Passerelle API vs proxy inverse

Afin de gérer l'architecture du microservice, il est souvent utilisé avec un proxy inverse (tel que nginx ou apache httpd) et pour des questions transversales d'implémentation, un modèle de passerelle API est utilisé . Parfois, le proxy inverse fait le travail de la passerelle API.
Il sera bon de voir des différences claires entre ces deux approches. Il semble que l'avantage potentiel de l'utilisation de la passerelle API est d'appeler plusieurs microservices et d'agréger les résultats. Toutes les autres responsabilités de la passerelle API peuvent être implémentées à l'aide du proxy inverse.

• Authentification (Cela peut être fait à l'aide de scripts LUA nginx);
• Sécurité des transports. Il lui-même tâche de proxy inverse;
• L'équilibrage de charge
• ....

Donc, sur la base de cela, il y a plusieurs questions:

1. Est-il judicieux d'utiliser simultanément la passerelle API et le proxy inverse (comme exemple de demande-> passerelle Api-> proxy inverse (nginx) -> mictoservice concret)? Dans quels cas?
2. Quelles sont les autres différences qui peuvent être implémentées à l'aide de la passerelle API et ne peuvent pas être implémentées par le proxy inverse et vice versa?

Il est plus facile d'y penser si vous vous rendez compte qu'ils ne s'excluent pas mutuellement. Considérez une passerelle API comme une implémentation de proxy inverse de type spécifique.

En ce qui concerne vos questions, il n'est pas rare de voir les deux utilisés conjointement où la passerelle API est traitée comme un niveau d'application qui se trouve derrière un proxy inverse pour l'équilibrage de charge et la vérification de l'état. Un exemple serait quelque chose comme une architecture sandwich WAF en ce que votre pare-feu d'application Web / passerelle API est pris en sandwich par des niveaux de proxy inverse, l'un pour le WAF lui-même et l'autre pour les microservices individuels avec lesquels il communique.

En ce qui concerne les différences, elles sont très similaires. C'est juste de la nomenclature. Au fur et à mesure que vous effectuez une configuration de proxy inverse de base et que vous commencez à développer davantage d'éléments tels que l'authentification, la limitation de débit, les mises à jour de configuration dynamiques et la découverte de services, les gens sont plus susceptibles d'appeler cela une passerelle API.

Je crois que API Gateway est un proxy inverse qui peut être configuré dynamiquement via API et potentiellement via l'interface utilisateur, tandis que le proxy inverse traditionnel (comme Nginx, HAProxy ou Apache) est configuré via un fichier de configuration et doit être redémarré lorsque la configuration change. Ainsi, API Gateway doit être utilisé lorsque les règles de routage ou d'autres configurations changent souvent. À vos questions:

1. Cela a du sens tant que chaque composant de cette séquence atteint son objectif.
2. Les différences ne se trouvent pas dans la liste des fonctionnalités, mais dans la manière dont les modifications de configuration sont appliquées.

De plus, API Gateway est souvent fourni sous forme de SAAS, comme Apigee ou Tyk par exemple.

Aussi, voici mon tutoriel sur la création d'une passerelle API simple avec Node.js https://memz.co/api-gateway-microservices-docker-node-js/

J'espère que ça aide.

Les passerelles API fonctionnent généralement comme une construction L7.

Les passerelles API offrent des fonctionnalités supplémentaires par rapport à un proxy inverse simple. Si vous considérez certains des portails disponibles, ils peuvent fournir:

• Gestion complète du cycle de vie des API, y compris la documentation
• un portail qui peut être utilisé comme source de vérité pour diverses applications client et où vous pouvez fournir une gouvernance client, une limitation de débit, etc.
• acheminement vers différentes versions de l'API, y compris les versions Canary / beta
• détecter les modèles d'utilisation, enregistrer les applications, récupérer les informations d'identification du client, etc.

Cependant, avec l'avènement des maillages de service comme Istio, Consul une grande partie des fonctionnalités des passerelles API seront subsumées par des maillages.