Architektura mikroserwisów

Architektura mikroserwisów w ostatnim czasie zyskała na popularności w branży jako realna alternatywa dla aplikacji monolitycznych i architektur zorientowanych na usługi. Często niestety nie wiemy jak poprawnie zaprojektować aplikację opartą na mikroserwisach. Używamy takiej architektury ze względu na trend a nie wymagania biznesowe. Z drugiej strony wiele firm odnalazło się w mikroserwisach i radzą sobie świetne. Baa.. w internecie można znaleźć dużo cennych artykułów o tym jak im szło lub idzie [1, 2].

I’ll keep saying this … if people can’t build monoliths properly, microservices won’t help.

Simon Brown


Cześć 🙂

To jest kolejny artykuł z serii wzorców o architekturach aplikacyjnych. Poprzednie artykuły znajdziesz pod tym linkiem mini-seria wpisów.

W dzisiejszym artykule:


Czym jest architektura mikroserwisów

Mikroserwisy to styl architektoniczny, w którym pojedyncza aplikacja jest tworzona jako zestaw małych usług. Każda usługa działa w ramach własnego procesu i jest – albo przynajmniej powinna być – niezależna od innych. Warto podkreślić, że mikroserwis to nie jest zawsze pojedyczny projekt (moduł). W ramach jednego mikroserwisu możemy mieć kilka projektów (modułów), które tworzą jeden niezależny mikroserwis. Całkiem dobrze obrazuje to poniższy rysunek.

Wracając do niezależności – co dokładnie miałem na myśli? Każdy z serwisów powinien móc być wdrażany/testowany całkowicie oddzielnie od pozostałych usług. Tylko wtedy osiągniemy pełnię korzyści z tej architektury!

Mikroserwisy są implementacją wzorca SOA (Service-Oriented Architecture) z tą różnicą, że usługi mikroserwisowe są rozbijane na mniejsze – łatwiejsze do ogarnięcia. Zamiast monolitycznej aplikacji otrzymujemy N niezależnych, które mogą być rozwijane niezależnie przez kilka odrębnych zespołów.

Podsumowując, charakterystykę mikroserwisów można zamknąć w kilku punktach:

  • jest implementacją wzorca SOA
  • nie ma punktów centralnych, które orkiestrują powiązaniami pomiędzy serwisami (poszczególne usługi same wiedzą w jaki sposób komunikować się z innymi)
  • komponenty są luźno powiązane
  • najlepiej nadaje się do chmury (tam wyciągnie największe korzyści – skalowalność)

Topologie mikroserwisów

Architekturę mikroserwisów można podzielić na 3 główne topologie: API REST, Application REST i centralized messaging topology.

API REST – charakteryzuje się ‚drobnoziarnistymi’ (fine-grained) mikroserwisami. Oznacza to, że mikroserwisy są małe i wykonują konkretne zadanie biznesowe niezależnie od pozostałych mikroserwisów. Topologia przydatna dla stron internetowych, które udostępniają małe, niezależne, indywidualne usługi za pośrednictwem API.

Application REST – topologia typowa dla małych i średnich aplikacji biznesowych o stosunkowo niskim stopniu złożoności. Komponenty (moduły) usług różnią się od tych w topologii opartej na API-REST tym, że zwykle są większe (coarse-grained) i reprezentują niewielką część całej aplikacji biznesowej, a nie drobnoziarnistą, pojedynczą usługę.

Centralized messaging topology – jest podobna do Application REST, z tym wyjątkiem, że zamiast używać REST’a do komunikacji, używa lekkiego scentralizowanego brokera komunikatów (ActiveMQ, RabbitMQ, inna implementacja JMS). Scentralizowana topologia przesyłania wiadomości jest zwykle stosowana w większych aplikacjach biznesowych. Zalety to zaawansowane mechanizmy kolejkowania, asynchroniczne przesyłanie komunikatów, monitorowanie oraz lepszy load balancing i skalowalność.


Wady i zalety architektury

Zalety:

  • serwisy są małe i niezależne – a zatem łatwiejsze w rozwoju i zrozumieniu
  • łatwiejsza testowalność (mowa tylko o pojedynczym mikroserwisie)
  • możliwość niezależnego wdrażania (przynajmniej w teorii tak powinno być)
  • izolacja błędów – dzięki temu, że serwisy są od siebie niezależne, w przypadku gdy wystąpi błąd (np. wyciek pamięci) w jednym z serwisów nie powinno to wpłynąć na działanie innego
  • pozwala na użycie dowolnej technologi w nowych serwisach (może to być również wadą)
  • skalowalność (szczególnie zauważalne w technologiach chmurowych)

Wady:

  • dowolność technologiczna może prowadzić do chaosu
  • testowanie interakcji pomiędzy serwisami jest utrudnione
  • skomplikowana infrastruktura
  • utrudniona analiza komunikacji
  • IDE/narzędzia developerskie wciąż nie wspierają tak dobrze projektów opartych o mikroserwisy jak projektów monolitycznych

Podsumowanie

Decyzja o tym czy nowy projekt powinien iść w stronę mikroserwisów powinna być odraczana możliwie jak najdłużej. Bardzo często zamiast iść w kierunku mikroserwisów (bo są popularne) powinniśmy zacząć od monolitu. Wyjątkiem będzie naprawdę dobrze przemyślana architektura i wizja na przyszłość, gdzie od razu wiemy, że prędzej czy później mikroserwisy faktycznie przyniosą nam korzyści.

Mikroserwisy to fajna architektura. Ale należy pamiętać – dobór architektury zawsze powinien być podyktowany problemem biznesowym. Nasze ego czy też chęć cv-driven-development nie powinno zwyciężać bo może się okazać, że zatopimy projekt.

Źródła:


Za tydzień

Wejdziemy w świat DDD. Zaczniemy od poznawania fundamentów 🙂

0 0 vote
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments