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
• Topologie mikroserwisów
• Wady i zalety architektury

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:

• Software Architecture Patterns (Mark Richards) – Chapter 4. Microservices Architecture Pattern
• Pattern: Microservice Architecture
• Microservices
• Java Microservices: A Practical Guide

Za tydzień

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