Ogarnąć chaos, czyli orkiestracja mikroserwisami w procesach biznesowych


Czym jest mikroserwis lub mikrousługa w porównaniu do monolitycznej aplikacji?
Mikroserwis lub mikrousługa to tożsame określenia na niezależną aplikację, która odpowiada za realizowanie konkretnej funkcji biznesowej. Jednak, aby stworzyć proces, który realizować będzie mniej lub bardziej złożone operacje, potrzebujemy takich aplikacji kilka (a czasem nawet kilkanaście).
Tym samym, jeśli założymy, że nasz system to więcej niż jeden proces, prawdopodobnie okaże się, że takich aplikacji będziemy potrzebować naprawdę sporo. Z jednej strony może to generować trudności w zarządzaniu mikroserwisami, jednak z drugiej takie podejście daje dużo większą elastyczność w rozwoju aplikacji. Dodawanie nowych funkcjonalności jest prostsze niż w przypadku aplikacji monolitycznych, dzięki czemu możemy szybciej i sprawniej dostarczać wartość biznesową klientom.
Architektura mikroserwisów pozwala na to, aby usługi były rozwijane niezależnie, przez dedykowany zespół specjalistów, który ma swobodę doboru narzędzi i technologii najlepiej pasujących do rozwiązywanego przez nich problemu.
Mikroserwisy a złożone procesy biznesowe
W dalszej części artykułu skupimy się na tym, w jaki sposób — przy pomocy niezależnych usług — realizować złożone procesy biznesowe, na jakie problemy przy tym natrafimy i w jaki sposób im zaradzić. W celu lepszego zrozumienia tematu przyjmijmy, że będziemy rozpatrywać działanie systemu w firmie realizującej naprawy sprzętu telekomunikacyjnego. Sprzęt dostarczany jest do firmy za pośrednictwem usług kurierskich, a poniżej znajduje się uproszczony podział na usługi oraz proces obsługi sprzętu.


Architektura mikroserwisów. Komunikacja bezpośrednia
Mikroserwisy realizują powierzone im zadania. W tym celu komunikują się z innymi usługami, aby pozyskać niezbędne do realizacji dane lub podzielić się wynikiem.
Jednym ze sposobów komunikacji pomiędzy usługami jest komunikacja synchroniczna z wykorzystaniem RESTa. Większość zespołów wykorzystuje takie podejście do tworzenia warstwy komunikacji w usługach, ponieważ jest to sposób relatywnie najprostszy, najlepiej znany i wymagający najmniej planowania. Niestety serwisy wykorzystujące jedynie ten sposób komunikacji są ze sobą ściśle powiązane (ang. tight coupling), przez co bardzo mocno uzależniają się od siebie.
I tutaj przechodzimy do sedna problemu: duża liczba usług powoduje, że pomiędzy nimi tworzy się silna sieć komunikacyjna. W efekcie wprowadzenie dodatkowego mikroserwisu może spowodować konieczność modyfikacji wszystkich innych, które będą się z nim komunikować. Tym samym każda zmiana procesu biznesowego okazuje się być bardzo kosztowna, podobnie jak w przypadku architektury monolitycznej.
W jaki sposób unikać takich problemów?
Komunikacja w mikroserwisach. Na co zwrócić uwagę?
W pierwszej kolejności należy skupić się na:
- Wyeliminowaniu ścisłego powiązania pomiędzy usługami, dzięki czemu możliwy będzie bardziej niezależny rozwój poszczególnych usług.
- Niezawodności aplikacji, czyli jej wysokiej dostępności, ale też możliwość wznowienia pracy po awarii (w przypadku komunikacji synchronicznej występuje duże ryzyko zatrzymania pracy aplikacji na skutek błędu w jednym z serwisów).
- Czytelnym widoku procesu biznesowego realizowanego przez poszczególne usługi.
- Monitorowaniu pracy systemu w celu szybkiego i sprawnego rozwiązywania problemów.
Komunikacja asynchroniczna. Architektura sterowana zdarzeniami
Rozwiązaniem części problemów będzie zmiana sposobu podejścia do komunikacji mikroserwisów. Zamiast tworzyć sieć usług komunikujących się ze sobą synchronicznie i bezpośrednio, można zastanowić się nad przejściem na luźniejszą formę komunikacji, tzw. zdarzenia (ang. events). Jak to wygląda?
Usługa, która zrealizuje polecenie, komunikuje ten fakt innym usługom. Komunikacja pomiędzy usługami nie jest bezpośrednia (usługa -> usługa) – zdarzenie nie jest wysyłane do każdej z usług, ale na tzw. kolejkę. Dzięki takiemu podejściu nie ma sztywnego powiązania pomiędzy serwisami. Główną formą komunikacji jest wysyłanie i odbieranie zdarzeń z „kolejki”, a same mikroserwisy nie wiedzą, kto dokładnie jest odbiorcą naszej wiadomości. Wprowadzenie lub wyłączenie usługi odbywa się dużo niższym kosztem, ponieważ nie są wymagane zmiany w innych usługach.


