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? Jak usługi obsługują kończenie żądań SSL, wzajemne protokoły TLS, uwierzytelnianie i inne problemy? Brama interfejsu API może pomóc w rozwiązywaniu tych problemów.
diagram 
Pobierz plik programu Visio tej architektury.
Co to jest brama interfejsu API?
Brama interfejsu API zapewnia scentralizowany punkt wejścia do zarządzania interakcjami między klientami i usługami aplikacji. Działa jako zwrotny serwer proxy i kieruje żądania klientów do odpowiednich usług. Może również wykonywać różne zadania krzyżowe, takie jak uwierzytelnianie, kończenie żądań SSL, wzajemne protokoły TLS i ograniczanie szybkości.
Dlaczego warto używać bramy interfejsu API?
Brama interfejsu API upraszcza komunikację, zwiększa interakcje klientów i centralizuje zarządzanie typowymi obowiązkami na poziomie usług. Działa jako pośrednik i zapobiega bezpośredniemu narażeniu usług aplikacji na klientów. Bez bramy interfejsu API klienci muszą komunikować się bezpośrednio z poszczególnymi usługami aplikacji, co może powodować następujące wyzwania:
złożony kod klienta: może to spowodować złożony kod klienta. Klienci muszą śledzić wiele punktów końcowych i obsługiwać awarie w sposób odporny.
ścisłe sprzęganie: tworzy sprzężenie między klientem a zapleczem. Klienci muszą zrozumieć dekompozycję poszczególnych usług, komplikując konserwację usług i refaktoryzację.
zwiększone opóźnienie: pojedyncza operacja może wymagać wywołań wielu usług. Wynikiem może być wiele rund sieci między klientem a serwerem, dodając znaczne opóźnienie.
Nadmiarowa obsługa problemów: Każda publiczna usługa musi obsługiwać takie problemy jak uwierzytelnianie, protokół SSL i ograniczanie szybkości klientów.
Ograniczenia protokołu: usługi muszą uwidocznić przyjazny dla klienta protokół, taki jak HTTP lub WebSocket. To narażenie ogranicza protokołów komunikacyjnych opcji.
rozszerzoną powierzchnię ataków: publiczne punkty końcowe zwiększają potencjalną powierzchnię ataków i wymagają wzmacniania zabezpieczeń.
Jak używać bramy interfejsu API
Brama interfejsu API może być dostosowana do wymagań aplikacji przy użyciu określonych wzorców projektowych. Te wzorce projektowe dotyczą kluczowych funkcji, takich jak routing, agregacja żądań i zagadnienia dotyczące krzyżowego cięcia:
routingu bramy. Bramę interfejsu API można używać jako zwrotnego serwera proxy do kierowania żądań klientów do różnych usług aplikacji. Brama interfejsu API używa routingu w warstwie 7 i udostępnia pojedynczy punkt końcowy dla klientów do użycia. Użyj routingu bramy interfejsu API, jeśli chcesz rozdzielić klientów z usług aplikacji.
agregacji bramy. Brama interfejsu API umożliwia agregowanie wielu żądań klientów w jednym żądaniu. Użyj tego wzorca, gdy pojedyncza operacja wymaga wywołań do wielu usług aplikacji. W agregacji interfejsu API klient wysyła jedno żądanie do bramy interfejsu API. Następnie brama interfejsu API kieruje żądania do różnych usług wymaganych dla operacji. Na koniec brama interfejsu API agreguje wyniki i wysyła je z powrotem do klienta. Agregacja pomaga zmniejszyć liczbę rozmów między klientem a usługami aplikacji.
odciążanie bramy. Brama interfejsu API umożliwia udostępnianie funkcji krzyżowych, dzięki czemu poszczególne usługi nie muszą jej udostępniać. Może być przydatne skonsolidowanie funkcji krzyżowych w jednym miejscu, a nie tworzenie każdej usługi odpowiedzialnej. Oto przykłady funkcji, które można odciążyć do bramy interfejsu API:
- Kończenie żądań SSL
- Wzajemne protokoły TLS
- 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
Opcje bramy interfejsu API
Poniżej przedstawiono kilka opcji implementowania bramy interfejsu API w aplikacji.
odwrotnego serwera proxy. Serwery Nginx i HAProxy to oferty zwrotnego serwera proxy typu open source. Obsługują one funkcje, takie jak równoważenie obciążenia, kończenie żądań SSL i routing w warstwie 7. Mają bezpłatne wersje i płatne wersje, które zapewniają dodatkowe funkcje i opcje pomocy technicznej. Te produkty są dojrzałe dzięki rozbudowanym zestawom funkcji, wysokiej wydajności i rozszerzalności.
kontroler ruchu przychodzącego siatki usługi. Jeśli używasz siatki usługi, oceń funkcje kontrolera ruchu przychodzącego specyficzne dla tej siatki usług. Sprawdź dodatki obsługiwane przez usługę AKS, takie jak Istio i Open Service Mesh. Poszukaj projektów open source innych firm, takich jak Linkerd lub Consul Connect. Na przykład kontroler ruchu przychodzącego Istio obsługuje routing warstwy 7, przekierowania HTTP, ponawianie prób i inne funkcje.
usługi Azure Application Gateway. Application Gateway to zarządzana usługa równoważenia obciążenia. Zapewnia on routing warstwy 7, kończenie żądań SSL i zaporę aplikacji internetowej (WAF).
usługi Azure Front Door. Usługa Azure Front Door to sieć dostarczania zawartości (CDN). Używa ona globalnych i lokalnych punktów obecności (PoPs), aby zapewnić szybki, niezawodny i bezpieczny dostęp do statycznej i dynamicznej zawartości internetowej aplikacji globalnie.
usługi Azure API Management. Usługa API Management to zarządzane rozwiązanie do publikowania interfejsów API dla klientów zewnętrznych i wewnętrznych. Udostępnia ona funkcje do zarządzania publicznymi interfejsami API, w tym ograniczaniem szybkości, ograniczeniami adresów IP i uwierzytelnianiem 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 należy używać go z modułem równoważenia obciążenia, takim jak usługa Azure Application Gateway lub zwrotny serwer proxy. Aby uzyskać informacje, zobacz API Management z usługą Azure Application Gateway.
Wybieranie technologii bramy interfejsu API
Podczas wybierania bramy interfejsu API należy wziąć pod uwagę następujące czynniki:
Obsługa wszystkich wymagań. Wybierz bramę interfejsu API, która obsługuje wymagane funkcje. Wszystkie poprzednie opcje bramy interfejsu API obsługują routing w warstwie 7. Jednak ich obsługa innych funkcji, takich jak uwierzytelnianie, ograniczanie szybkości i kończenie żądań SSL, może się różnić. Oceń, czy pojedyncza brama spełnia Twoje potrzeby, czy też jest wymagana wiele bram.
Preferuj wbudowane oferty. Używaj wbudowanych rozwiązań bramy interfejsu API i ruchu przychodzącego udostępnianych przez platformę, takich jak Azure Container Apps i AKS, za każdym razem, gdy spełniają wymagania dotyczące zabezpieczeń i kontroli. Użyj bramy niestandardowej tylko wtedy, gdy wbudowane opcje nie mają niezbędnej elastyczności. Rozwiązania niestandardowe wymagają modelu ładu, takiego jak GitOps, w celu efektywnego zarządzania cyklem życia.
Wybierz odpowiedni model wdrażania. Użyj usług zarządzanych, takich jak Azure Application Gateway i Azure API Management, aby zmniejszyć obciążenie operacyjne. Jeśli używasz serwerów proxy odwrotnego przeznaczenia ogólnego przeznaczenia lub modułów równoważenia obciążenia, wdróż je w sposób zgodny z architekturą. Bramy interfejsu API ogólnego przeznaczenia można wdrożyć na dedykowanych maszynach wirtualnych lub w klastrze usługi AKS w swoich ofertach kontrolera ruchu przychodzącego. Aby odizolować bramę interfejsu API od obciążenia, można wdrożyć je poza klastrem, ale to wdrożenie zwiększa złożoność zarządzania.
Zarządzanie zmianami. Podczas aktualizowania usług lub dodawania nowych może być konieczne zaktualizowanie reguł routingu bramy. Implementowanie procesów lub przepływów pracy w celu zarządzania regułami routingu podczas dodawania lub modyfikowania usług, certyfikatów SSL, list dozwolonych adresów IP i konfiguracji zabezpieczeń. Użyj narzędzi infrastruktury jako kodu i automatyzacji, aby usprawnić zarządzanie bramami interfejsu API.
Następne kroki
W poprzednich artykułach omówiono interfejsy między mikrousługami i między mikrousługami a aplikacjami klienckimi. Te interfejsy traktują każdą usługę jako samodzielną, nieprzezroczystą jednostkę. Krytyczną zasadą architektury mikrousług jest to, że usługi nigdy nie powinny ujawniać wewnętrznych szczegółów dotyczących sposobu zarządzania danymi. Takie podejście ma znaczący wpływ na utrzymanie integralności i spójności danych, co jest przedmiotem następnego artykułu.
Powiązane zasoby
- interfejsy API projektowania dla mikrousług
- Projektowanie architektury mikrousług
- Używanie analizy domeny do modelowania mikrousług
- ocena i gotowość mikrousług