Mikroserwisy mają obecnie swoje 5 minut. Są jak klocki Lego – małe, jednofunkcyjne procesy, które można łączyć tworząc aplikacje w architekturze zorientowanej na usługi. Ich zwolennicy twierdzą, że zapewniają lepszą skalowalność, dzięki łatwości łączenia i rekombinacji. Mogą być rozwijane niezależnie, pozwalają zatem na łatwy podział odpowiedzialności pomiędzy zespołami inżynierów.
Jednak podobnie jak w przypadku każdego trendu, zbyt łatwo można dać się ponieść fali zainteresowania i zaangażować bezrefleksyjnie w architekturę, która w rezultacie wpędzi Twój zespół i organizację w problemy. Mikroserwisy – tak jak każda nowatorska technologia, metodyka, etc. – nie są dla każdego.
Wzorzec architektoniczny
Idea mikrousług (mikroserwisów) polega w ogólności na tym, aby podzielić monolityczną aplikację na zbiór mniejszych usług pozostających ze sobą w relacji. Każdy mikroserwis jest de facto małą aplikacją, która ma własną architekturę, składającą się z logiki biznesowej i różnych adapterów. Niektóre mikrousługi wykorzystują API REST, inne RPC lub interfejs API oparty na komunikatach, a większość usług korzysta z interfejsów API dostarczanych przez innych dostawców.
Wzorzec architektury mikrousługowej znacząco wpływa na relacje między aplikacją a bazą danych. Zamiast współdzielenia ujednoliconego schematu bazy danych z pozostałymi usługami, każda usługa ma swój własny schemat. Z jednej strony takie podejście jest sprzeczne z ideą modelu danych dla całej organizacji. Często powoduje to również redundancję danych. Jednak posiadanie schematu bazy danych per usługa jest niezbędne, jeśli wykorzystujemy architekturę mikrousługową, ponieważ zapewnia ‘luźne łączenie’ (loose coupling). Zatem każda z usług ma własną bazę danych a ponadto może korzystać z rodzaju bazy danych najlepiej dostosowanego do jej potrzeb, tzw. architektura polyglot persistence.
Interfejsy API są wystawiane do wykorzystania przez aplikacje mobilne i webowe. Aplikacje nie mają jednak bezpośredniego dostępu do warstwy backend. Zamiast tego w komunikacji pośredniczy API Gateway. Jest on odpowiedzialny za równoważenie obciążenia, buforowanie, kontrolę dostępu, czy też pomiary API i monitorowanie.
Wzorzec architektoniczny mikrousług w relacji do Scale Cube (skalowalność)
Czytaj także: 5 dobrych praktyk gdy wdrażasz mikroserwisy
Architektura mikrousług: korzyści
- Adresuje problem złożoności, rozkładając aplikację na szereg łatwych w zarządzaniu elementów, znacznie szybszych w opracowaniu i łatwiejszych w zrozumieniu i utrzymaniu.
- Umożliwia niezależne rozwijanie każdej z usług przez zespół, który dzięki temu koncentruje się na tylko na funkcjonalności tej usługi.
- Obniża barierę adopcji nowych technologii (swoboda wyboru technologii)
- Umożliwia niezależne wdrożenie każdej usługi. W rezultacie umożliwia ciągłe wdrażanie (Continuous Deployment – CD) w przypadku złożonych projektów / aplikacji.
- Umożliwia też skalowanie każdej usługi niezależnie.
Korzyści nie mogą przesłonić wad
Architektura mikrousługowa dodaje niebagatelny wymiar złożoności do projektu z tego powodu, że jest architekturą systemów rozproszonych. Oznacza to m.in. konieczność wyboru i wdrożenia mechanizmu komunikacji między procesami opartego na komunikatach lub RPC, czy też konieczność oprogramowania wyjątków i awarii oraz wzięcie pod uwagę pozostałych aspektów obliczeń rozproszonych. Ponadto:
- architektura partycjonowanej bazy danych. Transakcje biznesowe aktualizujące wiele jednostek w aplikacji opartej na mikroserwisach wymagają aktualizacji wielu baz danych należących do różnych usług. Korzystanie z transakcji rozproszonych zwykle nie wchodzi w rachubę i ostatecznie pozostaje konieczność zapewnienia spójności programowo, co jest oczywiście trudniejsze dla programistów.
- testowanie aplikacji opartych na mikrousługach jest również znacznie bardziej złożone niż w przypadku monolitycznej aplikacji webowej. W przypadku usługi, trzeba uruchomić tę usługę i wszystkie usługi powiązane.
- trudniej jest wprowadzić zmiany obejmujące wiele usług. W monolitycznej aplikacji można po prostu zmienić odpowiednie moduły, zintegrować zmiany i wdrożyć je za jednym razem. W architekturze mikrousługowej należy dokładnie planować i koordynować wdrażanie zmian w każdej z usług.
- wdrażanie aplikacji jest również bardziej złożone. Monolityczna aplikacja jest po prostu wdrażana z wykorzystaniem zestawu maszyn wirtualnych. Natomiast aplikacja oparta na mikrousługach zazwyczaj składa się z dużej liczby usług, każda usługa ma wiele instancji środowiska wykonawczego, każda instancja musi być skonfigurowana, wdrożona, skalowana i monitorowana. Ponadto konieczne jest zapewnienie mechanizmu wykrywania usług. Ten poziom złożoności wymaga już wysokiego poziomu automatyzacji.
Podejścia hybrydowe – kompromis
Absolutnie nic nie stoi na przeszkodzie, aby stosować podejście hybrydyczne i pozostawić monolityczną architekturę tam, gdzie to konieczne. Ogromna większość istniejących systemów legacy używa tego podejścia i to jest główny powód tego, że wciąż są używane. Kluczową rzeczą jest, aby unikać wprowadzania zmian dla samych zmian, bo to nie dostarcza wartości. Nie dotyczy to oczywiście tylko dużych organizacji, warto poczytać np. o drodze jaką przeszedł startup Segment, wracając do architektury monolitycznej po uprzednim wprowadzeniu mikrousług.
Pozostałe źródła godne polecenia:
