Architektura mikrousługowa robi się coraz bardziej popularna. Jeżeli popatrzeć na wykres Google Trends dla hasła microservices na cały świat w ciągu ostatnich 5 lat, okaże się, że w roku 2018 hasło to jest wyszukiwane 10 razy częściej niż jeszcze 3 lata temu.
Rozbicie dużego, monolitycznego systemu budowanego przez lata na pojedyncze, niezależne usługi – mikroserwisy – wymaga czasu. Pozwala to jednak bezpieczniej biznesowo budować rozwiązania IT w taki sposób, aby możliwe było pewne uniezależnienie – polegające na możliwości wytwarzania części systemu przez jednego wykonawcę, a drugiej przez inną firmę tworzącą oprogramowanie. Przed wdrożeniem takiej zmiany warto więc się zastanowić i określić zakres prac, decydując, które obszary systemu mają zostać przeniesione do architektury mikroserwisowej, a także wybrać odpowiednie narzędzia.
Popularność architektury mikroserwisowej przekłada się na wzrost ilości narzędzi pozwalających w niej budować. Postaram się przybliżyć trzy z nich, z których korzystaliśmy przy migracji z monolitu do mikroserwisów w systemie europejskiej platformy transportowej, na której codziennie zawierane są setki tysięcy transakcji.
1) RabbitMQ
Implementacja protokołu AMQP w wydaniu open source. Wykorzystanie message broker’a umożliwiło odseparowanie (tzw. “loose coupling”) mikrousług od siebie. Dzięki temu możemy bezproblemowo skalować system. Brak ścisłych powiązań pomiędzy poszczególnymi usługami skrócił czas opracowania kolejnych wydań i podniósł bezawaryjność systemu. Awaria jednego komponentu nie rozprzestrzenia się na resztę systemu.
Rozbicie dużego, monolitycznego systemu budowanego przez lata na pojedyncze, niezależne usługi – mikroserwisy – wymaga czasu. Przed wdrożeniem takiej zmiany warto więc się zastanowić i określić zakres prac, decydując, które obszary systemu mają zostać przeniesione do architektury mikroserwisowej.Pozwala to jednak bezpieczniej biznesowo budować rozwiązania IT w taki sposób, aby możliwe było pewne uniezależnienie – polegające na możliwości wytwarzania części systemu przez jednego wykonawcę, a drugiej przez inną firmę tworzącą oprogramowanie.
2) REST
Częstym wyzwaniem w projektowaniu rozproszonej architektury systemów jest zachowanie spójności pomiędzy różnymi komponentami takiego systemu. Aby ułatwić komunikację, zarówno wewnętrzną – pomiędzy usługami systemu, jak i zewnętrzną – integrację z zewnętrznymi firmami, zdecydowaliśmy się wdrożyć ogólny standard komunikacji z systemem. Dzięki REST api komunikacja z naszymi usługami stała się prosta, intuicyjna i doskonale udokumentowana.
3) Consul
Kolejnym wyzwaniem rozproszonego systemu opartego o mikroserwisy jest dbanie o możliwie jak największą elastyczność. Komunikacja poprzez “szynę danych AMQP” zlikwidowała ograniczenia w komunikacji pomiędzy serwisami, lecz aby w pełni wykorzystać brak takiego ograniczenia, potrzebna była możliwość dynamicznego skalowania i konfigurowania systemu. Tu z pomocą przyszedł Consul – narzędzie, dzięki któremu informacja o przeskalowaniu dowolnej części systemu stawała się automatycznie widoczna w całym systemie.
Stworzenie wydajnej, skalowalnej i dobrze udokumentowanej architektury opartej o mikroserwisy to nie lada wyzwanie. Opisane narzędzia mocno to ułatwiły w projekcie platformy transportowej, z której codziennie korzysta kilkadziesiąt tysięcy użytkowników.
Karol Kaczmarek,
Development Teams Leader w RST Software Masters. Doświadczenie zdobywał jakoprogramista PHP, iOS/Objc, Nodejs, architekt systemów. Ponad wszystko ceni sobie elegancję tworzonych rozwiązań oraz ich wartość dla użytkownika końcowego. Entuzjasta modelu agile w tworzeniu oprogramowania.
Jeśli interesują Was szczegóły migracji od monolitu do mikroserwisów, więcej znajdziecie w ebooku RST mikroserwisy, który opracowaliśmy podsumowując kilka lat praktycznych doświadczeń z wykorzystania architektury mikrousługowej.
