Wzorce zaplecza dla frontonów

W tym wzorcu opisano sposób oddzielenia usług zaplecza od implementacji frontonu w celu dostosowania środowisk dla różnych interfejsów klienta. Ten wzorzec jest przydatny, gdy chcesz uniknąć dostosowywania zaplecza obsługującego wiele interfejsów. Ten wzorzec oparty jest na wzorcu Backends for Frontends autorstwa Sam Newmana.

Kontekst i problem

Rozważ aplikację, która jest początkowo zaprojektowana z interfejsem użytkownika dla aplikacji desktopowej i odpowiednią usługą backendową. W miarę zmiany wymagań biznesowych w miarę upływu czasu jest dodawany interfejs mobilny. Oba interfejsy współdziałają z tą samą usługą zaplecza. Jednak możliwości urządzenia przenośnego różnią się znacząco od przeglądarki klasycznej pod względem rozmiaru ekranu, wydajności i ograniczeń wyświetlania.

Diagram zawiera dwie sekcje: usługę zaplecza oraz klienta stacjonarnego i klienta mobilnego. Dwie dwukierunkowe strzałki wskazują od usługi zaplecza do klienta stacjonarnego i klienta mobilnego.

Usługa backendowa często spotyka konkurujące wymagania z wielu systemów frontendowych. Te wymagania powodują częste aktualizacje i potencjalne wąskie gardła programistyczne. Powodujące konflikty aktualizacje i konieczność zachowania zgodności powodują nadmierne zapotrzebowanie na pojedynczy zasób możliwy do wdrożenia.

Posiadanie oddzielnego zespołu zarządzającego usługą zaplecza może utworzyć rozłączenie między zespołami frontonu i zaplecza. To rozłączenie może spowodować opóźnienia w uzyskaniu konsensusu i równoważenia wymagań. Na przykład zmiany żądane przez jeden zespół frontonu muszą zostać zweryfikowane z innymi zespołami frontonu przed integracją.

Rozwiązanie

Wprowadzenie nowej warstwy obsługującej tylko wymagania specyficzne dla interfejsu. Ta warstwa, znana jako usługa zaplecza dla frontonu (BFF), znajduje się między klientem frontonu a usługą zaplecza. Jeśli aplikacja obsługuje wiele interfejsów, takich jak interfejs internetowy i aplikacja mobilna, utwórz usługę BFF dla każdego interfejsu.

Ten wzorzec dostosowuje środowisko klienta dla określonego interfejsu bez wpływu na inne interfejsy. Optymalizuje również wydajność pod kątem potrzeb środowiska frontendowego. Ponieważ każda usługa BFF jest mniejsza i mniej złożona niż udostępniona usługa zaplecza, może ułatwić zarządzanie aplikacją.

Zespoły frontonu niezależnie zarządzają własną usługą BFF, która zapewnia im kontrolę nad wyborem języka, cyklem wydania, priorytetyzacją obciążeń i integracją funkcji. Ta autonomia umożliwia efektywne działanie bez zależności od scentralizowanego zespołu do tworzenia oprogramowania zaplecza.

Wiele usług BFF tradycyjnie polegało na interfejsach API REST, ale implementacje graphQL pojawiają się jako alternatywa. W przypadku języka GraphQL mechanizm wykonywania zapytań eliminuje konieczność użycia oddzielnej warstwy BFF, ponieważ umożliwia klientom żądanie potrzebnych danych bez polegania na wstępnie zdefiniowanych punktach końcowych.

Diagram przedstawia trzy sekcje. Pierwsza sekcja składa się z klienta klasycznego i klienta mobilnego. Druga sekcja obejmuje usługę BFF dla klienta komputerowego oraz usługę BFF dla klienta mobilnego. Klient pulpitu ma solidną strzałkę wskazującą usługę BFF klienta pulpitu. Klient mobilny ma solidną strzałkę wskazującą usługę BFF klienta mobilnego. Każda usługa BFF ma kropkowaną strzałkę wskazującą sekcję usługi zaplecza.

Aby uzyskać więcej informacji, zobacz wzorzec Backends for Frontends autorstwa Sama Newmana.

Problemy i zagadnienia

• Oceń optymalną liczbę usług w zależności od powiązanych kosztów. Utrzymywanie i wdrażanie większej liczby usług oznacza zwiększenie nakładu pracy operacyjnej. Każda usługa ma własny cykl życia, wymagania dotyczące wdrażania i konserwacji oraz wymagania dotyczące zabezpieczeń.

