Gateway de API vs. proxy reverso


108

Para lidar com a arquitetura de microsserviço, geralmente é usado junto com um proxy reverso (como nginx ou apache httpd) e, para questões transversais, o padrão de gateway de implementação de API é usado . Às vezes, o proxy reverso faz o trabalho do gateway de API.
Será bom ver diferenças claras entre essas duas abordagens. Parece que o benefício potencial do uso do gateway de API é invocar vários microsserviços e agregar os resultados. Todas as outras responsabilidades do gateway de API podem ser implementadas usando o proxy reverso. Como:

  • Autenticação (pode ser feita usando scripts nginx LUA);
  • Segurança de transporte. É a própria tarefa de proxy reverso;
  • Balanceamento de carga
  • ....

Portanto, com base nisso, existem várias perguntas:

  1. Faz sentido usar o gateway de API e o proxy reverso simultaneamente (por exemplo, solicitação-> gateway da API-> proxy reverso (nginx) -> mictoservice concreto)? Em quais casos?
  2. Quais são as outras diferenças que podem ser implementadas usando o gateway de API e não podem ser implementadas pelo proxy reverso e vice-versa?

Respostas:


83

É mais fácil pensar sobre eles se você perceber que não são mutuamente exclusivos. Pense em um gateway de API como uma implementação de proxy reverso de tipo específico.

Em relação às suas perguntas, não é incomum ver os dois usados ​​em conjunto onde o gateway de API é tratado como uma camada de aplicativo que fica atrás de um proxy reverso para balanceamento de carga e verificação de integridade. Um exemplo seria algo como uma arquitetura sanduíche WAF em que seu Firewall de aplicativo da Web / API Gateway é ensanduichado por camadas de proxy reverso, uma para o próprio WAF e outra para os microsserviços individuais com os quais ele se comunica.

Quanto às diferenças, são muito semelhantes. É apenas nomenclatura. Conforme você faz uma configuração básica de proxy reverso e começa a aplicar mais peças como autenticação, limitação de taxa, atualizações de configuração dinâmica e descoberta de serviço, é mais provável que as pessoas chamem isso de gateway de API.


corrija-me se estiver errado, mas posso usar os dois no mesmo ecossistema. Usar um gateway de API é mais para orquestrar mudanças dinâmicas e constantes adicionadas ao monitoramento do painel e restrições de segurança que usar um proxy reverso como o nginx poderia ser mais eficaz para servir subdomínios estáticos e fixos fornecendo equilíbrio de carga, por exemplo.
aelkz

28

Acredito que o API Gateway é um proxy reverso que pode ser configurado dinamicamente via API e potencialmente via UI, enquanto o proxy reverso tradicional (como Nginx, HAProxy ou Apache) é configurado via arquivo de configuração e deve ser reiniciado quando a configuração muda. Portanto, o API Gateway deve ser usado quando as regras de roteamento ou outras configurações mudam com frequência. Para suas perguntas:

  1. Faz sentido, desde que cada componente desta sequência sirva ao seu propósito.
  2. As diferenças não estão na lista de recursos, mas na forma como as alterações de configuração são aplicadas.

Além disso, o API Gateway é frequentemente fornecido na forma de SAAS, como Apigee ou Tyk, por exemplo.

Além disso, aqui está meu tutorial sobre como criar um gateway de API simples com Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Espero que ajude.


Obrigado pelas sugestões SAAS
Zenuka

4
alguma chance de você saber de um lugar alternativo para a informação do que estava naquele link memz.co? Está morto.
Nova Alexandria

0

Gateways API geralmente operam como uma construção L7.

Os Gateways API fornecem funcionalidade adicional em comparação com um proxy reverso simples. Se você considerar alguns dos portais por aí, eles podem fornecer:

  • Gerenciamento completo do ciclo de vida da API, incluindo documentação
  • um portal que pode ser usado como a fonte da verdade para vários aplicativos do cliente e onde você pode fornecer governança do cliente, limitação de taxa etc.
  • roteamento para diferentes versões da API, incluindo versões canário / beta
  • detectar padrões de uso, registrar aplicativos, recuperar credenciais de cliente etc.

No entanto, com o advento de malhas de serviço como o Istio, muitas das funcionalidades dos Gateways de API do Consul serão englobadas por malhas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.