Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 35

Warstwa usług ma chyba najbardziej oczywistą nazwę – tutaj znajdują się nasze usługi. Na tym poziomie usługi współdziałają w celu wykonywania konkretnych zadań, bazując na abstrakcjach z niższej warstwy w celu zapewnienia niezawodnego działania i komunikacji oraz udostępniają swoją pracę za pośrednictwem warstwy granicznej klientom aplikacji. Komponenty logicznie należące do usług, takie jak magazyny danych, traktujemy również jako część tego poziomu.

Struktura warstwy usług będzie się znacznie różnić w zależności od natury naszej działalności. W tej części omówimy niektóre typowo spotykane wzorce:

■ zdolności biznesowe i techniczne,

■ agregacja i usługi wyższego szczebla,

■ usługi na ścieżkach krytycznych i niekrytycznych.

3.3.1. Zdolności

Usługi, które napiszemy, będą implementować różne zdolności:

■ zdolność biznesowa to coś, co firma ma, aby generować wartość i realizować cele biznesowe; mikroserwisy, które można przyrównać do zdolności biznesowych, bezpośrednio odzwierciedlają cele biznesowe;

■ zdolność techniczna wspiera inne usługi przez implementację wspólnej cechy technicznej.

Na rysunku 3.7 porównano te dwa typy zdolności. Usługa obsługi zleceń SimpleBanku udostępnia zdolność zarządzania ich realizacją – jest to zdolność biznesowa. Usługa obsługi giełdy jest zdolnością techniczną; zapewnia bramę dla podmiotu zewnętrznego tak, że inne usługi (takie jak udostępnianie informacji rynkowych lub rozliczanie transakcji) mogą z niej korzystać.

Rysunek 3.7. Mikroserwisy implementują zdolności biznesowe lub techniczne

UWAGA  W następnym rozdziale omówimy, kiedy wykorzystywać zdolności biznesowe i techniczne oraz jak je zmapować do poszczególnych usług.

3.3.2. Agregacja i usługi wyższego szczebla

W pierwszych dniach aplikacji mikroserwisowej nasze usługi prawdopodobnie będą płaskie; każda usługa pewnie będzie miała podobny poziom odpowiedzialności. Na przykład usługi z rozdziału 2 – zleceń, opłat, transakcji i rachunku – mają zakres na zbliżonym poziomie abstrakcji.

Wraz z rozwojem aplikacji napotkamy dwa rodzaje nacisków na rozwój usług:

■ agregowanie danych z wielu usług w celu obsługi żądań klientów dotyczących danych zdenormalizowanych (np. zwracanie zleceń i opłat);

■ zapewnienie wyspecjalizowanej logiki biznesowej, która wykorzystuje zdolności podstawowe (np. umieszczenie specjalnego typu zlecenia).

Z czasem te dwa rodzaje presji doprowadzą do powstania hierarchii usług. Usługi bliżej granicy systemu będą współdziałać z wieloma innymi usługami, aby zebrać ich dane wyjściowe – nazwijmy je agregatorami (rys. 3.8). Ponadto wyspecjalizowane usługi mogą działać jako koordynatorzy działań wielu usług niższego szczebla.

Rysunek 3.8. Agregator obsługuje zapytania, łącząc dane z usług podstawowych, a koordynator zarządza zachowaniem, wydając polecenia usługom niższego szczebla

Wyzwaniem, przed którym staniemy, jest ustalenie, kiedy nowe wymagania dotyczące danych lub nowe zachowanie aplikacji wymaga nowej usługi, a nie zmian w którejś z istniejących. Utworzenie nowej usługi zwiększy ogólną złożoność i może powodować luźne powiązanie, ale dodanie funkcjonalności do istniejącej usługi może spowodować, że będzie ona mniej spójna i trudniejsza do zastąpienia. To złamałoby fundamentalną zasadę mikroserwisów.

3.3.3. Ścieżki krytyczne i niekrytyczne

Wraz z rozwojem systemu niektóre funkcjonalności w sposób naturalny staną się bardziej krytyczne dla potrzeb naszych klientów i skutecznego działania firmy niż inne. Na przykład w SimpleBanku usługa obsługi zleceń znajduje się na ścieżce krytycznej dla złożenia zlecenia. Bez tej działającej poprawnie usługi nie można wykonywać zleceń klientów. I odwrotnie, inne usługi są mniej istotne; jeśli usługa profilu klienta jest niedostępna, jest mniej prawdopodobne, że wpłynie ona na krytyczny, generujący przychody element naszej oferty. Na rysunku 3.9 zilustrowano przykładowe ścieżki w SimpleBanku.

Rysunek 3.9. Łańcuchy usług tworzą zdolności. Wiele usług będzie znajdować się na wielu ścieżkach

To miecz obosieczny. Im więcej usług będzie na ścieżce krytycznej, tym bardziej prawdopodobna będzie awaria. Ponieważ żadna usługa nie jest w 100% niezawodna, skumulowana niezawodność usługi jest wynikiem niezawodności jej zależności.

Mikroserwisy pozwalają jednak wyraźnie zidentyfikować te ścieżki i traktować je niezależnie, pozwalając na zainwestowanie więcej wysiłku w maksymalizowanie odporności i skalowalności tych ścieżek zamiast w mniej istotne obszary systemu.