Zagrożenia komunikacji asynchronicznej w systemach rozproszonych
Odpowiedzialność za wysoką efektywność, dostępność i niezawodność komunikacyjną przenosimy na zewnętrzny system („kolejka”). Rozwiązanie to ma jednak kilka wad. Wprowadzenie kolejki powoduje, że staje się ona głównym miejscem wymiany zdarzeń, tym samym okazuje się, że nasz system ma tzw. pojedynczy punkt awarii (ang. Single Point Of Failure). Awaria tego jednego elementu może spowodować, że system utraci zdolność realizowania procesu biznesowego. Dodatkowo musimy coraz więcej myśleć nad takimi zagadnieniami jak ostateczna spójność (ang. eventual consistency) czy też kompensacja (ang. compensation events).
Przechodząc na komunikację asynchroniczną, gdzie każda usługa realizuje swoje zadanie po odebraniu konkretnego zdarzenia (ale w najlepszym dla siebie momencie), musimy pamiętać, że i w tym podejściu bardzo łatwo o kłopoty. Łatwość tworzenia nowych usług i dodawania nowych funkcjonalności powoduje, że szybko dokładamy nowe kroki w procesie, ale zaczynamy tracić z oczu widok całości.
To, co wcześniej było zaplanowaną choreografią, zaczyna przypominać występ indywidualności. Kwestią czasu jest, aż któraś z mikrousług wyjdzie przed szereg i zacznie psuć proces oraz dane.
Rola orkiestratora w architekturze mikroserwisów
W tym momencie pojawia się rola orkiestratora. Jedna z usług może przyjąć funkcję polegającą na nadzorowaniu całego procesu. W uproszczeniu to orkiestrator wysyła komendę (ang. command), a po otrzymaniu zdarzenia o zakończeniu wykonuje kolejną czynność i wysyła nową komendę do kolejnej usługi. Orkiestrator pilnuje również, aby każda z usług wykonała poprawnie swoje zadanie, a w razie problemów potrafi odpowiednio „posprzątać”.
Usługi nadal są niezależne i nie wiedzą o swoim istnieniu. Wysyłają zdarzenia na kolejkę i tam również na nie oczekują. Główna różnica jest taka, że komendy inicjujące wykonanie funkcji wysyła jeden z mikroserwisów. Odpowiedzialność za prawidłowe wykonanie całego procesu spada na wybraną usługę.
Zagrożenia orkiestracji
Rozwiązanie, jak każde inne również nie jest idealne. W momencie powołania orkiestratora równocześnie tworzymy kolejne wąskie gardło w systemie. Paraliż jednej usługi powoduje zatrzymanie całego procesu.
Dodawanie nowych mikrousług wymaga wkomponowania ich w sam proces, a więc należy pamiętać również o zmianach w orkiestratorze. Decydując się na takie podejście, powoli tracimy elastyczność, a posiadanie kilku wersji tego samego procesu mocno komplikuje proces wytwórczy i same wdrożenia. Nie wystarcza już włączenie lub wyłączenie danej usługi. Należy pamiętać o implementacji kilku ścieżek procesu i zapewnić, aby każda działała tak, jak zostało to zaplanowane.
Orkiestracja mikroserwisami a silniki workflow
Nawet orkiestracja mikroserwisami potrzebuje wsparcia. Z pomocą przychodzą nam systemy implementujące silniki workflow, które to dbają wysoką niezawodność, pozwalają monitorować procesy oraz wdrażać ich kolejne wersje bez konieczności likwidowania poprzednich. Dzięki narzędziom do zarządzania procesem biznesowym w bardzo łatwy sposób można wykorzystać kolejną usługę, wpinając ją w ścieżkę. Wszystko odbywa się z użyciem wizualnych narzędzi, a sam proces bardzo często definiowany jest przy pomocy standardów BPMN 2.0.
Rozwiązania takie pozwalają zapanować nad chaosem powstałym w wyniku niekontrolowanego rozwoju procesu biznesowego.
Silnik workflow: Zeebe
Jednym z takich narzędzi jest Zeebe. Darmowy i o otwartym kodzie silnik do zarządzania orkiestracją mikroserwisów, który oferuje:
- Czytelność — każdy z procesów w firmie będzie zbudowany przy pomocy standardu ISO BPMN 2.0. Rozwiązanie pozwala na bieżąco obserwować działanie procesu, średni czas przepływu czy występujące błędy.
- Orkiestracja — Zeebe pełni funkcję orkiestratora. Publikuje „zdarzenia”, które mogą być wykorzystywane przez jedną lub więcej z mikrousług, zapewniając postępy w przepływie procesu zgodnie z jego definicją.
- Monitoring — opóźnień lub innych błędów procesu oraz możliwość definiowania ścieżek obsługi błędów takich jak ponowna próba wykonania lub eskalacja do zespołu (możliwość ręcznego ukończenia procesu zgodnie z planem).
O Zeebe możesz przeczytać również w naszym artykule: 5 rzeczy, które powinieneś wiedzieć o Camunda 8
Zeebe. Orkiestracja mikroserwisów
Orkiestracja mikroserwisami i rozwiązanie problemów z nią związanych – oto cel, jaki został postawiony przez twórców Zeebe. Udało się to osiągnąć dzięki:
- Wysokiej skalowalności horyzontalnej — możliwość dodawania dodatkowych węzłów (ang. node) do systemu powoduje, że te mogą przetworzyć większe obciążenie (wzrost liniowy).
- Braku zależności od relacyjnych baz danych — Zeebe zapisuje dane w systemie plików serwera, na którym jest zainstalowany.
- Odporności na awarie — dzięki replikacji danych Zeebe może kontynuować prace zaraz po usunięciu awarii.
- Architekturze opartej na zdarzeniach — zdarzenia można eksportować do zewnętrznych systemów w celu zapewnienia raportów z pracy systemu.
- Wizualnemu modelowaniu procesu w standardzie ISO BPMN 2.0 — dzięki czemu osoby techniczne i nietechniczne mogą współpracować przy definicji procesu we wspólnym języku.
Integracja z Zeebe może być realizowana w każdym języku programowania używanym w organizacji.
Zeebe. Śledzenie i monitorowanie procesów
W przypadku bardzo dużych systemów migracja całej architektury na nowe rozwiązanie może okazać się bardzo kosztowna, a wręcz nieopłacalna. W takim przypadku, zamiast przerabiać cały proces i generować duże koszty, można skupić się na rozpoczęciu monitorowania procesu biznesowego.
Wykorzystując do tego celu Zeebe można w łatwy sposób zintegrować zaimplementowane usługi z silnikiem przepływów i „na żywo” monitorować proces biznesowy. Rozwiązanie jest na tyle nieinwazyjne, że nie wymaga dużych nakładów pracy, a sam silnik bardzo dobrze współpracuje z „kolejkami”.


