Wprowadzenie

Często spotykaną definicją mikro-serwisów jest

W inżynierii oprogramowania architektura mikro-serwisów to wzorzec architektoniczny, który organizuje aplikację w zbiór luźno powiązanych, drobnoziarnistych usług, które komunikują się za pośrednictwem lekkich protokołów. Wzorzec ten charakteryzuje się możliwością niezależnego opracowywania i wdrażania usług, poprawiając modułowość, skalowalność i zdolność adaptacji. Wprowadza on jednak dodatkową złożoność, szczególnie w zarządzaniu systemami rozproszonymi i komunikacją między usługami, czyniąc początkową implementację trudniejszą w porównaniu do architektury monolitycznej. (https://en.wikipedia.org/wiki/Microservices)

To samo źródło dalej:

Nie istnieje jedna, powszechnie uzgodniona definicja mikro-serwisów. Ogólnie jednak charakteryzują się one skupieniem na modułowości, a każda usługa jest zaprojektowana wokół konkretnych możliwości biznesowych. Usługi te są luźno powiązane, niezależnie wdrażane i często opracowywane i skalowane oddzielnie, co zapewnia większą elastyczność i zwinność w zarządzaniu złożonymi systemami. Architektura mikro-serwisów jest ściśle powiązana z zasadami takimi jak projektowanie oparte na domenie, decentralizacja danych i zarządzanie oraz elastyczność wykorzystania różnych technologii dla poszczególnych usług, aby jak najlepiej spełnić ich wymagania.

Czytamy “zbiór luźno powiązanych, drobnoziarnistych usług” co niestety “Wprowadza […] jednak dodatkową złożoność, szczególnie w zarządzaniu systemami rozproszonymi i komunikacją między usługami, czyniąc początkową implementację trudniejszą w porównaniu do architektury monolitycznej.” Idąc takim tropem często niestety otrzymujemy to:

Więc jak uniknąć “Gwiazdy Śmieci”?

Architektura

Problem Gwiazdy Śmierci usuwamy rezygnując z “drobnoziarnistych usług, które komunikują się“. Mikro-serwisy to jednak niewątpliwie komponenty (modułowość) czyli niezależne (hermetyzacja) i dziedzinowe (zakres odpowiedzialności) jednostki. Po drugie wymiana danych między komponentami jest jednak czasami konieczna, więc czy to jest sprzeczność? Nie.

Micro serwisy są często pokazywane jako architektura poniżej:

Nie ma żadnej komunikacji między mikro-serwisami (dla mikro serwisów, po prawej, stosujemy wzorzec Saga):

Wielu autorów przedstawia taki oto przykład:

Ale przecież np. Zamówienie powstaje na podstawie Koszyka. To jak? Zamówienie ma sobie brać coś bazy danych koszyka? Nie, bo właśnie tak powstają monolity i Gwiazdy Śmierci! Czym więc realnie jest API Gateway? Wygląda na to, że jest także szyną integracyjną, która zawiera scenariusze każdej usługi (Przypadek Użycia), np. Zamówienia (na podstawie Koszyka i należnego Upustu), jednak powyższy diagram tego nie tłumaczy. Potrzebny jest pełniejszy projekt.

Projektowanie

Popatrzy na kolejny przykład, który bardzo często pojawia się u autorów w Internecie. Naliczyłem kilkanaście stron w Internecie z tym oto schematem:

Aby opracować projekt z narzędziem CASE odwzorujmy to w UML. Najpierw spróbujmy odtworzyć wymagania w postaci przypadków użycia:

Kolejny krok to wstępna wizja pracy z tym sklepem:

Projektujemy architekturę HLD, która zapewni realizację ww. wymagań (funkcjonalności):

Tu kilka wyjaśnień. Należy pokazać źródło danych takich jak np. aktualna data: API_Environmant (wzorzec architektura heksagonalna). Separujemy otoczenie od naszego kodu adapterami (hermetyzacja ERP i e-Płatności). Komponenty się wzajemnie nie widzą, więc nie zależ od siebie.

Scenariusz realizacji zamówienia:

Powyższe to umowa z zamawiającym, ale to także test odbiorczy (UAT, przypadki użycia, ich specyfikacje, to testy odbiorcze).

Kolejny etap to ostateczny test architektury i projekt implementacji (tu API Gateway pełni także role koordynatora):

Operacja wstawienia treści Koszyka do Zamówienia wymaga zdefiniowania koszyka:

Oraz Zamówienia:

Procedurę wstawienia do zamówienia daty oraz treści koszyka można opisać słownie lub z pomocą diagramu aktywności (to opisałem w innym miejscu: Diagram aktywności UML). Metodę projektowania wraz z bogate literaturą czytelnik z znajdzie w tekście: ICONIX jako zwinny proces projektowania oprogramowania z użyciem UML.

Podsumowanie

Programming is not solely about constructing software—programming is about designing software. [Ipek Ozkaya. ‘Building Blocks of Software Design’. IEEE Software 37, no. 2 (2020): 3–5. https://doi.org/10.1109/MS.2019.2959049.]

Pokazano standardowy sposób tworzenia modeli PIM (Platform Independent Model, OMG.org). Mikro-serwisy to bardzo wygodna, od wielu lat opisywana architektura, pierwotnie nie była tak nazywana, ponad 20 laty temu można znaleźć opis tej idei jako wzorzec SAGA i komponentowa architektura aplikacji. Era “drobienia” jest nowa i szybko się skompromitowała powstaniem Gwiazd Śmierci, i świat wraca powoli do źródeł tej koncepcji.

Jako uzupełnienie polecam artykuł: Architektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu.

F.A.Q.

“bo skoro jedyna komunikacja jest prze API gateway “

tak

“I jest orkiestrowa przez ui, “

to nie jest prawda, orkiestracja jest w API Gateway lub za nim (koordynator)

“nie ma komunikacji między serwisami. “

i tak ma być, one sie nie widzą dzięki temu ich zmiana lub awaria nie przynosi żadnej większej szkody, po drugie to właśnie komunikacja między mikro-serwisami to prosta droga do “gwiazdy śmieci”, komunikację między serwisami realizuj koordynator

“To z kolei oznacza, że każdy z serwisów robi bardzo proste, zamknięte procesy. “

nie oznacza, żaden mikroserwis nie robi żadnych “procesów” tylko, nie raz bardzo skomplikowane, dziedzinowe operacje, procesy (a raczej sekwencje) realizuje koordynator, będący częścią API Gateway’a

“Cały ciężar logiki przeniesiony jest na ui, który składa z masy atomowych wywołań złożony proces – robi się skomplikowanie i krucho. “

co więc także nie jest prawdą, logika dziedzinowa to: operacje na dokumentach (komunikatach) i robią to mikroserwisy, właściwa sekwencje tych operacji i dba o to koordynator

“Takie podejście nie pozwala na zbudowanie sensownych serwisów, które oferują rozbudowane możliwości. Na przykład nie jest możliwe zamknięcie procesu składania zamówienia w jednym wywołaniu.”

pozwala, co pokazałem na diagramie sekwencji, rzecz w tym, że nie obciążamy mikroserwisów odpowiedzialnością za pracę innych mikroserwisów, tak jak na budowie nie obciążamy murarza wiedzą i odpowiedzialnością za prace współpracującego elektryka, odpowiada za to zawsze Kierownik Budowy

Źródła