Com um aplicativo monolítico temos apenas um conjunto de terminais (geralmente replicados e com balanceamento de carga). Em uma arquitetura de microsserviços, no entanto, cada microsserviço expõe um conjunto de recursos de baixa granularidade. Vamos examinar como isso afeta a comunicação cliente-aplicativo e explicar o que é um API Gateway.
Comunicação direta entre cliente e microsserviço
Em teoria, um cliente poderia fazer solicitações diretamente a cada um dos microsserviços, com cada um tendo um terminal público, como por exemplo empresa.nome.api.servico. Essa URL seria mapeada para o balanceador de carga do microsserviço, que distribuiria solicitações pelas instâncias disponíveis.
Infelizmente existem alguns desafios e limitações com esta opção. Um primeiro problema com o cliente chamando diretamente os microsserviços é que alguns podem usar protocolos que não são compatíveis com a web. Existem protocolos que não são amigáveis para navegadores ou firewalls.
Um outro problema é a incompatibilidade entre as necessidades do cliente e as APIs refinadas expostas por cada um dos microsserviços. Por exemplo, a Amazon precisa consumir centenas de serviços na renderização da página do seu produto.
O código do cliente se tornaria muito mais complexo nessa configuração.
Outra desvantagem é a dificuldade de refatoração dos microsserviços. Com o tempo podemos mudar a forma como o sistema é particionado em serviços. Por exemplo, podemos mesclar dois serviços ou dividir um serviço em dois ou mais serviços.
Se, no entanto, os clientes se comunicarem diretamente com os serviços, a execução desse tipo de refatoração poderá ser extremamente difícil.
Benefícios e desvantagens de um gateway de API
Único ponto de entrada no sistema
O API Gateway encapsula a arquitetura interna do sistema e fornece uma API personalizada para cada cliente. Pode ter outras responsabilidades, como autenticação, monitoramento, balanceamento de carga, armazenamento em cache, modelagem e gerenciamento de solicitações e manipulação de resposta estática.
Impede a exposição de preocupações internas a clientes externos
Um gateway de API separa APIs públicas externas das APIs de microsserviço interno, permitindo que os microsserviços sejam adicionados e os limites alterados.
O resultado é a capacidade de refatorar e dimensionar eles corretamente ao longo do tempo, sem afetar negativamente os clientes externos. Ele também oculta detalhes de descoberta e versão de serviço do cliente, fornecendo um único ponto de entrada para todos os seus microsserviços.
Adiciona uma camada adicional de segurança aos seus microsserviços
Os gateways de API ajudam a impedir ataques maliciosos, fornecendo uma camada adicional de proteção contra vetores de ataque, como injeção de SQL, explorações do Analisador de XML e ataques de negação de serviço (DoS). Isso permite deixar a aplicação mais focada no negócio leva as outras responsabilidades de cache e segurança para o API Gateway.
Permite suporte para misturar protocolos de comunicação
Enquanto as APIs externas, normalmente, oferecem uma API baseada em HTTP ou REST, os microsserviços internos podem se beneficiar do uso de diferentes protocolos de comunicação. Os protocolos podem incluir ProtoBuf, AMQP ou talvez integração de sistema com SOAP, JSON-RPC ou XML-RPC.
Um gateway de API pode fornecer uma API baseada em REST externa e unificada nesses vários protocolos, permitindo que as equipes escolham o que melhor se ajusta à arquitetura interna.
Virtualização de microsserviços
Ao separar APIs de microsserviço da API externa, você pode simular (via mock) ou virtualizar seus serviços para validar os requisitos de design ou ajudar no teste de integração.
Desvantagens
A arquitetura de implantação exigirá mais orquestração e gerenciamento com a adição de um gateway de API.
A configuração da lógica de roteamento deve ser gerenciada durante a implantação, para garantir o roteamento adequado da API externa para o microsserviço adequado.
A menos que seja adequadamente arquitetado para alta disponibilidade e escala, um gateway de API pode se tornar um fator limitante e até um único ponto de falha. Consequentemente, existe o risco de o API Gateway se tornar um gargalo de desenvolvimento.
É mais um componente altamente disponível que deve ser desenvolvido, implantado e gerenciado. Os desenvolvedores devem atualizar o Gateway da API para expor os pontos de extremidade de cada microsserviço.
É importante que o processo para atualizar o API Gateway seja o mais leve possível. Caso contrário, os desenvolvedores serão forçados a esperar na fila para atualizar o gateway.
Exemplo do API Gateway da Netflix: Zuul
O serviço de streaming da Netflix está disponível em centenas de tipos diferentes de dispositivos, incluindo televisores, decodificadores, smartphones, sistemas de jogos, tablets, etc.
Inicialmente, a Netflix tentou fornecer uma API de tamanho único para o serviço de streaming. No entanto, eles descobriram que não funcionou tão bem por causa da diversidade de dispositivos e de suas necessidades exclusivas.
O Zuul foi criado para permitir roteamento dinâmico com monitoramento, resiliência e segurança. Ele também pode rotear solicitações para vários grupos do Amazon Auto Scaling, conforme apropriado.
Hoje, o Zuul fornece uma API personalizada para cada dispositivo, executando o código do adaptador específico do dispositivo. O adaptador geralmente lida com cada solicitação, chamando, em média, de seis a sete serviços de back-end. O Netflix API Gateway trata bilhões de solicitações por dia.
Conclusão
Hoje, a maioria dos aplicativos baseados em microsserviços implementam um API Gateway, que atua como um único ponto de entrada em um sistema. Também é responsável pelo roteamento de solicitação, composição e tradução de protocolo, além de fornecer para cada um dos clientes do aplicativo uma API personalizada.
O API Gateway também pode mascarar falhas nos serviços de back-end, retornando dados em cache ou padrão.
Conheça o API Manager da Zup.
Newsletter sobre desenvolvimento
Quer receber em primeira mão conteúdos como esse por e-mail? Assine aqui nossa newsletter semanal.
Aproveito para deixar um agradecimento especial ao Eder Paraiso, nosso especialista em API GW.
