Używanie bram interfejsu API w mikrousługach

Azure Application Gateway
Azure API Management

W architekturze mikrousług klient może wchodzić w interakcje z więcej niż jedną usługą frontonu. Biorąc pod uwagę ten fakt, jak klient wie, jakie punkty końcowe mają być wywoływane? Co się stanie, gdy zostaną wprowadzone nowe usługi lub istniejące usługi zostaną refaktoryzowane? W jaki sposób usługi obsługują kończenie żądań ssl, uwierzytelnianie i inne problemy? Brama interfejsu API może pomóc w rozwiązywaniu tych problemów.

Diagram of an API gateway

Pobierz plik programu Visio z tą architekturą.

Co to jest brama interfejsu API?

Brama interfejsu API znajduje się między klientami i usługami. Działa jako zwrotny serwer proxy, rozsyłanie żądań od klientów do usług. Może również wykonywać różne zadania krzyżowe, takie jak uwierzytelnianie, kończenie żądań SSL i ograniczanie szybkości. Jeśli brama nie zostanie wdrożona, klienci muszą wysyłać żądania bezpośrednio do usług frontonu. Istnieją jednak pewne potencjalne problemy z uwidacznianie usług bezpośrednio klientom:

  • Może to spowodować złożony kod klienta. Klient musi śledzić wiele punktów końcowych i obsługiwać błędy w sposób odporny.
  • Tworzy sprzężenie między klientem a zapleczem. Klient musi wiedzieć, jak poszczególne usługi są rozłożone. Utrudnia to utrzymanie klienta, a także trudniejsze do refaktoryzacji usług.
  • Pojedyncza operacja może wymagać wywołań wielu usług. Może to spowodować wiele rund sieci między klientem a serwerem, dodając znaczne opóźnienie.
  • Każda publiczna usługa musi obsługiwać problemy, takie jak uwierzytelnianie, protokół SSL i ograniczanie szybkości klientów.
  • Usługi muszą uwidaczniać przyjazny dla klienta protokół, taki jak HTTP lub WebSocket. Ogranicza to wybór protokołów komunikacyjnych.
  • Usługi z publicznymi punktami końcowymi są potencjalnym obszarem ataków i muszą być wzmocnione.

Brama pomaga rozwiązać te problemy przez oddzielenie klientów od usług. Bramy mogą wykonywać wiele różnych funkcji i mogą nie być potrzebne. Funkcje można zgrupować w następujące wzorce projektowe:

Routing bramy. Użyj bramy jako zwrotnego serwera proxy, aby kierować żądania do co najmniej jednej usługi zaplecza przy użyciu routingu warstwy 7. Brama zapewnia pojedynczy punkt końcowy dla klientów i pomaga rozdzielić klientów z usług.

Agregacja bramy. Brama służy do agregowania wielu pojedynczych żądań w jednym żądaniu. Ten wzorzec ma zastosowanie, gdy jedna operacja wymaga wywołań do wielu usług zaplecza. Klient wysyła jedno żądanie do bramy. Brama wysyła żądania do różnych usług zaplecza, a następnie agreguje wyniki i wysyła je z powrotem do klienta. Pomaga to zmniejszyć czatność między klientem a zapleczem.

Odciążanie bramy. Użyj bramy, aby odciążyć funkcje z poszczególnych usług do bramy, szczególnie w przypadku problemów obejmujących krzyżowe. Może być przydatne skonsolidowanie tych funkcji w jednym miejscu, a nie tworzenie każdej usługi odpowiedzialnej za ich implementację. Dotyczy to szczególnie funkcji wymagających wyspecjalizowanych umiejętności w celu poprawnego wdrożenia, takich jak uwierzytelnianie i autoryzacja.

Poniżej przedstawiono kilka przykładów funkcji, które można odciążyć do bramy:

  • Kończenie żądań protokołu SSL
  • Uwierzytelnianie
  • Lista dozwolonych adresów IP lub lista zablokowanych
  • Ograniczanie szybkości klienta (ograniczanie)
  • Rejestrowanie i monitorowanie
  • Buforowanie odpowiedzi
  • Zapora aplikacji internetowej
  • Kompresja GZIP
  • Obsługa zawartości statycznej

Wybieranie technologii bramy

