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 ale jest UI. 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 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:

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.