Discovery e Gateway API

Além de estar integrado ao SSO da PDPJ-Br, todos os serviços, módulos e sistemas integrados à plataforma devem se registrar no seu serviço de descoberta (discovery). O mencionado serviço é uma implementação de um Eureka Netflix Server como provido no pacote do Spring Cloud. Em homologação, o endereço é https://discovery.stg.cloud.pje.jus.br/.

A principal consequência do registro no serviço de descoberta é a possibilidade da API do serviço registrado ser acessível por meio do Gateway API da PDPJ-Br. Desta maneira, os serviços, sistemas e módulos que não possuam URL própria podem ter a sua API alcançada por meio do caminho https://URL-DO-GATEWAY/NOME-DO-SERVICO/PATH-PARA-API. A título de exemplo, para obter os dados de um pessoa a partir do seu CPF, por meio do serviço de pessoas da PDPJ-Br, poder-se-ia acessar a API (com a devida autenticação, como explicado acima), por meio do caminho https://gateway.stg.cloud.pje.jus.br/pessoas-api/api/v1/pessoas-fisicas?cpf=XXX+

Service Discovery

Quando se constrói uma aplicação monolítica, é comum termos divisões dentro da sua estrutura para separar as funcionalidades, em alguns casos chamamos estas divisões de módulos.

Uma vez que os diversos módulos estão na mesma aplicação, é comum um módulo se comunicar com outro, de maneira a lidar com a complexidade de negócio, deixando o frontend apenas o trabalho exibir os dados.

A medida que começamos a quebrar esta aplicação em pedaços menores, alguns códigos que antes eram feitos no backend, começam a aparecer no frontend, normalmente este tipo de código aparece como uma cadeia de chamadas em cascata para diversos serviços, de maneira que o frontend faça o papel de "cola" entre os módulos que antes estavam todos juntos.

Porém, a medida que o negócio cresce e a maturidade das equipes de desenvolvimento de software também cresce, eles veem que está cada vez mais difícil de manter a aplicação cliente que precisa:

• Saber onde está cada serviço, e quando é necessário mudar o IP ou porta o cliente precisa ser ajustado;
• Cada serviço precisa estar exposto, o que aumenta a superfície de ataques;
• Lidar com latência de rede, talvez precise ser implementado no front;
• Realizar estrangulamento de dados, para não afogar o banco de dados talvez precise ser implementado no front;
• Dificulta o rastreamento dos dados;
• Uma simples operação pode acabar por realizar muitas chamadas aos serviços, resultando em lentidão. Se esta complexidade se mante-se no servidor, um “agregador” poderia realizar diversas chamadas todas na rede interna, tornando tudo mais eficiente;
• Cliente precisa fazer muitas requisições, quando se trata de um dispositivo móvel, isto implica em maior consumo de dados móveis e e bateria.

A solução é devolver a complexidade que foi levado ao frontend de volta ao seu dono, o backend, com o que hoje conhecemos como Service Discovery. Com ele, o cliente não vai mais enviar suas requisições a cada serviço, ele irá enviar para um local único, que através do Service Discovery saberá para onde encaminhar, então receber de volta a requisição e devolvê-la pro cliente. Para isto funcionar, cada serviço precisa registrar-se no Service Discovery, e quando for necessário, quem precisar enviar uma requisição perguntará para o Service Discovery qual o serviço está em execução.

Dessa forma, tem-se um modelo mais escalável e resiliente a falhas.

API Gateway

Após esses serviços estarem disponíveis e registrados, é necessário disponibilizá-los em um catálogo, o Gateway API.

Na arquitetura de microsserviços, o mesmo serviço estará disponível em vários locais como microsserviços. Um registro de serviço armazena as informações dos endpoints. Quando um cliente precisa enviar uma solicitação para um serviço, o registro de serviço fornece as informações sobre o endpoint em que o serviço está.

Um microsserviço pode estar disponível ou fora do ar a qualquer momento com base em vários fatores como falha de hardware, sobrecarga, atividades de desenvolvimento, etc. Uma nova instância de microsserviço pode ser gerada a qualquer momento por várias razões, como - atualização da versão do serviço, manutenção de alta disponibilidade, etc. Portanto, não é possível para um cliente obter as informações sobre onde um determinado serviço está disponível. O registro de serviços entra em cena para resolver esse problema no cenário acima.‎

O registro ocorre quando uma instância de um microsserviço está levantando, o registro de serviço será notificado de que este serviço em particular está disponível no endpoint específico.

Da mesma forma, o descadastramento ocorre quando um microsserviço cai, o registro de serviço é notificado sobre a indisponibilidade dessa instância.