Em uma arquitetura de microsserviços, um cliente pode interagir com mais de um serviço front-end. Diante desse fato, como um cliente sabe quais endpoints chamar? O que acontece quando novos serviços são introduzidos ou os serviços existentes são refatorados? Como os serviços lidam com terminação SSL, autenticação e outras preocupações? Um gateway de API pode ajudar a enfrentar esses desafios.
Transfira um ficheiro do Visio desta arquitetura.
O que é um gateway de API?
Um gateway de API fica entre clientes e serviços. Ele atua como um proxy reverso, roteando solicitações de clientes para serviços. Ele também pode executar várias tarefas transversais, como autenticação, terminação SSL e limitação de taxa. Se você não implantar um gateway, os clientes deverão enviar solicitações diretamente para os serviços front-end. No entanto, existem alguns problemas potenciais com a exposição de serviços diretamente aos clientes:
- Isso pode resultar em código de cliente complexo. O cliente deve acompanhar vários endpoints e lidar com falhas de forma resiliente.
- Ele cria acoplamento entre o cliente e o back-end. O cliente precisa saber como os serviços individuais são decompostos. Isso torna mais difícil manter o cliente e também mais difícil refatorar os serviços.
- Uma única operação pode exigir chamadas para vários serviços. Isso pode resultar em várias viagens de ida e volta de rede entre o cliente e o servidor, adicionando latência significativa.
- Cada serviço voltado para o público deve lidar com questões como autenticação, SSL e limitação de taxa de cliente.
- Os serviços devem expor um protocolo amigável ao cliente, como HTTP ou WebSocket. Isso limita a escolha dos protocolos de comunicação.
- Serviços com pontos de extremidade públicos são uma superfície de ataque potencial e devem ser fortalecidos.
Um gateway ajuda a resolver esses problemas, dissociando clientes de serviços. Os gateways podem executar várias funções diferentes, e você pode não precisar de todas elas. As funções podem ser agrupadas nos seguintes padrões de design:
Roteamento de gateway. Use o gateway como um proxy reverso para rotear solicitações para um ou mais serviços de back-end, usando o roteamento de camada 7. O gateway fornece um único ponto de extremidade para clientes e ajuda a separar clientes de serviços.
Agregação de gateway. Use o gateway para agregar várias solicitações individuais em uma única solicitação. Esse padrão se aplica quando uma única operação requer chamadas para vários serviços de back-end. O cliente envia uma solicitação para o gateway. O gateway despacha solicitações para os vários serviços de back-end e, em seguida, agrega os resultados e os envia de volta ao cliente. Isso ajuda a reduzir a conversa entre o cliente e o backend.
Descarregamento de gateway. Use o gateway para descarregar a funcionalidade de serviços individuais para o gateway, especialmente preocupações transversais. Pode ser útil consolidar estas funções num único local, em vez de responsabilizar todos os serviços pela sua implementação. Isso é particularmente verdadeiro para recursos que exigem habilidades especializadas para serem implementados corretamente, como autenticação e autorização.
Aqui estão alguns exemplos de funcionalidades que podem ser descarregadas para um gateway:
- Terminação de SSL
- Autenticação
- Lista de permissões ou lista de bloqueio de IP
- Limitação da taxa do cliente (limitação)
- Início de sessão e monitorização
- Cache de resposta
- Firewall de aplicação Web
- Compressão GZIP
- Manutenção de conteúdo estático
Escolhendo uma tecnologia de gateway
Aqui estão algumas opções para implementar um gateway de API em seu aplicativo.
Servidor proxy reverso. Nginx e HAProxy são servidores proxy reverso populares que suportam recursos como balanceamento de carga, SSL e roteamento de camada 7. Ambos são produtos gratuitos de código aberto, com edições pagas que fornecem recursos adicionais e opções de suporte. Nginx e HAProxy são produtos maduros com conjuntos de recursos ricos e alto desempenho. Você pode estendê-los com módulos de terceiros ou escrevendo scripts personalizados no Lua. O Nginx também suporta um módulo de script baseado em JavaScript conhecido como NGINX JavaScript. Este módulo foi formalmente chamado nginScript.
Controlador de entrada de malha de serviço. Se você estiver usando uma malha de serviço, como Linkerd ou Istio, considere os recursos fornecidos pelo controlador de entrada para essa malha de serviço. Por exemplo, o controlador de ingresso Istio suporta roteamento de camada 7, redirecionamentos HTTP, tentativas e outros recursos.
Azure Application Gateway. O Application Gateway é um serviço de balanceamento de carga gerenciado que pode executar roteamento de camada 7 e terminação SSL. Ele também fornece um firewall de aplicativo da Web (WAF).
O Azure Front Door é a moderna Rede de Distribuição de Conteúdo (CDN) na nuvem da Microsoft que fornece acesso rápido, confiável e seguro entre seus usuários e o conteúdo da Web estático e dinâmico de seus aplicativos em todo o mundo. O Azure Front Door fornece seu conteúdo usando a rede de borda global da Microsoft com centenas de pontos de presença (PoPs) globais e locais distribuídos em todo o mundo perto de seus usuários finais corporativos e consumidores.
Gerenciamento de API do Azure. O Gerenciamento de API é uma solução pronta para uso para publicação de APIs para clientes externos e internos. Ele fornece recursos que são úteis para gerenciar uma API voltada para o público, incluindo limitação de taxa, restrições de IP e autenticação usando o Microsoft Entra ID ou outros provedores de identidade. O Gerenciamento de API não executa nenhum balanceamento de carga, portanto, deve ser usado em conjunto com um balanceador de carga, como o Application Gateway ou um proxy reverso. Para obter informações sobre como usar o Gerenciamento de API com o Application Gateway, consulte Integrar o Gerenciamento de API em uma VNet interna com o Application Gateway.
Ao escolher uma tecnologia de gateway, considere o seguinte:
Caraterísticas. As opções listadas acima suportam roteamento de camada 7, mas o suporte para outros recursos varia. Dependendo dos recursos necessários, você pode implantar mais de um gateway.
Implementação. O Gateway de Aplicativo do Azure e o Gerenciamento de API são serviços gerenciados. O Nginx e o HAProxy normalmente são executados em contêineres dentro do cluster, mas também podem ser implantados em VMs dedicadas fora do cluster. Isso isola o gateway do restante da carga de trabalho, mas incorre em sobrecarga de gerenciamento superior.
Gestão. Quando os serviços são atualizados ou novos serviços são adicionados, as regras de roteamento do gateway podem precisar ser atualizadas. Considere como esse processo será gerenciado. Considerações semelhantes se aplicam ao gerenciamento de certificados SSL, listas de permissões de IP e outros aspetos da configuração.
Implantando Nginx ou HAProxy no Kubernetes
Você pode implantar Nginx ou HAProxy no Kubernetes como um ReplicaSet ou DaemonSet que especifica a imagem do contêiner Nginx ou HAProxy. Use um ConfigMap para armazenar o arquivo de configuração para o proxy e monte o ConfigMap como um volume. Crie um serviço do tipo LoadBalancer para expor o gateway por meio de um Azure Load Balancer.
Uma alternativa é criar um Ingress Controller. Um Ingress Controller é um recurso do Kubernetes que implanta um balanceador de carga ou servidor proxy reverso. Existem várias implementações, incluindo Nginx e HAProxy. Um recurso separado chamado Ingress define configurações para o Ingress Controller, como regras de roteamento e certificados TLS. Dessa forma, você não precisa gerenciar arquivos de configuração complexos que são específicos de uma determinada tecnologia de servidor proxy.
O gateway é um gargalo potencial ou um único ponto de falha no sistema, portanto, sempre implante pelo menos duas réplicas para alta disponibilidade. Talvez seja necessário expandir ainda mais as réplicas, dependendo da carga.
Considere também executar o gateway em um conjunto dedicado de nós no cluster. Os benefícios desta abordagem incluem:
Isolamento. Todo o tráfego de entrada vai para um conjunto fixo de nós, que podem ser isolados dos serviços de back-end.
Configuração estável. Se o gateway estiver configurado incorretamente, todo o aplicativo poderá ficar indisponível.
Desempenho. Talvez você queira usar uma configuração de VM específica para o gateway por motivos de desempenho.
Próximos passos
Os artigos anteriores analisaram as interfaces entre microsserviços ou entre microsserviços e aplicativos cliente. Por design, essas interfaces tratam cada serviço como uma caixa opaca. Em particular, os microsserviços nunca devem expor detalhes de implementação sobre como gerenciam dados. Isso tem implicações para a integridade e consistência dos dados, exploradas no próximo artigo.