• Przejrzyj cele poziomu usług podczas dodawania nowej usługi. Może wystąpić zwiększone opóźnienie, ponieważ klienci nie kontaktują się bezpośrednio z waszymi usługami, a nowa usługa wprowadza dodatkowy skok sieciowy.

• Gdy różne interfejsy wysyłają te same żądania, oceń, czy żądania można skonsolidować w jedną usługę BFF. Udostępnianie jednej usługi BFF między wieloma interfejsami może spowodować różne wymagania dla każdego klienta, co może skomplikować wzrost i obsługę usługi BFF.

  Duplikowanie kodu jest prawdopodobnym wynikiem tego wzorca. Oceń kompromis między duplikacją kodu a lepszym dostosowanym środowiskiem dla każdego klienta.

• Usługa BFF powinna obsługiwać tylko logikę specyficzną dla klienta związaną z określonym środowiskiem użytkownika. Funkcje przekrojowe, takie jak monitorowanie i autoryzacja, powinny być abstrahowane, aby utrzymać wydajność. Typowe funkcje w usłudze BFF są obsługiwane oddzielnie za pomocą wzorców kontroli dostępu, ograniczania szybkości i trasowania.

• Zastanów się, jak uczenie się i implementowanie tego wzorca wpływa na zespół deweloperów. Opracowywanie nowych systemów zaplecza wymaga czasu i nakładu pracy, co może spowodować dług techniczny. Utrzymanie istniejącej usługi zaplecza potęguje to wyzwanie.

• Oceń, czy ten wzorzec jest potrzebny. Jeśli na przykład twoja organizacja używa języka GraphQL z narzędziami rozpoznawania specyficznymi dla frontonu, usługi BFF mogą nie dodawać wartości do aplikacji.

  Innym scenariuszem jest aplikacja łącząca bramę interfejsu API z mikrousługami. Takie podejście może być wystarczające w przypadku niektórych scenariuszy, w których usługi BFF są zwykle zalecane.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

• Usługa zaplecza współużytkowanego lub ogólnego przeznaczenia wymaga znacznego nakładu pracy w celu jej utrzymania.

• Chcesz zoptymalizować zaplecze pod kątem wymagań określonych interfejsów klienta.

• Wprowadzasz dostosowania do zaplecza ogólnego przeznaczenia, aby dostosować je do wielu interfejsów.

• Język programowania lepiej nadaje się do zaplecza określonego interfejsu użytkownika, ale nie wszystkich interfejsów użytkownika.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

• Interfejsy tworzą te same lub podobne żądania do zaplecza.

• Tylko jeden interfejs współdziała z zapleczem.

Projektowanie obciążenia

Oceń, jak używać wzorca Backends for Frontends w projekcie obciążenia roboczego, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące tego, jak ten wzorzec obsługuje cele poszczególnych filarów.

Filar	Jak ten wzorzec obsługuje cele filaru
Decyzje projektowe dotyczące niezawodności pomagają obciążeniom stały się odporne na awarię i zapewniają, że zostanie ono przywrócone do w pełni funkcjonalnego stanu po wystąpieniu awarii.	Izolując usługi do określonego interfejsu frontendu, ograniczasz występowanie awarii. Dostępność jednego klienta nie ma wpływu na dostępność dostępu innego klienta. W przypadku różnego traktowania różnych klientów można określić priorytety wysiłków związanych z niezawodnością na podstawie oczekiwanych wzorców dostępu klientów. - RE:02 Przepływy krytyczne - RE:07 Instynkt samozachowawczy
Decyzje dotyczące projektowania zabezpieczeń pomagają zapewnić poufność, integralność i dostępność danych i systemów obciążenia.	Separacja usług wprowadzona w tym wzorcu umożliwia dostosowanie zabezpieczeń i autoryzacji w warstwie usługi dla konkretnych potrzeb każdego klienta. Takie podejście może zmniejszyć powierzchnię interfejsu API i ograniczyć przemieszczanie się między zapleczami, które mogą ujawniać różne możliwości. - Segmentacja SE:04 - SE:08 Wzmacnianie zabezpieczeń zasobów
Efektywność wydajności pomaga wydajnie sprostać wymaganiom dzięki optymalizacjom skalowania, danych i kodu.	Separacja zaplecza umożliwia optymalizację pod kątem sposobów, które mogą nie być możliwe w przypadku warstwy usług udostępnionych. W przypadku różnych obsługi poszczególnych klientów można zoptymalizować wydajność pod kątem ograniczeń i funkcjonalności określonego klienta. - PE:02 Planowanie pojemności - PE:09 Przepływy krytyczne

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Przykład