Poniżej przedstawiono kilka opcji implementowania bramy interfejsu API w aplikacji.

  • Zwrotny serwer proxy. Serwery Nginx i HAProxy to popularne serwery zwrotnego serwera proxy, które obsługują funkcje, takie jak równoważenie obciążenia, protokół SSL i routing warstwy 7. Są to zarówno bezpłatne produkty typu open source, jak i płatne wersje, które udostępniają dodatkowe funkcje i opcje pomocy technicznej. Produkty Nginx i HAProxy są zarówno dojrzałymi produktami z bogatymi zestawami funkcji i wysoką wydajnością. Można je rozszerzyć za pomocą modułów innych firm lub pisząc skrypty niestandardowe w usłudze Lua. Serwer Nginx obsługuje również oparty na języku JavaScript moduł skryptowy nazywany językiem JavaScript NGINX. Ten moduł został formalnie nazwany nginScript.

  • Kontroler ruchu przychodzącego siatki usługi. Jeśli używasz siatki usług, takiej jak Linkerd lub Istio, rozważ funkcje udostępniane przez kontroler ruchu przychodzącego dla tej siatki usług. Na przykład kontroler ruchu przychodzącego Istio obsługuje routing warstwy 7, przekierowania HTTP, ponawianie prób i inne funkcje.

  • aplikacja systemu Azure Gateway. Application Gateway to zarządzana usługa równoważenia obciążenia, która może wykonywać routing warstwy 7 i kończenie żądań SSL. Zapewnia również zaporę aplikacji internetowej (WAF).

  • Usługa Azure Front Door to nowoczesna usługa Content Delivery Network (CDN) firmy Microsoft, która zapewnia szybki, niezawodny i bezpieczny dostęp między użytkownikami a statyczną i dynamiczną zawartością internetową aplikacji na całym świecie. Usługa Azure Front Door dostarcza twoją zawartość przy użyciu globalnej sieci brzegowej firmy Microsoft z setkami globalnych i lokalnych punktów obecności (PoPs) dystrybuowanych na całym świecie w pobliżu zarówno użytkowników końcowych przedsiębiorstwa, jak i konsumentów.

  • Azure API Management. Usługa API Management to gotowe rozwiązanie do publikowania interfejsów API dla klientów zewnętrznych i wewnętrznych. Udostępnia ona funkcje przydatne do zarządzania publicznym interfejsem API, w tym ograniczanie szybkości, ograniczenia adresów IP i uwierzytelnianie przy użyciu identyfikatora Entra firmy Microsoft lub innych dostawców tożsamości. Usługa API Management nie wykonuje żadnego równoważenia obciążenia, dlatego powinna być używana w połączeniu z modułem równoważenia obciążenia, takim jak usługa Application Gateway lub zwrotny serwer proxy. Aby uzyskać informacje na temat korzystania z usługi API Management z usługą Application Gateway, zobacz Integrowanie usługi API Management w wewnętrznej sieci wirtualnej z usługą Application Gateway.

Podczas wybierania technologii bramy należy wziąć pod uwagę następujące kwestie:

Funkcje. Opcje wymienione powyżej obsługują routing warstwy 7, ale obsługa innych funkcji będzie się różnić. W zależności od potrzebnych funkcji można wdrożyć więcej niż jedną bramę.

Wdrożenie. aplikacja systemu Azure Gateway i API Management to usługi zarządzane. Serwery Nginx i HAProxy są zwykle uruchamiane w kontenerach wewnątrz klastra, ale mogą być również wdrażane na dedykowanych maszynach wirtualnych spoza klastra. W ten sposób brama jest odizolowana od reszty obciążenia, ale wiąże się z większym obciążeniem związanych z zarządzaniem.

Zarządzanie. Po zaktualizowaniu usług lub dodaniu nowych usług może być konieczne zaktualizowanie reguł routingu bramy. Rozważ sposób zarządzania tym procesem. Podobne zagadnienia dotyczą zarządzania certyfikatami SSL, listami dozwolonymi adresów IP i innymi aspektami konfiguracji.

Wdrażanie serwera Nginx lub haProxy na platformie Kubernetes

Można wdrożyć serwer Nginx lub haProxy na platformie Kubernetes jako zestaw replik lub zestaw daemonSet , który określa obraz kontenera Nginx lub HAProxy. Użyj obiektu ConfigMap, aby zapisać plik konfiguracji serwera proxy i zainstalować element ConfigMap jako wolumin. Utwórz usługę typu LoadBalancer, aby uwidocznić bramę za pośrednictwem usługi Azure Load Balancer.

Alternatywą jest utworzenie kontrolera ruchu przychodzącego. Kontroler ruchu przychodzącego to zasób Kubernetes, który wdraża moduł równoważenia obciążenia lub zwrotny serwer proxy. Istnieje kilka implementacji, w tym Nginx i HAProxy. Oddzielny zasób o nazwie Ruch przychodzący definiuje ustawienia kontrolera ruchu przychodzącego, takie jak reguły routingu i certyfikaty TLS. W ten sposób nie trzeba zarządzać złożonymi plikami konfiguracji specyficznymi dla określonej technologii serwera proxy.

Brama jest potencjalnym wąskim gardłem lub pojedynczym punktem awarii w systemie, więc zawsze wdrażaj co najmniej dwie repliki w celu zapewnienia wysokiej dostępności. W zależności od obciążenia może być konieczne dalsze skalowanie replik w poziomie.

Rozważ również uruchomienie bramy w dedykowanym zestawie węzłów w klastrze. Korzyści z tego podejścia obejmują:

  • Izolacja. Cały ruch przychodzący jest kierowany do stałego zestawu węzłów, który można odizolować od usług zaplecza.

  • Stabilna konfiguracja. Jeśli brama jest nieprawidłowo skonfigurowana, cała aplikacja może stać się niedostępna.

  • Wydajność Ze względu na wydajność bramy warto użyć określonej konfiguracji maszyny wirtualnej.

Następne kroki

Poprzednie artykuły przejrzały interfejsy między mikrousługami lub między mikrousługami a aplikacjami klienckimi. Zgodnie z projektem te interfejsy traktują każdą usługę jako nieprzezroczyste pole. W szczególności mikrousługi nigdy nie powinny ujawniać szczegółów implementacji dotyczących sposobu zarządzania danymi. Ma to wpływ na integralność danych i spójność danych, o których mowa w następnym artykule.