Padrões de Microserviços — Proxy ou API Gateway

Zull é um API Gateway que negocia com todas as requisições e realiza todo tipo de operação com elas inclusive roteamento dinâmico já com balanceamento de carga (no lado do servidor), para isto ele utiliza o Netflix Ribbon para procurar todas as instâncias dos serviços disponíveis no Service Discovery (Netflix Eureka Server).

O Zull também é conhecido como Servidor de borda, este nome vem por que comumente se encontra entre a sua rede interna e a rede externa, realizando um papel análogo ao de um firewall.

Por exemplo, poderíamos ter /api/user mapeado para o micro serviço que retorna os usuários paginado e o /api/products mapeado para o micro serviço que retorna os produtos de forma paginada.

O nome Zull vem de uma analogia com o cão de guarda que aparece nos Caça Fantasmas. Acredito que isto representa bem, pois o que o Netflix Zull faz é exatamente isto, ele fica no meio e não permite que requisições indesejadas passem para o outro lado e vice versa.

Como o Zull tem a posse das informações, ele pode realizar diversas outras tarefas como:

• Autenticação
• Lidar com SSL
• Limitar taxa de transferência

Você pode optar por não utilizar um API Gateway, expondo seu back-end ao front-end, isto habilitaria o seu back a enviar requisições diretamente ao front. Porem, há alguns problemas em potencial pelo não uso do API Gateway:

• Pode resultar em complexidade de código no front-end. O Client talvez precise manter o endereço de diversos endpoints para manter a segurança, negociar com possíveis falhas e manter-se resiliente;
• Cria acoplamento entre back e front. O Front precisa saber como cada serviço está individualmente decomposto. Isto é difícil de manter, e o front provavelmente sofrerá constantes refatorações;
• 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;
• Caso seja necessário fazer um estrangulamento dos dados, talvez tenha de incluir esta complexidade no front;
• A rede interna poderia haver diversos protocolos de comunicação diferente, o front teria de saber como lidar com essa diversidade;
• É comum quer otimizar a comunicação na rede interna, a fim de ganhar performance e menor uso da rede, atualmente esta preocupação nos levaria para protocolos como gRPC ou MQTT, por exemplo. Mas isto faz sentido na rede externa? Atualmente o padrão mais comum é expor os dados em formato JSON afim de promover melhor experiência aos desenvolvedores, protocolos binários vão na contra mão desta experiência;
• Serviços públicos, são potenciais superfícies de ataque;

O API Gateway ajuda a endereçar essas questões, desacoplando o front do back. Há diversas funcionalidades possíveis de se utilizar, e você talvez não queria todas elas. Estas funcionalidades estão agrupadas em três padrões: Gateway routing, Gateway Aggregation, Gateway Offloading.

Gateway routing

Proxy reverso para rotear as requisições para um ou mais serviços.

Considerações sobre Gateway routing:

• Utilizar um API Gateway pode introduzir um ponto único de falha. Considere resiliência e tolerância a falhas na implantação;
• Introduz um gargalo. Tenha certeza de que a performance do mesmo está adequada, mantenha-o simples e leve;
• Faça testes para garantir que não foi introduzido falhas em cascata (engenharia do caos);
• Gateway routing é feito na camada (TCP/IP) que permite ser baseada em IP, porta, cabeçalho do protocolo ou URL;

Gateway Aggregation

Use para agregar múltiplas partes de requisições individuais em uma simples. Este padrão é utilizado quando uma simples operação deve chamar diversos serviços no back-end.

Demonstração do problema

O cliente envia uma unica requisição ao Gateway Aggregation que dispara para diversos serviços, agrega as respostas e envia de volta ao cliente.

A solução com Gateway aggregation

Este padrão pode reduzir o número de requisições entre o cliente o servidor, se for um dispositivo móvel, significa economia na franquia de dados no consumo da bateria.

Considerações a respeito do Gateway Aggregation

• Os pontos a serem levados em consideração do Gateway routing também são validos aqui;
• O Gateway deve estar próximo dos serviços (na mesma rede) afim de reduzir a latência;
• Não deve introduzir acoplamento entre os serviços;
• Utilize práticas de um design resiliente, como: bulkheads, circuit breaker, retry e timeout
• Se um ou mais serviços demorarem, lide com o timeout e retorne os dados parcialmente. Teste como a solução irá lidar com dados parciais;
• Prefira o paradigma assíncrono e não bloqueante a fim de evitar problemas com performance;
• Implemente trace distribuído (zipkin, jaeger), usando um ID para correlacionar cada chamada individualmente;
• Monitore as requisições e o tamanho das respostas;
• Considere retornar dados cacheados, servirá como estratégia para evitar falhas;
• Considere realizar a agregação dos serviços em outro serviço de agregação, não no Gateway Aggregation, a medida que a quantidade de serviços crescer esta funcionalidade tente a impactar a performance do Gateway e das outras funcionalidades dele;

restQL - microservice query language

Gateway Offloading

São todas as funcionalidades que não são de negócio, elas cortam os requisitos de negócio (cross-cuting), em outra palavras, este padrão simplifica as aplicações por implementar de forma compartilhada ou especializada funcionalidades no gateway proxy, como:

• SSL Termination
• Autenticação
• Lista de IPs permitidos (whitlist)
• Limitações do client (throttling)
• Log
• Monitoramento
• Caching
• Firewall
• Compressão GZIP
• Servir conteúdo estático

Este padrão, simplifica o desenvolvimento dos serviços, removendo a necessidade distribuir e manter estas funcionalidades em cada serviço. Permite ter times dedicados a estes recursos, deixando as equipes de desenvolvimento focas no desenvolvimento dos requisitos de negócio nas aplicações.

Notas

• Talvez você enfrente dificuldades com CORS por ter sua API em um servidor e o cliente em outro, mesmo que esteja no mesmo host se a porta for diferente pode haver bloqueios, na realidade esta é uma proteção, e você deve lidar com ela, talvez liberando sua API para ser acessada de qualquer lugar. Mas antes pense, se você não tem clientes na Russia, porque você liberaria ela para ser acessada deste local do mundo, talvez você apenas esteja aumentando o risco de um DDOS.