W tym przykładzie pokazano przypadek użycia wzorca, w którym dwie odrębne aplikacje klienckie, aplikacja mobilna i aplikacja klasyczna współdziałają z usługą Azure API Management (brama płaszczyzny danych). Ta brama służy jako warstwa abstrakcji i zarządza typowymi problemami przekrojowymi, takimi jak:

• Autoryzacja. Zapewnia, że tylko zweryfikowane tożsamości z odpowiednimi tokenami dostępu mogą wywoływać chronione zasoby, korzystając z usługi zarządzania API przy użyciu Microsoft Entra ID.

• Monitorowanie. Przechwytuje i wysyła szczegóły żądania i odpowiedzi do usługi Azure Monitor w celu obserwowania.

• Buforowanie żądań. Optymalizuje powtarzające się żądania, obsługując odpowiedzi z pamięci podręcznej przez wbudowane funkcje usługi API Management.

• Routing i agregacja. Kieruje żądania przychodzące do odpowiednich usług BFF.

Każdy klient ma dedykowaną usługę BFF działającą jako funkcję platformy Azure, która służy jako pośrednik między bramą a podstawowymi mikrousługami. Te usługi BFF specyficzne dla klienta zapewniają dostosowane środowisko stronicowania i innych funkcji. Aplikacja mobilna ustala priorytety przepustowości i wykorzystuje buforowanie w celu zwiększenia wydajności. Natomiast aplikacja desktopowa pobiera wiele stron w jednym żądaniu, co tworzy bardziej immersyjne doświadczenie użytkownika.

Diagram jest ustrukturyzowany na cztery sekcje ilustrujące przepływ żądań, uwierzytelniania, monitorowania i przetwarzania specyficznego dla klienta. Dwa urządzenia klienckie inicjują żądania: aplikację mobilną zoptymalizowaną pod kątem wydajnego pod względem przepustowości środowiska użytkownika i przeglądarkę internetową, która zapewnia w pełni funkcjonalny interfejs. Strzałki rozciągają się od obu urządzeń w kierunku centralnego punktu wejścia, czyli bramy usługi API Management, aby wskazać, że wszystkie żądania muszą przechodzić przez tę warstwę. W drugiej sekcji, ujętej w prostokąt liniowy kreskowany, architektura jest podzielona na dwie grupy poziome. Grupa po lewej stronie reprezentuje usługę API Management, która obsługuje żądania przychodzące i określa sposób ich przetwarzania. Dwie strzałki rozciągają się na zewnątrz z tej bramy płaszczyzny danych. Jedna strzałka wskazuje w górę do identyfikatora Entra firmy Microsoft, który zarządza autoryzacją. Kolejna strzałka wskazuje w dół do usługi Azure Monitor, która jest odpowiedzialna za rejestrowanie i obserwowanie. Strzałka wraca z bramy do klienta mobilnego, co reprezentuje buforowaną odpowiedź w przypadku powtórzenia identycznego żądania, co zmniejsza niepotrzebne przetwarzanie. Grupa po prawej stronie w prostokącie przerywanym koncentruje się na dostosowywaniu odpowiedzi serwera na podstawie typu klienta, który składa żądanie. Funkcjonalność obejmuje dwa oddzielne klientów backend-for-frontend, hostowanych przy użyciu Azure Functions do przetwarzania bezserwerowego. Jeden jest przeznaczony dla klienta mobilnego, a drugi do klienta stacjonarnego. Dwie strzałki przechodzą od bramy do tych klientów typu backend-for-frontend, co ilustruje, że każde żądanie przychodzące jest przekazywane do odpowiedniej usługi, w zależności od rodzaju klienta. Poza tą warstwą rozciągają się przerywane strzałki, które łączą klientów backendu dla frontendów z różnymi mikrousługami obsługującymi rzeczywistą logikę biznesową. Obraz przedstawia przepływ od lewej do prawej, w którym żądania klientów są przenoszone z klientów mobilnych i internetowych do bramy. Ta brama przetwarza każde żądanie podczas delegowania uwierzytelniania w górę do dostawcy tożsamości i rejestrowania w dół do usługi monitorowania. Następnie kieruje żądania do odpowiedniego klienta zaplecza dla frontonu na podstawie tego, czy żądanie pochodzi z klienta mobilnego lub stacjonarnego. Na koniec każdy klient backend-for-frontend przekazuje żądanie do wyspecjalizowanych mikrousług, które wykonują wymaganą logikę biznesową i zwracają potrzebną odpowiedź. Jeśli jest dostępna buforowana odpowiedź, brama przechwytuje żądanie i wysyła przechowywaną odpowiedź bezpośrednio do klienta mobilnego, co uniemożliwia nadmiarowe przetwarzanie.

