Tworzenie oddzielnych usług zaplecza do użycia przez określone aplikacje lub interfejsy frontonu. Ten wzorzec jest przydatny, gdy chcemy uniknąć dostosowywania pojedynczego zaplecza dla wielu interfejsów. Wzorzec ten został po raz pierwszy opisany przez Sama Newmana.
Kontekst i problem
Aplikacja może być początkowo przeznaczona dla internetowego interfejsu użytkownika na komputerach. Zazwyczaj równolegle opracowywana jest usługa zaplecza, która udostępnia funkcje niezbędne dla tego interfejsu użytkownika. Wraz ze wzrostem bazy użytkowników aplikacji opracowywana zostaje aplikacja mobilna, który musi współdziałać z tym samym zapleczem. Usługa zaplecza staje się zapleczem ogólnego przeznaczenia, obsługującym wymagania zarówno interfejsu dla komputerów, jak i interfejsu dla urządzeń przenośnych.
Jednak możliwości urządzenia przenośnego różnią się znacznie od przeglądarki klasycznej, pod względem rozmiaru ekranu, wydajności i ograniczeń wyświetlania. W rezultacie wymagania dotyczące zaplecza aplikacji mobilnej różnią się od internetowego interfejsu użytkownika na komputerze.
Te różnice skutkują konkurującymi wymaganiami co do zaplecza. Zaplecze wymaga regularnych i znacznych zmian, aby obsługiwać zarówno interfejs użytkownika na komputerze, jak i aplikację mobilną. Nad każdym frontonem pracują często oddzielne zespoły odpowiedzialne za interfejs, co powoduje, że zaplecze staje się wąskim gardłem w procesie tworzenia aplikacji. Sprzeczne wymagania dotyczące aktualizacji oraz potrzeba utrzymywania działania usługi dla obu frontonów może oznaczać konieczność włożenia sporego wysiłku we wdrożenie pojedynczego zasobu.
W związku z tym, że aktywność deweloperska koncentruje się na usłudze zaplecza, może zostać utworzony oddzielny zespół do zarządzania zapleczem i jego obsługi. W efekcie powoduje to odseparowanie zespołów odpowiedzialnych za tworzenie interfejsu i zaplecza, nakładając ciężar zrównoważenia konkurujących wymagań poszczególnych zespołów interfejsu użytkownika na zespół odpowiedzialny za zaplecze. Jeśli jeden z zespołów interfejsu użytkownika wymaga wprowadzenia zmian zaplecza, zmiany te muszą zostać zatwierdzone przez inne zespoły interfejsów użytkownika zanim zostaną zintegrowane w ramach zaplecza.
Rozwiązanie
Utwórz odrębne zaplecza dla każdego interfejsu użytkownika. Dostosuj zachowanie i wydajność każdego zaplecza, aby najlepiej dopasować je do potrzeb środowiska frontonu, nie martwiąc się o wpływ na inne środowiska frontonu.
Ponieważ każde zaplecze jest przypisane do jednego interfejsu, może być optymalizowane pod kątem tego interfejsu. W związku z tym będzie mniejsze, mniej złożone i prawdopodobnie szybsze niż zaplecze ogólne, które próbuje spełnić wymagania wszystkich interfejsów. Każdy zespół interfejsu ma autonomię w zakresie kontrolowania własnego zaplecza i nie jest zależny od zespołu deweloperów scentralizowanego zaplecza. Zapewnia to zespołowi interfejsu elastyczność w zakresie wyboru języka, cyklu wersji, priorytetyzacji obciążeń i integracji funkcji zaplecza.
Aby uzyskać więcej informacji, zobacz Wzorzec: zaplecza dla frontonów.
Problemy i kwestie do rozważenia
- Weź pod uwagę liczbę zapleczy do wdrożenia.
- Jeśli różne interfejsy (np. klienci mobilni) będą generować takie same żądania, zastanów się, czy konieczne jest wdrażanie odrębnego zaplecza dla każdego interfejsu, czy też wystarczy jedno zaplecze.
- Podczas implementowania tego wzorca bardzo prawdopodobne jest duplikowanie kodu w poszczególnych usługach.
- Usługi zaplecza dedykowane dla frontonu powinny zawierać wyłącznie zachowanie i logikę specyficzną dla danego klienta. Ogólna logika biznesowa i pozostałe funkcje globalne powinny być obsługiwane w innym miejscu aplikacji.
- Zastanów się, w jaki sposób ten wzorzec można odzwierciedlić w obowiązkach zespołu deweloperów.
- Weź pod uwagę, jak długo potrwa implementacja tego wzorca. Czy wysiłek włożony w utworzenie nowych zapleczy będzie w stanie pokryć dług techniczny przy jednoczesnej dalszej obsłudze istniejącego zaplecza ogólnego?
Kiedy używać tego wzorca
Użyj tego wzorca, gdy:
- Utrzymywanie usługi zaplecza współużytkowanej lub ogólnego przeznaczenia wiąże się ze znacznymi narzutami związanymi z programowaniem.
- Chcesz zoptymalizować zaplecze pod kątem wymagań konkretnych interfejsów klientów.
- Zaplecze ogólnego przeznaczenia jest dostosowywane do 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 generują takie same lub podobne żądania dla zaplecza.
- Gdy do interakcji z zapleczem używany jest tylko jeden interfejs.
Projekt obciążenia
Architekt powinien ocenić, w jaki sposób wzorzec zaplecza dla frontonów może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy 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. - Segmentacja SE:04 - 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 Przepływy krytyczne |
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.