API-Gateway vs. Reverse-Proxy

Um mit der Microservice-Architektur fertig zu werden, wird sie häufig zusammen mit einem Reverse Proxy (wie Nginx oder Apache httpd) verwendet, und für Querschnittsthemen wird das API-Gateway-Muster für die Implementierung verwendet . Manchmal erledigt der Reverse Proxy die Arbeit des API-Gateways.
Es wird gut sein, klare Unterschiede zwischen diesen beiden Ansätzen zu sehen. Es sieht so aus, als ob der potenzielle Vorteil der Verwendung von API-Gateways darin besteht, mehrere Microservices aufzurufen und die Ergebnisse zu aggregieren. Alle anderen Verantwortlichkeiten des API-Gateways können mit Reverse Proxy implementiert werden.

• Authentifizierung (Dies kann mithilfe von Nginx-LUA-Skripten erfolgen);
• Transportsicherheit. Es selbst Reverse Proxy-Aufgabe;
• Lastverteilung
• ....

Auf dieser Grundlage gibt es mehrere Fragen:

1. Ist es sinnvoll, API-Gateway und Reverse-Proxy gleichzeitig zu verwenden (als Beispiel request-> Api-Gateway-> Reverse-Proxy (nginx) -> konkreter Mictoservice)? In welchen Fällen?
2. Was sind die anderen Unterschiede, die mit dem API-Gateway implementiert werden können und nicht mit dem Reverse-Proxy implementiert werden können und umgekehrt?

Es ist einfacher, an sie zu denken, wenn Sie feststellen, dass sie sich nicht gegenseitig ausschließen. Stellen Sie sich ein API-Gateway als eine Reverse-Proxy-Implementierung eines bestimmten Typs vor.

In Bezug auf Ihre Fragen ist es nicht ungewöhnlich, dass beide in Verbindung verwendet werden, wenn das API-Gateway als Anwendungsebene behandelt wird, die sich hinter einem Reverse-Proxy für den Lastausgleich und die Integritätsprüfung befindet. Ein Beispiel wäre eine WAF-Sandwich-Architektur, bei der Ihre Webanwendungs-Firewall / Ihr API-Gateway von Reverse-Proxy-Ebenen umgeben ist, eine für die WAF selbst und die andere für die einzelnen Mikrodienste, mit denen sie spricht.

In Bezug auf die Unterschiede sind sie sehr ähnlich. Es ist nur eine Nomenklatur. Wenn Sie ein grundlegendes Reverse-Proxy-Setup durchführen und weitere Elemente wie Authentifizierung, Ratenbegrenzung, dynamische Konfigurationsaktualisierungen und Diensterkennung verwenden, wird dies eher als API-Gateway bezeichnet.

Ich glaube, API Gateway ist ein Reverse-Proxy, der dynamisch über die API und möglicherweise über die Benutzeroberfläche konfiguriert werden kann, während der herkömmliche Reverse-Proxy (wie Nginx, HAProxy oder Apache) über die Konfigurationsdatei konfiguriert wird und bei Konfigurationsänderungen neu gestartet werden muss. Daher sollte API Gateway verwendet werden, wenn sich Routingregeln oder andere Konfigurationen häufig ändern. Auf Ihre Fragen:

1. Es ist sinnvoll, solange jede Komponente in dieser Sequenz ihren Zweck erfüllt.
2. Unterschiede bestehen nicht in der Funktionsliste, sondern in der Art und Weise, wie Konfigurationsänderungen angewendet werden.

Darüber hinaus wird API Gateway häufig in Form von SAAS bereitgestellt, z. B. Apigee oder Tyk .

Außerdem ist hier mein Tutorial zum Erstellen eines einfachen API-Gateways mit Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Ich hoffe es hilft.