Przepływ A dla pierwszego żądania strony z klienta mobilnego

1. Klient mobilny wysyła GET żądanie dla strony 1, zawierając token OAuth 2.0 w nagłówku autoryzacji.

2. Żądanie dociera do bramy usługi API Management, która je przechwytuje i:

   1. Sprawdza stan autoryzacji. Usługa API Management implementuje ochronę w głębi systemu, dzięki czemu sprawdza poprawność tokenu dostępu.

   2. Przesyła strumieniowo działanie żądania jako dzienniki do usługi Azure Monitor. Szczegółowe informacje o żądaniu są rejestrowane na potrzeby inspekcji i monitorowania.

3. Zasady są wymuszane, a następnie usługa API Management kieruje żądanie do mobilnej usługi BFF funkcji platformy Azure.

4. Usługa mobilna BFF funkcji platformy Azure współdziała następnie z niezbędnymi mikrousługami, aby pobrać jedną stronę i przetworzyć żądane dane w celu zapewnienia lekkiego środowiska.

5. Odpowiedź jest zwracana do klienta.

Przepływ B dla pierwszego buforowanego żądania od klienta mobilnego

1. Klient mobilny wysyła ponownie to samo GET żądanie dla strony 1, umieszczając token OAuth 2.0 w nagłówku autoryzacji.

2. Brama usługi API Management rozpoznaje, że to żądanie zostało wykonane wcześniej i:

   1. Zasady są egzekwowane. Następnie brama identyfikuje buforowana odpowiedź zgodną z parametrami żądania.

   2. Zwraca natychmiast buforowana odpowiedź. Ta szybka odpowiedź eliminuje konieczność przekazywania żądania do mobilnej usługi BFF funkcji Azure.

Przepływ C dla pierwszego żądania od klienta komputerowego

1. Klient desktopowy wysyła po raz pierwszy żądanie GET, w tym token OAuth 2.0 w nagłówku autoryzacji.

2. Żądanie dociera do bramy zarządzania API, gdzie są obsługiwane kwestie wspólne.

   1. Autoryzacja: Weryfikacja tokenu jest zawsze wymagana.

   2. Monitorowanie aktywności żądania: Szczegóły żądania są rejestrowane w celu zapewnienia obserwowalności.

3. Pl-PL: Po wymuszeniu wszystkich zasad, usługa API Management kieruje żądanie do usługi Azure Function Desktop BFF, która obsługuje przetwarzanie aplikacji wymagających dużej ilości danych. Usługa pulpitu BFF agreguje wiele żądań, wykorzystując wywołania mikrousług, zanim przekaże klientowi odpowiedź obejmującą wiele stron.

Projektowanie

• Microsoft Entra ID służy jako dostawca tożsamości oparty na chmurze. Zapewnia dostosowane oświadczenia odbiorców zarówno dla klientów mobilnych, jak i stacjonarnych. Te oświadczenia są następnie używane do autoryzacji.

• Usługa API Management służy jako serwer proxy między klientami a usługami BFF, która ustanawia obwód. Usługa API Management jest skonfigurowana przy użyciu zasad w celu zweryfikowania tokenów sieci Web JSON i odrzuca żądania, które nie zawierają tokenu lub zawierają nieprawidłowe oświadczenia dla docelowej usługi BFF. Przesyła również strumieniowo wszystkie dzienniki aktywności do usługi Azure Monitor.

• Usługa Azure Monitor działa jako scentralizowane rozwiązanie do monitorowania. Agreguje wszystkie dzienniki aktywności, aby zapewnić kompleksową obserwację.

• Azure Functions to rozwiązanie bezserwerowe, które efektywnie uwidacznia logikę usługi BFF w wielu punktach końcowych, co upraszcza programowanie. Usługa Azure Functions minimalizuje również nakłady pracy związane z infrastrukturą i pomaga obniżyć koszty operacyjne.

Dalsze kroki

• Backends for Frontends - wzorzec autorstwa Sama Newmana
• Uwierzytelnianie i autoryzacja interfejsów API w usłudze API Management
• Jak zintegrować usługę API Management z usługą Application Insights

Powiązane zasoby

• Wzorzec agregacji za pomocą bramy
• Wzorzec odciążania bramy
• Wzorzec routingu bramy
• architektura referencyjna bezserwerowej aplikacji internetowej