LITMIR.BIZ

      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

Скачать книгу