Czy wiesz, jak zbudować system, który pozwoli na łatwe i częste dostarczanie użytkownikom nowych funkcji? Czy wiesz, co zrobić, aby jedna zmiana nie powodowała niedostępności całej aplikacji? Odpowiedzi na te pytania może przynieść architektura mikroserwisowa.
Mikroserwisy (lub mikrousługi) to niewielkie usługi – obejmujące jeden obszar biznesu – których przygotowanie zajmuje maksymalnie kilka tygodni. Mówi się o nich od kilku lat. Wśród powodów, dla których zdobywają popularność, znajdują się m.in. lepsza kontrola nad poziomem długu technicznego, skrócenie czasu wydawania wersji, podniesienie stabilności systemu.
Jeśli rozwijasz duży system ze sporym repozytorium kodu, który nie jest w całości pokryty testami automatycznymi, każde wdrożenie nowszej wersji wymaga wykonywania czasochłonnych, ręcznych testów regresyjnych. Taki monolit bywa nieprzewidywalny – wdrożenie nowej funkcji (nawet pokrytej testami automatycznymi zgodnie z dobrymi praktykami inżynierii kodu) może spowodować wystąpienie błędu w innym miejscu i zablokowanie całego systemu.
Sytuacja komplikuje się dodatkowo w momencie, gdy nad rozwojem systemu pracuje wiele zespołów deweloperskich. Ostatecznie kończy się to wydłużonym czasem oddawania nowych funkcjonalności biznesowi – ze względu na testy od momentu postawienia wymagań do udostępnienia produkcyjnego może minąć nawet kilka tygodni.
W porównaniu z monolitem mikrousługi mają szereg zalet. Pozwalają lepiej kontrolować poziom długu technicznego, redukują ryzyko zatrzymania pracy całego systemu ze względu na drobny błąd w jednym obszarze, umożliwiają szybsze i częstsze wdrożenia nowych wersji.
Architektura mikroserwisowa wydaje się idealna zwłaszcza w sytuacji, gdy trzeba często testować pomysły na nowe funkcjonalności i sprawdzać, jak zareagują na nie użytkownicy.
Zanim zaczniesz – wybierz scenariusz migracji
Dekompozycja monolitu na mikrousługi w przypadku większego systemu może zająć całe lata. Na szczęście można wybrać drogę pośrednią, która polega na stopniowej migracji i ograniczaniu roli monolitu poprzez wydzielanie z niego kolejnych mikroserwisów.
O czym warto pamiętać, gdy mamy już wybrany scenariusz migracji i wstępnie określony zakres przejścia na architekturę mikrousługową?
Poniżej znajdziecie subiektywną – i na pewno możliwą do udoskonalenia – listę, stworzoną na podstawie kilku lat pracy z architekturą mikroserwisową w platformie transportowej, na której zawierane są setki tysięcy transakcji miesięcznie. Nie jest to może jeszcze skala Allegro czy Netflixa, również używających mikrousług, ale pozwala odkryć, o co warto zadbać przy przejściu na mikroserwisy.
1. Wskaż właściciela mikroserwisu
Zadbaj o to, aby każda mikrousługa miała wyraźnie zdefiniowanego właściciela. Ustalenie właściciela nadaje mu pewien obszar swobody, ale także przypisuje odpowiedzialność. Skróci to czas zgłaszania nowych funkcjonalności lub awarii.
2. Zadbaj o monitoring i dokumentację
Wprowadź monitorowanie jakości pracy mikroserwisów, dzięki któremu zapobiegniesz awariom. Idealnie byłoby jednocześnie prowadzić dziennik zmian, umożliwiający śledzenie nowych funkcji lub poprawek błędów.
3. Zapewnij niezależność mikroserwisów
Staraj się z wyprzedzeniem identyfikować zależności, aby dobrze zaplanować rozwój systemu. Dbaj o możliwie wysoką niezależność poszczególnych mikroserwisów – dzięki temu uzyskasz wysoką dostępność rozwiązania.
4. Pomyśl o standaryzacji
Wykorzystaj standardowe sposoby, aby ujednolicić komunikację w systemie i poza nim. Ułatwi to zwłaszcza rozwój rozległego systemu, otwierającego się naraz w wielu nowych kierunkach.
5. Wykorzystaj gotowe szkielety
Sięgnij po frameworki do tworzenia mikroserwisów albo opracuj własne szkielety. Dzięki temu oszczędzisz czas na dostosowanie się do standardów.
Więcej o mikrousługach można znaleźć na stronach Chrisa Richardsona microservices.io, a od strony technicznej realizacji na stronach dostawców chmury publicznej:
- Microsoft Azure: Microservices architecture style
- AWS: What are Microservices?
- Google Cloud Platform: Microservices Architecture on Google App Engine
Zachęcam też do lektury mojego ebooka: Od monolitu do mikroserwisów, czyli jak wyjść z architektury hamującej rozwój.
