Mikroserwisy - wprowadzenie i praktyczny przykład

Architektura mikrousługowa to podejście do tworzenia aplikacji podzielonej na wiele modułów. Każdy z modułów ma swoją pojedynczą odpowiedzialność. Każdy z modułów jest odwzorowywany na aplikacje, która komunikuje się z innymi aplikacjami, tworząc większą, spójną całość. Podejście takie pozwala na niezależność w rozwijaniu każdej aplikacji oraz swobodnego wyboru narzędzi (języka, frameworku) w ramach każdej aplikacji.

Skąd się wzięło podejście tworzenia mikrousług?

Samo pojęcie mikroserwisu powstało w 2012 roku. Sformułował je Adrian Cockcroft, który pracował w Netflix. Koncepcja jest zaś dużo starsza. Pojęcie mikroserwisów zdefiniował jako „fine grained SOA”. Tutaj rysuje się pewien wzór wskazujący na to, że mikroserwisy to właściwie nic nowego, lecz dobrze dobrane, współpracujące rozwiązania:

Microservice = SOA + DDD

Dlatego aby dobrze zrozumieć, czym są mikroserwisy i z czego tak naprawdę płyną ich korzyści, trzeba rozwinąć dwa pojęcia: SOA + DDD

Domain Driven Design (DDD)

TL;DR: To koncepcja tworzenia oprogramowania, gdzie nacisk kładzie się na prawidłowe odwzorowywanie potrzeb biznesowych. Całość ma odkładnie odzwierciedlać rzeczowość:

najważniejsza jest dobra komunikacja między zespołem produktowym a zespołem analizy biznesowej (budowa wspólnego języka z biznesem). Najczęściej z wykorzystaniem metody Event Storming;
podział odpowiedzialności projektu na ekspertów domenowych. Każdy ekspert domenowy odpowiada za domenę, którą się zajmuje;
podejście iteracyjne do tworzenia projektu;
inteligencja werbalna ważniejsza od algorytmicznej.

Service-oriented architecture (SOA)

Definiuje koncepcję tworzenia systemów informatycznych przedsiębiorstw zorientowanych na usługi. Polega na współdzieleniu pomiędzy wieloma aplikacjami sprawdzonych komponentów.

Jej standard zasadza się na otwartych usługach, dzięki czemu jest bardzo elastyczna. Nie jest zależna od żadnej technologii czy języka programowania. Stanowi zbiór dobrych praktyk. Jej głównymi założeniami są:

samowystarczalność – usługa nie powinna wymuszać integracji z innymi systemami na niższym poziomie. Potrafi działać samodzielnie, ale jest również zdolna do komunikacji z innymi systemami na wyższym poziomie.
luźne powiązanie – logika powinna być odizolowana od interfejsu. Zmiana implementacji nie może wpłynąć na zmianę interfejsu.
wykrywalność – łatwe do odszukania jako usługa.
bezstanowość – sesja powinna nie mieć wpływu na inną.
wielokrotnie stosowana – raz stworzona usługa powinna być elastyczna i możliwa do wykorzystania ponownie.
komponentalność – zbudowany z mniejszych części (warstw), które są odizolowane od siebie.
technologicznie niezależna – oparta na otwartych usługach, niezależna od języka programowania i technologii.

Mikrousługi – jakie problemy rozwiązuje? Zalety

Coraz dłuższy czas tworzenia nowych funkcjonalności (spuścizna SOA) – w systemach monolitycznych istnieje wiele warstw, przez które trzeba się przebijać, aby realizować nowe funkcjonalności. Okazuje się, że stworzenie osobnego programu realizującego założone funkcjonalności jest często znacznie szybsze niż do implementowanie kodu w architekturze monolitycznej. Znalezienie odpowiedniego miejsca w kodzie, spełnienie wymagań interfejsów pośrednich i przejście do warstwy widoku jest coraz trudniejsze i rośnie w miarę rośnięcia złożoności kodu. Dlatego rozwiązaniem jest pisanie małych programów z interfejsem do komunikacji.
Chodząca dokumentacja (spuścizna DDD) – w ferworze tworzenia oprogramowania często zapomina się o dokumentacji. Nawet jeśli stara się nadążyć z dokumentacja, to trudno ja utrzymać, tak aby była zrozumiała i pełna. Głównie wiedza na temat projektu, odpowiedzialności, powiazań, uruchomienia, wdrożenia i pozostałych rzeczy jest przechowywana w pamięci programistów. Problem się pojawia, kiedy kluczowy programista się zwolni, zachoruje lub napotka go inny losowy przypadek. Rozwiązaniem jest tworzenie małych programów. Ponieważ każdy zespół realizuje na tyle małą i komplementarną aplikacje, że przekazanie wiedzy na jej temat jest szybkie i bezproblemowe.
Problem w skalowaniu aplikacji (spuścizna SOA) – aplikacja monolityczna ciężko się skaluje. Zazwyczaj odbywa się poprzez skalowanie jej całej – co jest bardzo kosztowne. W przypadku mikroarchitektury możemy skalować tylko ten serwis, który jest pod największym obciążeniem. Redukuje to znacznie koszty utrzymania.
Trudność w migracji technologii (spuścizna DDD) – kiedy tworzona jest aplikacja monolityczna, to z góry zespoły mają narzucony stack technologiczny. Trudno jest później migrować rozwiązanie, lub nawet aktualizować wersje języków, frameworków czy bibliotek. W przypadku rozwiązania opartego na mikroarchitekturze, to wybór narzędzi jest dobrowolny dla każdego serwisu. Można zastosować różne języki programowania (dobrane według potrzeb danego projektu). Bez większego problemu można również aktualizować technologie w ramach serwisu, bez obawy, że będzie to miało impakt na cały system.
Kosztowne zmiany zespołu (spuścizna DDD) – czasem jeden ze serwisów jest błędnie napisany, lub wymaga zmian. W przypadku mikroarchitekury nie wiąże się z tak dużymi kosztami wzięcie serwisu, wyrzucenie go do kosza i przepisanie na nowo. Tak samo można (brutalnie, ale można) podejść do całego zespołu. Zwolnić cały zespół, jeśli nam nie odpowiada i zaangażować zupełnie nowy. Sprzyja to też outsourcingowi specjalistów.

Mikrousługi – wady

Nieopłacalność przy wdrożeniach do małych projektów.Wymaga dobrego zorganizowania i infrastruktury biznesowej.
Wymaga dobrego zorganizowania i infrastruktury biznesowej.

Architektura mikroserwisów przykład

Na moim kanale YouTube znajdziesz omówienie praktycznego przykładu. Opisuję go w 50:56. Poniższy link zaprowadzi Cię bezpośrednio do odpowiedniego fragmentu, ale zachęcam również do obejrzenia całego wykładu, który pomoże Ci uporządkować wiedzę 🙂.