Mikroserwisy to podejście do tworzenia aplikacji, w którym całość jest podzielona na mniejsze, niezależne od siebie moduły. Każdy z tych modułów jest osobną aplikacją, która może działać niezależnie od reszty. Moduły te są ze sobą połączone za pomocą sieci, dzięki czemu mogą ze sobą komunikować się i działać wspólnie.
Takie podejście umożliwia większą elastyczność, skalowalność i łatwiejsze zarządzanie aplikacją. Elastyczność wynika z faktu, że każdy moduł jest samodzielnym elementem i można go łatwo wymienić lub zastąpić bez wpływu na pozostałe części systemu. Każdy moduł może być też wykonany w różnych technologiach. Innymi słowy, mikroserwisy pozwalają na łatwe wprowadzanie zmian w aplikacji bez konieczności modyfikowania całego systemu.
Skalowalność to kolejny atut w architekturze mikroserwisów. Dzięki temu podejściu, aplikacja może być skalowana w sposób bardziej precyzyjny, tj. jeśli tylko dana część systemu wymaga większych zasobów, można zwiększyć jej moc obliczeniową lub rozszerzyć bazy danych bez wpływu na całą aplikację.
Mikroserwisy pozwalają też na niezależny rozwój funkcjonalności i lepszą organizację pracy zespołó, ponieważ każdy moduł może być rozwijany niezależnie przez inny zespół programistów. Przy dużych systemach monolitycznych pracuje dużo osób. W podejściu mikroserwisowym można podzielić system na różne konteksty rozwijanie niezależnie przez osobne zespoły.
Skąd się wzięło podejście tworzenia mikrousług?
Podejście tworzenia mikroserwisów pojawiło się w latach 90. XX wieku, kiedy to firmy zaczynały tworzyć coraz większe aplikacje monolityczne. Z czasem okazało się, że taki typ aplikacji jest trudny w utrzymaniu, a wprowadzanie zmian w nim jest kosztowne i ryzykowne. W odpowiedzi na te problemy powstało podejście mikroserwisów, które opiera się na tworzeniu mniejszych, niezależnych od siebie modułów, które mogą działać niezależnie i być łatwo wymieniane lub zastępowane bez wpływu na całość systemu.
Architektura monolityczna
Architektura monolityczna to podejście do tworzenia aplikacji, w którym całość systemu działa jako jedna, spójna jednostka. Wszystkie jego funkcjonalności są zawarte w jednym programie, a zmiany w jednej części systemu mogą mieć wpływ na całość. Jest to często stosowane podejście w aplikacjach starszej generacji, które opierają się na prostych strukturach i mniejszej liczbie funkcjonalności. Jednakże, wraz z rozwojem technologii i zwiększeniem złożoności aplikacji, podejście monolityczne staje się coraz mniej praktyczne i skuteczne.
Rozwój systemów a mikroserwisy, czyli jak ich architektura odpowiada na ich potrzeby?
Architektura mikroserwisów odpowiada na potrzeby biznesu i zespołów programistyczny w następujący sposób:
- Elastyczność: dzięki podziałowi aplikacji na mniejsze, niezależne moduły, możliwe jest łatwe wprowadzanie zmian w aplikacji bez konieczności modyfikowania całego systemu.
- Skalowalność: dzięki temu podejściu, aplikacja może być skalowana w sposób bardziej precyzyjny, tj. jeśli tylko dana część systemu wymaga większych zasobów, można zwiększyć jej moc obliczeniową lub rozszerzyć bazy danych bez wpływu na całą aplikację.
- Lepsza organizacja pracy zespołu: każdy moduł może być rozwijany niezależnie przez inny zespół.
- Większa odporność na błędy: błąd w mikroserwisie powoduje, że tylko ta usługa, w której wystąpił błąd przestanie działać.
- Możliwość użycia różnych technologii: do każdej mikro usługi można zastosować inne technologie.
- Wdrażanie: mikro serwisy można wdrażać niezależnie, a więc zrobienie zmiany w jednej usłudze powoduje konieczność deploy tylko tej jednej usługi.
- Skalowanie: w przypadku korzystania z mikro serwisów można skalować tylko te usługi, które tego wymagają. Daje to duże możliwości optymalizacji.
Mikroserwisy – czy to jeszcze rewolucja i nowa jakość czy już standard w projektach?
Mimo że mikroserwisy nie są już taką nowością jak kilka lat temu, to wciąż nie można powiedzieć, że to jest standard w projektach. Wiele firm wciąż korzysta z podejścia monolitycznego, a mikroserwisy stosowane są głównie w większych projektach. Jednakże, wraz z coraz większą popularnością technologi cloudowyc i potrzebą szybkiego dostosowania się do zmieniających się warunków rynkowych, podejście mikroserwisowe zyskuje na znaczeniu i można spodziewać się, że w niedalekiej przyszłości stanie się standardem w projektach prowadzonych w dużej skali (architekturę mikroserwisów można polecić do złożonych aplikacji)
Architektura mikroserwisów vs. architektura monolityczna
| Mikroserwisy | Monolity | |
| Elastyczność | Możesz podzielić aplikację na mniejsze, niezależne moduły, które mogą działać niezależnie i być łatwo wymieniane lub zastępowane bez wpływu na całość systemu. | Wszystkie funkcjonalności są zawarte w jednym programie, a zmiany w jednej części systemu mogą mieć wpływ na całość. |
| Skalowalność | Aplikacja może być skalowana w sposób bardziej precyzyjny. Można skalować tylko te usługi, które tego wymagają. | Trzeba skalować cały system |
| Organizacja | Lepsza organizacja pracy zespołu. Różne zespoły mogą pracować niezależnie nad różnymi częściami systemu | Jeden duży zespół na cały system |
| Wdrażanie | Mikroserwisy można wdrażać niezależnie. | Najmniejsza zmiana w kodzie powoduje konieczność deploymentu całej aplikacji |
| Koszty | Koszty infrastruktury, oprogramowania i licencji wzrastają | Koszty są na stałym poziomie, jest mniej “klocków” |
| Debugowanie i testowanie | Jest trudniejsze ponieważ system jest rozproszony | Łatwiejsze testowanie, ponieważ wszystko jest w jednym miejscu |
| Bezpieczeństwo | Ruch odbywa się przez sieć między systemami więc trzeba zadbać o zabezpieczenie komunikacji | Większość komunikacji jest w środku systemu, łatwiej zadbać o bezpieczeństwo |
| Wydajność | Komunikacja przez sieć powoduje opóźnienia i niespodziewane awarie | Mniej opóźnień spowodowanych przez sieć, aplikacja działa w bardziej przewidywalny sposób |
| Monitorowanie i analityka | System jest rozproszony, więc jego monitoring jest trudniejszy. Integracja z systemami zewnętrznymi nie jest taka prosta jak w przypadku monolitu | Proste, wszystko jest w jednym miejscu |
| Spójność danych | Każdy serwis może mieć bazę danych, transakcyjność jest trudna do osiągniecia | Jedna baza danych, operacje transakcyjne na wyciągnięcie ręki |
Wady mikroserwisów
Powyższa tabela pokazuje pewne wady mikroserwisów, podsumuję jeszcze poniżej problemy, które uderzają od samego początku przygody z mikroserwisami:
- Złożoność systemu: podział na mniejsze moduły i wiele usług skutkuje większą liczbą procesów, co zwiększa złożoność systemu.
- Wymagane umiejętności: pracownicy muszą być wykwalifikowani w dziedzinie rozwiązywania problemów związanych z mikroserwisami oraz w dziedzinie zarządzania usługami.
- Koszty: koszty infrastruktury, oprogramowania i licencji wzrastają, ale elastyczność i skalowalność aplikacji mogą przynieść korzyści.
- Problemy z utrzymaniem spójności danych: gdy dane są rozproszone w różnych usługach, utrzymanie spójności danych staje się trudniejsze i wymaga dodatkowych nakładów pracy.
- Problemy z testowaniem: testowanie systemu złożonego z wielu usług jest trudniejsze i wymaga więcej zasobów.
- Problemy z bezpieczeństwem: mikroserwisy komunikują się przez sieć, co wymaga zwrócenia uwagi na bezpieczeństwo przesyłanych danych tak, aby tylko upoważnione serwisy mogły z nich korzystać.
Mikrousługi a podejście DDD
Podejście DDD (Domain-Driven Design) skupia się na projektowaniu i rozwijaniu aplikacji zgodnie z biznesowymi potrzebami i wymaganiami. DDD jest zbiorem praktyk tworzenia architektury systemów z uwzględnieniem dziedziny biznesu i jej problemów.
Mikroserwisy są często stosowane w podejściu DDD, ponieważ pozwalają na łatwe podzielenie aplikacji na mniejsze, bardziej zrozumiałe części, które są bardziej związane z konkretnymi dziedzinami biznesowymi. Dzięki temu, mikroserwisy mogą być projektowane zgodnie z biznesowymi potrzebami i spełniać wymagania użytkowników w bardziej precyzyjny sposób.
W podejściu DDD, mikroserwisy są projektowane tak, aby reprezentować poszczególne części dziedziny biznesowej. Każdy mikroserwis odpowiada za jedną konkretną funkcjonalność lub dziedzinę biznesową, co pozwala na łatwiejszą organizację pracy zespołów i lepsze zrozumienie biznesu.
Warto zauważyć, że pomimo tego, że mikroserwisy są często stosowane w podejściu DDD, to nie są one jedynym sposobem projektowania aplikacji zgodnie z tym podejściem. DDD zakłada, że projektowanie aplikacji powinno być elastyczne i dostosowane do konkretnych potrzeb biznesowych, co oznacza, że różne podejścia mogą być stosowane w zależności od sytuacji.
Analiza dziedzin biznesowych
Dziedzina biznesowa to obszar wktórym działa firma lub organizacja. Obejmuje ona wszystkie procesy, systemy, procedury i działy firmy, które wpływają na jej funkcjonowanie i sukces. W podejściu DDD, dziedzina biznesowa jest kluczowa dla projektowania aplikacji, ponieważ pomaga w zrozumieniu potrzeb i wymagań użytkowników oraz umożliwia projektowanie aplikacji zgodnie z biznesowymi potrzebami.
Poddziedzina biznesowa to mniejsza część dziedziny biznesowej, która skupia się na konkretnym aspekcie działalności firmy lub organizacji. Każdy mikroserwis odpowiada za jedną konkretną funkcjonalność w dziedzinie biznesowej lub nawet za całą poddziedzinę biznesową.
Bounded Context
Bounded Context to pewien poziom abstrakcji, na którym projektujemy nasz system. Odpowiada on za wyodrębnienie konkretnych obszarów funkcjonalnych (w kontekście biznesowym), w których nasza aplikacja działa. Każdy z tych obszarów jest od siebie oddzielony i posiada swoje specyficzne wymagania. Dzięki temu, mikroserwisy mogą być projektowane zgodnie z biznesowymi potrzebami i spełniać wymagania użytkowników w bardziej precyzyjny sposób.
Komunikacja między mikroserwisami
Komunikacja między mikroserwisami odbywa się przez sieć, wykorzystując różne protokoły i formaty danych. Istnieją różne podejścia do komunikacji między mikroserwisami, w tym REST, gRPC, AMQP i wiele innych.
Jednym z popularnych podejść do komunikacji między mikroserwisami jest REST (Representational State Transfer). REST jest to architektura, która umożliwia wymianę zasobów między klientami a serwerami. W przypadku mikroserwisów, REST umożliwia komunikację między różnymi usługami poprzez standardowe protokoły HTTP i JSON.
Innym popularnym podejściem do komunikacji między mikroserwisami jest gRPC. gRPC to open-source’owy framework do zdalnego wywoływania procedur (RPC), który został opracowany przez firmę Google. gRPC umożliwia komunikację między różnymi usługami poprzez protokół HTTP/2 oraz format protokołu binarnego protobuf.
AMQP (Advanced Message Queuing Protocol) to kolejne podejście do komunikacji między mikroserwisami. AMQP to protokół komunikacyjny, który umożliwia przesyłanie wiadomości między różnymi usługami. Protokół ten umożliwia asynchroniczną wymianę wiadomości między usługami, co może być przydatne w przypadku aplikacji o dużej liczbie użytkowników.
Istnieje wiele innych podejść do komunikacji między mikroserwisami, a wybór konkretnego podejścia zależy od wielu czynników, takich jak wymagania biznesowe, skala aplikacji i preferencje deweloperów.
Abstrahując od protokolów i formatów danych komunikację między serwisami można podzielić na dwa podstawowe typy:
- synchchroniczna (blokująca)
- asynchroniczna (nieblokująca)
Czy architektura mikroserwisowa sprawdzi się w moim projekcie?
Architektura mikroserwisów może być dobrym wyborem, jeśli tworzysz dużą aplikację, która ma wiele złożonych funkcjonalności lub jeśli potrzebujesz elastyczności i skalowalności w zarządzaniu aplikacją. Mikroserwisy pozwalają na łatwe wprowadzanie zmian w aplikacji, jej skalowanie oraz lepsze zarządzanie nią. Mikroserwisy umożliwiają też elastyczną organizację pracy zespołu, co przekłada się na większą efektywność i szybkość działania. Jednakże, przed podjęciem decyzji, warto dokładnie przeanalizować potrzeby swojego projektu i zastanowić się, czy mikroserwisy są najlepszym rozwiązaniem dla twojego przypadku.
Konsekwencje użycia architektury mikro serwisowej
Wszystko w architekturze jest trade-offem, a mówiąc bardziej po polsku: każde rozwiązanie oprócz plusów ma też swoje minusy. Wybór konkretnej architektury niesie za sobą konsekwencje. Dzisiaj chciałbym Ci pokazać, jakie konsekwencje niesie za sobą wybranie architektury mikro serwisowej.
Możliwość użycia różnych technologii
Do każdej mikro usługi możesz zastosować inne technologie. Nic nie przeszkadza, żeby w jednej była baza danych relacyjna, a w drugiej nierelacyjna. W jednej programujesz w NodeJS, a w innej w Java. Może być jeszcze lepiej: jedna mikro usługa w Java, a druga w JavaScript. To naprawdę jest możliwe.
Z drugiej strony architektura mikro serwisowa sprzyja wprowadzaniu nowych technologii. W architekturze monolitycznej wymiana języka programowania jest raczej niemożliwa, a większość zmian będzie zazwyczaj bardzo kosztowna. Poza tym dodanie nowej (nieznanej) technologii wiąże się z dużym ryzykiem popełnienia błędu. W przypadku mikro serwisów możesz eksperymentować, nie ponosząc wielkiego ryzyka, bo pracujesz na dużo mniejszej skali.
Złożoność
Każdy mikro serwis zwiększa złożoność systemu. Złożoność systemu zwiększa też trudności w codziennej pracy programisty. Monolit można łatwo uruchomić na środowisku lokalnym i go rozwijać. Gdy przyjdzie CI uruchomić 50 mikro serwisów na lokalu, to już przestaje robić się wesoło.
Złożoność technologii może być też przytłaczająca dla programistów. Wprowadzanie mikro serwisów często wykorzystywana jest przez firmy do eksperymentowania z nowymi technologiami i językami programowania. To wszystko wiąże się z dużymi wyzwaniami i na pewno potrzeba dużej ilością czasu na zrozumienie nowości, nowinek technicznych oraz nowej architektury.
Większa odporność na błędy
Popełnienie błędu w systemie monolitycznym może oznaczać, że cały system wybuchnie i przestanie działać. Błąd w mikro serwisie powoduje, że tylko ta usługa, w której wystąpił błąd przestanie działać.
Skomplikowane testowanie
Testy e2e mikro serwisów kosztują więcej przez trudniejszą konfigurację i tracą na pewności, ponieważ aplikacja może przestać działać np. podczas problemu z połączeniem sieciowym podczas testowania.
Wdrażanie
Mikro serwisy można wdrażać niezależnie, a więc zrobienie zmiany w jednej usłudze powoduje konieczność deploy tylko tej jednej usługi.
Skalowanie
W przypadku korzystania z mikro serwisów możesz skalować tylko te usługi, które tego wymagają. Daje to duże możliwości optymalizacji.
Koszty
Koszt infrastruktury wzrasta. Koszt oprogramowania i licencji wzrasta. Koszt nauki wzrasta. Czy coś maleje? Z pewnością tempo pracy na początku wdrażania mikro serwisów. Koszty maleją dopiero z czasem, a na dobre efekty wyboru mikorserwisów trzeba długo zaczekać. Naturalnym pytaniem jest to, czy w takim razie architektura mikro serwisowa jest dobra dla startupów?
Elastyczność
Mikroserwisy dają elastyczność. Niestety nie ma nic za darmo. Tak naprawdć decydując się na mikro serwisy to kupujesz tą elastyczność. Jakie są koszty, przeczytałeś już paragraf wyżej.
Spójność danych
Bazodanowe transakcje działają świetnie w systemach monolitycznych. Zrobienie czegoś podobnego w architekturze mikroserwisowej nie jest już takie proste zadanie.
Analityka
W systemie monolitycznym masz jedną baze danych. Możesz tą baze monitorować i w łatwy sposób wyciągać z niej informacje, które są Ci potrzebne. W mikroserwisach dane są rozproszone, jest wiecej niż jedna baza danych co sprawia, że analizowanie danych jest trudniejsze.
Monitorowanie
Podobnie jak z analityką – zamiast monitorować jeden system, musisz monitorować kilka mikro serwisów. Znalezienie błędu i problemu jest trudniejsze niż przy monolicie.
Bezpieczeństwo
Mikroserwisy komunikuja się przez sieć. Oznacza to konieczność zwrócenia uwagi na bezpieczeństwo przesyłanych danych tak tylko aby upoważnione serwisy mogły z nich korzystać.
Opóznienia
Konsekwencją komunikacji przez sieć są opóznienia, które spowalniają działanie całego systemu i sprawiają, że czasem może działać on w nieprzewidywalny sposób.
Podsumowanie
Architektura mikroserwisowa to podejście do tworzenia aplikacji, które pozwala na większą elastyczność, skalowalność i łatwiejsze zarządzanie aplikacją. Dzięki temu podejściu, aplikacja może być łatwiej rozwijana i utrzymywana, co jest szczególnie ważne w przypadku dużych projektów. Jednakże, wybór konkretnej architektury zawsze niesie za sobą konsekwencje. W przypadku mikroserwisów, złożoność systemu i koszt infrastruktury wzrastają, a testowanie i monitorowanie stają się bardziej skomplikowane. Z drugiej strony, mikroserwisy pozwalają na elastyczne organizowanie pracy zespołów, łatwe wprowadzanie zmian w aplikacji, jej skalowanie oraz lepsze zarządzanie nią. Przed podjęciem decyzji o wyborze architektury, warto dokładnie przeanalizować potrzeby swojego projektu i zastanowić się, czy mikroserwisy są najlepszym rozwiązaniem dla twojego przypadku.
