Oddzielenie 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 jest oparty na wzorcu : zaplecza dla frontonów opisanych przez Sam Newman.
Kontekst i problem
Rozważmy aplikację, która została początkowo zaprojektowana przy użyciu internetowego interfejsu użytkownika pulpitu i odpowiedniej usługi zaplecza. Wraz ze zmianą wymagań biznesowych w miarę upływu czasu dodano interfejs mobilny. Oba interfejsy współdziałają z tą samą usługą zaplecza, ale 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.
Usługa zaplecza często napotyka konkurencyjne wymagania od różnych frontonów, co prowadzi do częstych zmian i potencjalnych wąskich gardeł w procesie programowania. Powodujące konflikty aktualizacje i konieczność zachowania zgodności powodują nadmierną pracę nad pojedynczym zasobem, który można wdrożyć.
Posiadanie oddzielnego zespołu zarządzającego usługą zaplecza może utworzyć rozłączenie między zespołami frontonu i zaplecza, co powoduje 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 nazywana usługą zaplecza dla frontonu (BFF) znajduje się między klientem frontonu a usługą zaplecza. Jeśli aplikacja obsługuje wiele interfejsów, utwórz usługę BFF dla każdego interfejsu. Jeśli na przykład masz interfejs internetowy i aplikację mobilną, utworzysz oddzielne usługi BFF dla każdego z nich.
Ten wzorzec dostosowuje środowisko klienta dla określonego interfejsu bez wpływu na inne interfejsy. Dopasuj również wydajność, aby najlepiej dopasować się do potrzeb środowiska frontonu. Ponieważ każda usługa BFF jest mniejsza i mniej złożona, aplikacja może doświadczyć korzyści optymalizacji w pewnym stopniu.
Zespoły frontonu mają autonomię nad własną usługą BFF, umożliwiając elastyczność wyboru języka, cykli wdrażania, priorytetyzacji obciążeń i integracji funkcji bez polegania na scentralizowanym zespole deweloperów zaplecza.
Chociaż wiele plików BFFs polegało na interfejsach API REST, implementacje graphQL stają się alternatywą, co eliminuje potrzebę warstwy BFF, ponieważ mechanizm wykonywania zapytań nie wymaga oddzielnego punktu końcowego.
Aby uzyskać więcej informacji, zobacz wzorzec : zaplecza dla frontonów.
Problemy i zagadnienia
Oceń optymalną liczbę usług, ponieważ będzie to miało powiązane koszty. 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ń.
Zapoznaj się z celami poziomu usług (SLO) podczas dodawania nowej usługi. Może wystąpić zwiększone opóźnienie, ponieważ klienci nie kontaktuje się bezpośrednio z usługami, a nowa usługa wprowadza dodatkowy przeskok 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 prowadzić do różnych wymagań dla każdego klienta, co może komplikować rozwój 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 wycinania krzyżowego, takie jak monitorowanie i autoryzacja, powinny być abstrakcje, aby zachować światło usługi BFF. Typowe funkcje, które mogą występować w usłudze BFF, są obsługiwane oddzielnie z gatekeeping, ograniczanie szybkości, Routingi inne.
Podczas uczenia się i implementowania tego wzorca należy wziąć pod uwagę wpływ zespołu deweloperów. Tworzenie nowych zapleczy wymaga czasu i nakładu pracy, co potencjalnie wiąże się z długiem technicznym przy zachowaniu istniejącej usługi zaplecza.
Oceń, czy ten wzorzec jest w ogóle potrzebny. Jeśli na przykład twoja organizacja używa języka GraphQL z narzędziami rozpoznawania specyficznymi dla frontonu, usługa BFF może nie dodawać wartości do aplikacji.
Innym przykładem jest aplikacja łącząca usługi API Gateway z mikrousługami. Takie podejście może być wystarczające w niektórych przypadkach, w których wcześniej zalecane były funkcje BFF.
Kiedy należy używać tego wzorca
Użyj tego wzorca, gdy:
Usługa zaplecza współużytkowanego lub ogólnego przeznaczenia musi być utrzymywana z dużym obciążeniem programistycznym.
Chcesz zoptymalizować zaplecze pod kątem wymagań określonych interfejsów klienta.
Dostosowania są wprowadzane do zaplecza ogólnego przeznaczenia w celu obsługi 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 być nieodpowiedni w następujących przypadkach:
Gdy interfejsy wysyłają te same lub podobne żądania do zaplecza.
Gdy tylko jeden interfejs jest używany do interakcji z zapleczem.
Projekt obciążenia
Architekt powinien ocenić, jak wzorzec zaplecza dla frontonów może być używany w projekcie obciążenia w celu rozwiązania celów i zasad omówionych w filarach platformy Azure Well-Architected Azure Well-Architected Framework. Na przykład:
| Filar | Jak ten wzorzec obsługuje cele filaru |
|---|---|
| Decyzje projektowe dotyczące niezawodności pomagają obciążeniu stać się odporne na awarię i zapewnić, że zostanie przywrócony do w pełni funkcjonalnego stanu po wystąpieniu awarii. | Posiadanie oddzielnych usług, które są wyłączne dla określonego interfejsu frontonu, zawiera awarie, dzięki czemu dostępność jednego klienta może nie mieć wpływu na dostępność dostępu innego klienta. Ponadto 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 Self-preservation |
| Decyzje dotyczące projektowania zabezpieczeń pomagają zapewnić poufność, integralność i dostępność danych i systemów obciążenia. | Ze względu na separację usług wprowadzoną w tym wzorcu zabezpieczenia i autoryzacja w warstwie usługi obsługującej jednego klienta mogą być dostosowane do funkcji wymaganych przez tego klienta, co może potencjalnie zmniejszyć obszar powierzchni interfejsu API i penetracji między różnymi zapleczami, które mogą uwidocznić różne możliwości. - SE:04 Segmentation - SE:08 Wzmacnianie zabezpieczeń zasobów |
| Wydajność pomagawydajnie sprostać zapotrzebowaniu dzięki optymalizacjom skalowania, danych, 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 Krytyczne przepływy |
Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.
Przykład
W tym przykładzie pokazano przypadek użycia dla wzorca, w którym masz dwie odrębne aplikacje klienckie: aplikację mobilną i aplikację klasyczną. Obaj klienci wchodzą w interakcje z usługą Azure API Management (bramą płaszczyzny danych), która działa jako warstwa abstrakcji, obsługując typowe problemy związane z wycinaniem krzyżowym, takie jak:
Authorization — zapewnienie, że tylko zweryfikowane tożsamości z odpowiednimi tokenami dostępu mogą wywoływać chronione zasoby przy użyciu usługi Azure API Management (APIM) z identyfikatorem Entra firmy Microsoft.
monitorowanie — przechwytywanie i wysyłanie szczegółów żądania i odpowiedzi na potrzeby obserwacji w usłudze Azure Monitor.
buforowanie żądań — optymalizowanie powtarzających się żądań przez obsługę odpowiedzi z pamięci podręcznej przy użyciu wbudowanych funkcji usługi APIM.
Routing & Agregacja — kierowanie żądań przychodzących do odpowiedniego zaplecza dla usług frontonu (BFF).
Każdy klient ma dedykowaną usługę BFF działającą jako funkcja platformy Azure, która pełni rolę pośrednika między bramą a bazowymi mikrousługami. Te specyficzne dla klienta BFF zapewniają dostosowane środowisko stronicowania między innymi funkcjami. Chociaż aplikacja mobilna jest bardziej świadoma przepustowości i buforowanie poprawia wydajność, pulpit agreguje wiele stron w jednym żądaniu, optymalizując pod kątem bogatszego środowiska użytkownika.
Diagram ma strukturę czterech odrębnych sekcji, ilustrujących przepływ żądań, uwierzytelniania, monitorowania i przetwarzania specyficznego dla klienta. Po lewej stronie 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ą oferującą w pełni funkcjonalny interfejs. Strzałki rozciągają się od obu urządzeń w kierunku centralnego punktu wejścia, który jest bramą usługi Azure API Management, wskazując, ż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ę Azure API Management, odpowiedzialną za obsługę żądań przychodzących i określanie sposobu ich przetwarzania. Dwie strzałki rozciągają się na zewnątrz z tej bramy płaszczyzny danych: jeden wskazujący w górę do identyfikatora Entra firmy Microsoft, który zarządza autoryzacją, a drugi wskazuje w dół do usługi Azure Monitor, która jest odpowiedzialna za rejestrowanie i obserwowanie. Ponadto strzałka powraca z bramy do klienta mobilnego, reprezentując buforowana odpowiedź, gdy identyczne żądanie jest powtarzane, co zmniejsza niepotrzebne przetwarzanie. Właściwa grupa w prostokątze przerywanym koncentruje się na dostosowywaniu odpowiedzi zaplecza na podstawie typu klienta wysyłającego żądanie. Oferuje ona dwóch oddzielnych klientów zaplecza dla frontonu, zarówno hostowanych przy użyciu usługi Azure Functions na potrzeby przetwarzania bezserwerowego — jednego dedykowanego klientowi mobilnemu, jak i drugiemu klientowi pulpitu. Dwie strzałki rozciągają się od bramy do tych klientów zaplecza dla frontonu, co pokazuje, że każde żądanie przychodzące jest przekazywane do odpowiedniej usługi w zależności od typu klienta. Poza tą warstwą strzałki kreskowane rozszerzają się dalej po prawej stronie, łącząc klientów zaplecza dla frontonu z różnymi mikrousługami, które obsługują rzeczywistą logikę biznesową. Aby zwizualizować ten diagram, wyobraź sobie przepływ od lewej do prawej, w którym żądania klientów przechodzą 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 zaplecza dla frontonu przekazuje żądanie do wyspecjalizowanych mikrousług, które wykonują wymaganą logikę biznesową i zwracają niezbędną odpowiedź. Jeśli jest dostępna buforowana odpowiedź, brama przechwytuje żądanie i wysyła przechowywaną odpowiedź bezpośrednio do klienta mobilnego, uniemożliwiając nadmiarowe przetwarzanie.
Flow A: Klient mobilny — żądanie pierwszej strony
- Klient mobilny wysyła żądanie
GETdla strony1łącznie z tokenem OAuth 2.0 w nagłówku autoryzacji. - Żądanie dociera do bramy azure APIM Gateway, która przechwytuje je i:
- Sprawdza stan autoryzacji — usługa APIM implementuje ochronę w głębi systemu, dzięki czemu sprawdza poprawność tokenu dostępu.
- Przesyłanie strumieniowe aktywności żądania jako dzienników do usługi Azure Monitor — szczegóły żądania są rejestrowane na potrzeby inspekcji i monitorowania.
- Zasady są wymuszane, a następnie usługa Azure APIM kieruje żądanie do usługi Azure Function Mobile BFF.
- Usługa Azure Function Mobile BFF współdziała następnie z niezbędnymi mikrousługami, aby pobrać jedną stronę i przetworzyć żądane dane w celu zapewnienia lekkiego środowiska.
- Odpowiedź jest zwracana do klienta.
Przepływ B: Klient mobilny — żądanie buforowane na pierwszej stronie
- Klient mobilny wysyła to samo żądanie
GETdla strony1ponownie, w tym token OAuth 2.0 w nagłówku autoryzacji. - Usługa Azure APIM Gateway rozpoznaje, że to żądanie zostało wykonane przed i:
- Zasady są wymuszane i po nim identyfikuje buforowana odpowiedź zgodną z parametrami żądania.
- Zwraca natychmiast buforowana odpowiedź, eliminując konieczność przekazywania żądania do usługi Azure Function Mobile BFF.
Flow C: Klient pulpitu — pierwsze żądanie
- Klient pulpitu wysyła żądanie
GETpo raz pierwszy, w tym token OAuth 2.0 w nagłówku autoryzacji. - Żądanie dociera do usługi Azure APIM Gateway, w której są obsługiwane podobne problemy dotyczące krzyżowania:
- Autoryzacja — weryfikacja tokenu jest zawsze wymagana.
- Przesyłanie strumieniowe działania żądania — szczegóły żądania są rejestrowane w celu obserwowania.
- Po wymusieniu wszystkich zasad usługa Azure APIM kieruje żądanie do BFF pulpitu funkcji platformy Azure, który jest odpowiedzialny za obsługę przetwarzania aplikacji z dużą liczbą danych. Program Desktop BFF agreguje wiele żądań przy użyciu podstawowych wywołań mikrousług przed odpowiedzią na klienta z odpowiedzią na wiele stron.
Projektowanie
microsoft Entra ID służy jako dostawca tożsamości oparty na chmurze, wystawiając dostosowane oświadczenia odbiorców zarówno dla klientów mobilnych, jak i stacjonarnych, które następnie są używane do autoryzacji.
usługa Azure API Management działa jako serwer proxy między klientami i ich bbFs dodając obwód. Jest ona skonfigurowana przy użyciu zasad w celu weryfikowania tokenów sieci Web JSON (JWTs), odrzucanie żądań, które docierają bez tokenu lub oświadczenia nie są prawidłowe dla docelowej usługi BFF. Ponadto przesyła strumieniowo wszystkie dzienniki aktywności do usługi Azure Monitor.
usługa Azure Monitor działa jako scentralizowane rozwiązanie do monitorowania, agregując wszystkie dzienniki aktywności w celu zapewnienia kompleksowej możliwości obserwacji.
usługa Azure Functions to rozwiązanie bezserwerowe, które bezproblemowo uwidacznia logikę BFF w wielu punktach końcowych, co umożliwia usprawnione programowanie, zmniejsza obciążenie infrastrukturą i obniża koszty operacyjne.
Następne kroki
- wzorzec : zaplecza dla frontonów
Powiązane zasoby
- Wzorzec agregacji bramy
- Wzorzec odciążania bramy
- Wzorzec routingu bramy
- Uwierzytelnianie i autoryzacja do interfejsów API w usłudze Azure API Management
- Jak zintegrować usługę Azure API Management z usługą Azure Application Insights
- architektura referencyjna bezserwerowej aplikacji internetowej