Brama API a zwrotny serwer proxy

Aby poradzić sobie z architekturą mikrousług, jest często używany razem z odwrotnym serwerem proxy (takim jak nginx lub apache httpd), aw przypadku problemów związanych z cięciem krzyżowym używany jest wzorzec bramy API . Czasami Reverse proxy wykonuje pracę bramy API.
Dobrze będzie zobaczyć wyraźne różnice między tymi dwoma podejściami. Wygląda na to, że potencjalną korzyścią z użycia bramy interfejsu API jest wywoływanie wielu mikrousług i agregowanie wyników. Wszystkie inne obowiązki API Gateway można zaimplementować za pomocą Reverse Proxy, takich jak:

• Uwierzytelnianie (można to zrobić za pomocą skryptów Nginx LUA);
• Bezpieczeństwo transportu. To samo zadanie Reverse Proxy;
• Równoważenie obciążenia
• ....

Na tej podstawie powstaje kilka pytań:

1. Czy ma sens jednoczesne używanie bramy API i Reverse proxy (na przykład żądanie-> brama API-> reverse proxy (nginx) -> konkretna usługa mictoservice)? W jakich przypadkach?
2. Jakie inne różnice można zaimplementować za pomocą bramy interfejsu API, a których nie można zaimplementować przez Reverse proxy i odwrotnie?

Łatwiej o nich pomyśleć, jeśli zdasz sobie sprawę, że nie wykluczają się wzajemnie. Pomyśl o bramie interfejsu API jako o implementacji zwrotnego proxy określonego typu.

Jeśli chodzi o Twoje pytania, nierzadko zdarza się, że oba są używane w połączeniu, w których brama interfejsu API jest traktowana jako warstwa aplikacji, która znajduje się za zwrotnym serwerem proxy do równoważenia obciążenia i sprawdzania kondycji. Przykładem może być architektura typu sandwich WAF, w której zapora aplikacji sieci Web / brama interfejsu API jest umieszczona między warstwami odwrotnego serwera proxy, jedna dla samej WAF, a druga dla poszczególnych mikrousług, z którymi rozmawia.

Jeśli chodzi o różnice, są one bardzo podobne. To tylko nazewnictwo. Gdy podejmiesz podstawową konfigurację odwrotnego proxy i zaczniesz łączyć się z większą liczbą elementów, takich jak uwierzytelnianie, ograniczanie szybkości, dynamiczne aktualizacje konfiguracji i wykrywanie usług, ludzie będą częściej wywoływać to bramą interfejsu API.

Uważam, że API Gateway to odwrotne proxy, które można skonfigurować dynamicznie za pośrednictwem interfejsu API i potencjalnie za pośrednictwem interfejsu użytkownika, podczas gdy tradycyjne odwrotne proxy (takie jak Nginx, HAProxy lub Apache) jest konfigurowane za pomocą pliku konfiguracyjnego i musi zostać ponownie uruchomione po zmianie konfiguracji. Dlatego bramy interfejsu API należy używać w przypadku częstych zmian reguł routingu lub innej konfiguracji. Na Twoje pytania:

1. Ma to sens, o ile każdy element w tej sekwencji spełnia swoje zadanie.
2. Różnic nie ma na liście funkcji, ale w sposobie stosowania zmian konfiguracji.

Ponadto API Gateway jest często dostarczane w postaci SAAS, na przykład Apigee lub Tyk .

Oto mój samouczek dotyczący tworzenia prostej bramy API za pomocą Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Mam nadzieję, że to pomoże.

Bramy API zwykle działają jako konstrukcja L7.

Bramy interfejsu API zapewniają dodatkowe funkcje w porównaniu do zwykłego zwrotnego serwera proxy. Jeśli weźmiesz pod uwagę niektóre portale, które mogą zapewnić:

• pełne zarządzanie cyklem życia API wraz z dokumentacją
• portal, który może służyć jako źródło informacji o różnych aplikacjach klienckich i gdzie można zapewnić zarządzanie klientem, ograniczanie szybkości itp.
• routing do różnych wersji API, w tym wersji canary / beta
• wykrywanie wzorców użytkowania, rejestrowanie aplikacji, pobieranie danych logowania klienta itp.

Jednak wraz z pojawieniem się siatek usług, takich jak Istio, Consul wiele funkcji bram interfejsu API zostanie objętych przez siatki.