Zdarzenia konsumowane przez Zeebe z kolejki mogą posłużyć do stworzenia map cieplnych (ang. heat map) ujawniających wąskie gardła w systemie.


Zeebe. Pełna orkiestracja mikroserwisami
Mimo wszystko dużo lepsze efekty uzyskamy wdrażając rozwiązanie w pełni oparte o technologie Zeebe.
Jedną z możliwości jest wykorzystanie silnika Zeebe do orkiestracji mikroserwisami. Poza monitorowaniem zyskujemy funkcjonalność wizualnego definiowania przepływów w procesie. Nowe funkcjonalności i mikrousługi dodawane są niezależnie i nieinwazyjnie. Ich użycie definiowane jest w konkretnej wersji procesu, a w razie problemów można przywrócić poprzedni sposób działania. Wszystko przy zachowaniu wysokiej wydajności i bezpieczeństwa.
Orkiestracja mikroserwisami – podsumowanie
Zarządzanie mikroserwisami w celu realizowania procesu biznesowego jest skomplikowaną procedurą. Podchodząc do tego w sposób nieumiejętny, możemy natrafić na wiele problemów, a dalszy rozwój aplikacji może w pewnym momencie okazać się nieopłacalny. Dlatego też najprostszym i często najlepszym wyborem jest skorzystanie z gotowego rozwiązania do zarządzania procesami, np. omawianego w tekście silnika Zeebe.