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, TLS mútuo, autenticação e outras preocupações? Um gateway de API pode ajudar a enfrentar esses desafios.
Baixe um arquivo Visio dessa arquitetura.
O que é um gateway de API?
Um gateway de API fornece um ponto de entrada centralizado para gerenciar interações entre clientes e serviços de aplicativos. Ele atua como um proxy reverso e encaminha as solicitações dos clientes para os serviços apropriados. Ele também pode executar várias tarefas transversais, como autenticação, terminação SSL, TLS mútuo e limitação de taxa.
Por que usar um gateway de API?
Um gateway de API simplifica a comunicação, aprimora as interações do cliente e centraliza o gerenciamento de responsabilidades comuns de nível de serviço. Atua como intermediário e evita a exposição direta dos serviços de aplicação aos clientes. Sem um gateway de API, os clientes devem se comunicar diretamente com serviços de aplicativos individuais, o que pode introduzir os seguintes desafios:
Código de cliente complexo: Pode resultar em código de cliente complexo. Os clientes devem rastrear vários endpoints e lidar com falhas de forma resiliente.
Tight coupling: Cria acoplamento entre o cliente e o backend. Os clientes precisam entender a decomposição de serviços individuais, complicando a manutenção e refatoração do serviço.
Maior latência: Uma única operação pode exigir chamadas para vários serviços. O resultado pode ser várias viagens de ida e volta de rede entre o cliente e o servidor, adicionando latência significativa.
Tratamento redundante de preocupações: Cada serviço voltado para o público deve lidar com preocupações como autenticação, SSL e limitação de taxa de cliente.
Limitações do protocolo: Os serviços devem expor um protocolo amigável ao cliente, como HTTP ou WebSocket. Esta exposição limita protocolos opções de comunicação.
Superfície de ataque expandida: Os pontos finais públicos aumentam a superfície de ataque potencial e requerem endurecimento.
Como usar um gateway de API
Um gateway de API pode ser adaptado aos requisitos do seu aplicativo usando padrões de design específicos. Esses padrões de design abordam funcionalidades importantes, como roteamento, agregação de solicitações e preocupações transversais:
Roteamento de gateway. Você pode usar um gateway de API como um proxy reverso para rotear solicitações de cliente para diferentes serviços de aplicativo. O gateway de API usa roteamento de camada 7 e fornece um único ponto de extremidade para os clientes usarem. Use o roteamento de gateway de API quando quiser separar clientes de serviços de aplicativo.
Agregação de gateway. Você pode usar o gateway de API para agregar várias solicitações de cliente em uma única solicitação. Use esse padrão quando uma única operação exigir chamadas para vários serviços de aplicativos. Na agregação de API, o cliente envia uma solicitação para o gateway de API. Em seguida, o gateway de API roteia solicitações para os vários serviços necessários para as operações. Finalmente, o gateway de API agrega os resultados e os envia de volta ao cliente. A agregação ajuda a reduzir a tagarelice entre o cliente e os serviços do aplicativo.
Descarregamento do gateway. Você pode usar um gateway de API para fornecer funcionalidade transversal, para que serviços individuais não precisem fornecê-la. Pode ser útil consolidar a funcionalidade transversal num único local, em vez de responsabilizar todos os serviços. Aqui estão exemplos de funcionalidades que você pode descarregar para um gateway de API:
- Terminação SSL
- TLS mútuo
- Autenticação
- Lista de permissões ou lista de bloqueio de IP
- Limitação da taxa do cliente (limitação)
- Registo e monitorização
- Cache de resposta
- Firewall de aplicativos Web
- Compressão GZIP
- Manutenção de conteúdo estático
Opções de gateway de API
Aqui estão algumas opções para implementar um gateway de API em seu aplicativo.
Servidor proxy reverso. Nginx e HAProxy são ofertas de proxy reverso de código aberto. Eles suportam recursos como balanceamento de carga, terminação SSL e roteamento de camada 7. Eles têm versões gratuitas e edições pagas que fornecem recursos extras e opções de suporte. Esses produtos são maduros com conjuntos de recursos ricos, alto desempenho e extensíveis.
Controlador de entrada de malha de serviço. Se você usar uma malha de serviço, avalie os recursos do controlador de entrada específicos para essa malha de serviço. Verifique se há complementos suportados pelo AKS, como Istio e Open Service Mesh. Procure projetos de código aberto de terceiros como Linkerd ou Consul Connect. Por exemplo, o controlador de ingresso Istio suporta roteamento de camada 7, redirecionamentos HTTP, tentativas e outros recursos.
Gateway de Aplicativo do Azure. O Application Gateway é um serviço de balanceamento de carga gerenciado. Ele fornece roteamento de camada 7, terminação SSL e um firewall de aplicativo Web (WAF).
Azure Front Door. O Azure Front Door é uma rede de entrega de conteúdo (CDN). Ele usa pontos de presença (PoPs) globais e locais para fornecer acesso rápido, confiável e seguro ao conteúdo da Web estático e dinâmico de seus aplicativos globalmente.
Azure API Management. O Gerenciamento de API é uma solução gerenciada para publicação de APIs para clientes externos e internos. Ele fornece recursos para gerenciar APIs voltadas 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, você deve usá-lo com um balanceador de carga, como o Gateway de Aplicativo do Azure, ou um proxy reverso. Para obter informações, consulte Gerenciamento de API com o Gateway de Aplicativo do Azure.
Escolha uma tecnologia de gateway de API
Ao selecionar um gateway de API, considere os seguintes fatores:
Suporte a todos os requisitos. Escolha um gateway de API que suporte os recursos necessários. Todas as opções de gateway de API de anteriores oferecem suporte ao roteamento de camada 7. Mas seu suporte para outros recursos, como autenticação, limitação de taxa e terminação SSL, pode variar. Avalie se um único gateway atende às suas necessidades ou se vários gateways são necessários.
Prefira ofertas integradas. Use o gateway de API integrado e as soluções de entrada fornecidas pela sua plataforma, como os Aplicativos de Contêiner do Azure e o AKS, sempre que eles atenderem aos seus requisitos de segurança e controle. Use apenas um gateway personalizado se as opções internas não tiverem flexibilidade necessária. Soluções personalizadas exigem um modelo de governança, como o GitOps, para gerenciar seu ciclo de vida de forma eficaz.
Escolha o modelo de implantação correto. Use serviços gerenciados como o Gateway de Aplicativo do Azure e o Gerenciamento de API do Azure para reduzir a sobrecarga operacional. Se você usar proxies reversos ou balanceadores de carga de uso geral, implante-os de forma alinhada com sua arquitetura. Você pode implantar gateways de API de uso geral em máquinas virtuais dedicadas ou dentro de um cluster AKS em suas ofertas do Ingress Controller. Para isolar o gateway de API da carga de trabalho, você pode implantá-los fora do cluster, mas essa implantação aumenta a complexidade do gerenciamento.
Gerencie as alterações. Ao atualizar serviços ou adicionar novos, talvez seja necessário atualizar as regras de roteamento de gateway. Implemente processos ou fluxos de trabalho para gerenciar regras de roteamento ao adicionar ou modificar serviços, certificados SSL, listas de permissões de IP e configurações de segurança. Use ferramentas de infraestrutura como código e automação para simplificar o gerenciamento de gateway de API.
Próximos passos
Artigos anteriores exploraram as interfaces entre microsserviços e entre microsserviços e aplicativos cliente. Estas interfaces tratam cada serviço como uma unidade autónoma e opaca. Um princípio crítico da arquitetura de microsserviços é que os serviços nunca devem expor detalhes internos sobre como gerenciam dados. Essa abordagem tem implicações significativas para manter a integridade e a consistência dos dados, que é o assunto do próximo artigo.