Gateway de API vs. proxy reverso

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?

É 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.

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.

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.