web-dev-qa-db-fra.com

Passerelle API vs proxy inverse

Afin de gérer l'architecture de microservice, il est souvent utilisé avec un proxy inverse (tel que nginx ou Apache httpd) et pour la mise en œuvre de problèmes transversaux le modèle de passerelle API est utilisé . Parfois, le proxy inverse effectue 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 d’API consiste à appeler plusieurs microservices et à regrouper les résultats. Tous les autres responsabilités de la passerelle API peuvent être implémentés en utilisant un proxy inverse. Par exemple:

  • Authentification (cela peut être fait avec les scripts nginx LUA);
  • Sécurité des transports. Elle-même la tâche de proxy inverse;
  • L'équilibrage de charge
  • ....

Donc, sur cette base, plusieurs questions se posent:

  1. Est-il judicieux d’utiliser simultanément une passerelle API et un proxy inverse (par exemple, demande-> passerelle Api-> proxy inverse (nginx) -> concret mictoservice)? Dans quels cas?
  2. Quelles sont les autres différences qui peuvent être implémentées à l'aide d'une passerelle API et ne peuvent pas être implémentées par proxy inverse et inversement?
nginxreverse-proxymicroservicesaws-api-gatewaytyk
77
user1459144

Il est plus facile de penser à eux si vous réalisez qu’ils ne s’excluent pas mutuellement. Pensez à 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 utiliser conjointement lorsque la passerelle d’API est traitée comme un niveau d’application se trouvant derrière un proxy inverse pour l’équilibrage de la charge et la vérification de l’état de santé. Un exemple pourrait ressembler à une architecture sandwich WAF dans la mesure où votre passerelle API/pare-feu d'applications Web est intercalée entre 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 la nomenclature. Lorsque vous prenez une configuration de base de proxy inverse et que vous commencez à intégrer d'autres éléments tels que l'authentification, la limitation de débit, les mises à jour dynamiques de la configuration et la découverte de services, les utilisateurs sont plus susceptibles d'appeler cette passerelle API.

60
Justin Talbott

Je crois que API Gateway est un proxy inverse qui peut être configuré de manière dynamique via une API et éventuellement via une 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 une autre configuration changent souvent. A vos questions:

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

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

En outre, 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.

22
Andrey Chausenko