Mikroserwisy w akcji. Отсутствует
klient – aplikacje klienckie, takie jak strony internetowe i aplikacje mobilne, wchodzą w interakcję z backendem mikroserwisowym.
Na rysunku 3.4 pokazano te warstwy architektoniczne. Powinniśmy móc je zastosować do dowolnej aplikacji mikroserwisowej, niezależnie od wybranej technologii.
Rysunek 3.4. Czteropoziomowy model architektury aplikacji mikroserwisowych
Każda warstwa jest oparta na zdolnościach niższych warstw; na przykład poszczególne usługi wykorzystują strumienie wdrażania, infrastrukturę i mechanizmy komunikacji, które zapewnia niższa platforma mikroserwisowa. Aby dobrze zaprojektować aplikację mikroserwisową, potrzebne są doświadczenie i inwestycje na wszystkich warstwach.
Wspaniale! Teraz mamy model, z którym możemy pracować. W kolejnych pięciu podrozdziałach przejdziemy przez każdą warstwę w tym modelu architektonicznym i omówimy, w jaki sposób przyczynia się ona do budowania trwałych, elastycznych i ewolucyjnych aplikacji mikroserwisowych.
3.2. Platforma mikroserwisu
Mikroserwisy nie działają w izolacji. Mikroserwis jest obsługiwany przez infrastrukturę:
■ środowiska wdrożeniowego, w którym są uruchamiane usługi, w tym podstawowe elementy infrastruktury, takie jak moduły równoważenia obciążenia i maszyny wirtualne;
■ gromadzenia dzienników i monitorowania w celu obserwacji działania usługi;
■ spójnych i powtarzalnych strumieni wdrażania do testowania i udostępniania nowych usług i wersji;
■ wsparcia bezpieczeństwa operacji, takich jak kontrola sieciowa, zarządzanie bezpieczeństwem czy utwardzania aplikacji (application hardening);
■ kanałów komunikacji i dostępu do usług w celu wspierania ich interakcji.
Na rysunku 3.5 przedstawiono te możliwości i ich związek z warstwą usług aplikacji. Jeśli każdy mikroserwis jest domem, platforma zapewnia drogi, wodę, elektryczność i kable telefoniczne.
Rysunek 3.5. Możliwości platformy mikroserwisowej
Solidna warstwa platformy zmniejsza ogólne koszty wdrożenia, zwiększa ogólną stabilność i umożliwia szybki rozwój usług. Bez tej platformy twórcy produktów musieliby wielokrotnie pisać kod wykonujący podstawowe operacje zamiast dostarczać nowe funkcjonalności i wpływać na działalność. Przeciętny programista nie musi być ekspertem od zawiłości każdej warstwy aplikacji. Ostatecznie nawet częściowo niezależny, wyspecjalizowany zespół może opracować warstwę platformy, aby sprostać potrzebom wielu zespołów pracujących w warstwie usług aplikacji.
3.2.1. Mapowanie platformy uruchomieniowej
Platforma mikroserwisowa zwiększy naszą pewność, że możemy zaufać usługom, które pisze nasz zespół, aby obsługiwały zadania produkcyjne oraz były odporne, przejrzyste i skalowalne. Na rysunku 3.6 przedstawiono platformę uruchomieniową dla mikroserwisu.
Platforma uruchomieniowa (lub cel wdrożenia) – na przykład środowisko chmurowe, takie jak AWS, lub platforma jako usługa (PaaS), na przykład Heroku – zapewnia prymitywy infrastruktury niezbędne do uruchamiania wielu instancji usług i kanałów żądań między nimi. Ponadto zapewnia mechanizmy umożliwiające konfigurację – danych poufnych oraz zmiennych specyficznych dla środowiska – dla instancji usług.
Na tym fundamencie budujemy pozostałe elementy platformy mikroserwisowej. Narzędzia związane z obserwacjami będą zbierać i łączyć dane z usług i bazowej infrastruktury, strumień wdrażania zaś będzie zarządzać aktualizacją (lub wycofaniem) tej struktury.
Rysunek 3.6. Konfiguracja wdrożeniowa dla mikroserwisu działającego w typowym środowisku chmurowym
3.3. Usługi
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