Budowanie przyszłości: architektura mikroserwisów

Omawiając 2-3-letnią mapę drogową architektury dla systemu e-commerce, który działa już od kilku lat, typowe pytanie brzmi : czy musimy przejść na architekturę mikrousług?

Mikroserwisy to obecnie modne hasło, więc naturalne jest rozważenie ich przy ewolucji systemu. Jednak główne bodźce przekształcenia monolitycznego systemu w mikrousługi mają tak naprawdę charakter biznesowy i operacyjny, na przykład:

1. Projektowanie z myślą o rozwoju firmy: ponieważ system obsługuje więcej klientów i przetwarza więcej transakcji, potrzebuje większej wydajności i zasobów. Jednak nie wszystkie części systemu mogą rosnąć z tą samą prędkością.
2. Obsługa szczytów ruchu: W idealnym przypadku system powinien być w stanie skalować się automatycznie lub przynajmniej dynamicznie w taki sposób, aby infrastruktura nie była wypychana do maksymalnej przepustowości w celu obsługi szczytowego ruchu przez cały czas.
3. Szybszy czas wprowadzania na rynek: Dla firmy jest to znacząca wartość, ponieważ dodanie lub zmodyfikowanie funkcji zajmuje dni lub tygodnie zamiast miesięcy i nie wymaga nadmiernych (i często kosztownych) testów regresji i ponownego uruchomienia wszystkich aplikacji działających w całym środowisku. Odpowiedzią na to jest modułowość i projektowanie pod kątem zastępowalności, które ułatwiają mikroserwisy.
4. Szybkie, natychmiastowe zmiany w treści i doświadczeniu użytkownika: Wiele tradycyjnych systemów online generuje treści dynamicznie po stronie serwera, z tej samej aplikacji internetowej, która zawiera również funkcje do kasy, mojego konta i innych funkcji (np. monolit). Oznacza to, że chociaż treść skierowana do klienta może być aktualna, potencjalnie spersonalizowana i zarządzalna, stale odnawiająca się ta treść pochłania ogromną ilość cykli procesora, tworząc zależności online od magazynów danych i potencjalnie innych podsystemów.

Ostatecznym celem architektury mikroserwisów jest rozbicie tej aplikacji na stosunkowo niezależne usługi, które obsługują domyślną zawartość, dostarczają informacji o stanie zapasów oraz obsługują spersonalizowane oferty i rekomendacje. Usługi te można następnie dostrajać, skalować i zarządzać nimi, aby osiągnąć jak najlepsze wrażenia użytkownika.

Pomysł polega na tym, aby system składał się z kilku samodzielnych, skalowalnych i wymiennych usług.

Cegła po cegle: Stopniowe przesuwanie systemu

Powstaje zatem pytanie, jak realizujemy ten plan? Przepisywanie systemu od podstaw jest zwykle niedopuszczalne. Istnieje inwestycja w obecną platformę, funkcjonalność została przetestowana i sprawdzona lub istnieją inne ulepszenia funkcjonalne, które należy uzupełnić w obecnym systemie.

Lepszym podejściem może być uzgodnienie architektury docelowej i rozpoczęcie stopniowego przesuwania systemu w kierunku celu poprzez uwzględnienie działań związanych z przebudową architektury w planie rozwoju mapy drogowej:

1. Zidentyfikuj zmianę, która rozwiązałaby najważniejszy problem biznesowy i zaplanuj refaktoryzację/migrację. Na przykład „oddzielenie zarządzania treścią od transakcyjnych części systemu ”, dzięki czemu zmiany mogą być szybciej wprowadzane na stronę.
2. Dodając funkcję (na przykład „Możesz też polubić” lub „Jeśli wydasz dodatkowe X…”) zamiast łączyć ją z bieżącą aplikacją, zastanów się, czy jest to coś, co może zapewnić wartość jako samodzielna usługa, która udostępnia interfejs i może być zarządzany niezależnie. Nie musi działać jako samodzielny proces lub być wdrażany samodzielnie na początku, ale powinien być dobrze zamknięty z minimalnymi dobrze zrozumiałymi zależnościami.
3. Dokonując znaczącej zmiany w podsystemie — na przykład MyAccount — zastanów się, czy może to być odpowiedni moment, aby uczynić tę aplikację lub usługą samą w sobie. Ponownie, ważnym czynnikiem jest rozważenie zależności — zarówno od kodu, jak i poziomu środowiska wykonawczego.

Jeśli wprowadzenie zmiany w usłudze MyAccount wymaga ponownej kompilacji i ponownego wdrożenia wszystkich innych modułów, to nie jest to dobry kandydat do migracji (jeszcze). Ale mogą istnieć inne moduły kandydujące, które obejmują ich własne specyficzne problemy dotyczące domeny:

• • Usługa komunikacji e-mail klienta
  • Zamówienie jako usługa
  • Usługa dostępności przedmiotu
  • Wyszukiwarka handlowa
  • Różne usługi personalizacji, doradztwa lub rekomendacji
  • Recenzje/oceny produktów

Skalowanie projektu we właściwy sposób: Definiowanie procesów i planów architektury mikroserwisów

Jak widać, obraz ten może szybko zacząć czuć się zajęty, wraz ze wzrostem liczby usług i poczuciem zwiększonej złożoności rozwiązania. Aby sobie z tym poradzić, zespoły muszą zwrócić szczególną uwagę na następujące aspekty projektu:

Przejrzystość architektury: niekoniecznie oznacza to podejście „dużego projektu z góry”, ale zespół musi mieć wspólną wizję i zrozumienie, z jakich usług będzie składał się system oraz w jaki sposób usługi będą budowane, wdrażane i monitorowane. Zespół musi być przygotowany na przyjęcie różnych praktyk (API-first), frameworków (Spring Cloud), wspólnych elementów infrastruktury aplikacji – API Gateway, serwera uwierzytelniającego, rejestru usług itp. Nie wszystkie z nich są zawsze potrzebne, ale muszą być świadoma decyzja architektoniczna, czy będą częścią systemu, czy nie.

DevOps: To kolejne popularne hasło, ale niezwykle ważne w tym kontekście. Wraz z rozwojem systemu liczba usług może stać się przytłaczająca, dlatego w świecie mikroserwisów DevOps jest niezbędnym elementem. Oznacza to automatyzację i usprawnienie kompilacji, testowanie wdrażania, restarty, automatyczne skalowanie, alarmowanie itp. Nie mamy do czynienia z pojedynczym plikiem binarnym wdrożonym na kilku serwerach aplikacji. Mogą istnieć dziesiątki mniejszych elementów funkcjonalności, z których każdy może działać w wielu instancjach, nie jest to coś, co każdy chce obsługiwać ręcznie. Wyobraź sobie ręczne zbieranie dzienników ze wszystkich uruchomionych aplikacji…

Architektura mikroserwisów: robienie tego dobrze

Istnieje wiele sposobów na złą migrację do mikroserwisów: po prostu podążając za szumem technologicznym, bez uzasadnienia biznesowego, identyfikując nieodpowiednie usługi, które są zbyt zależne od siebie, nie stosując praktyk DevOps w celu rozwiązania złożoności, nie rozwijając odpowiednie umiejętności w zespole itp.

Jednak przy odpowiednim planowaniu i zarządzaniu ryzykiem, po pewnym czasie (i stresie, wątpliwościach i panice PM) zespół powinien zacząć odczuwać pozytywny wpływ:

• System lub jego ważne części lepiej skalują się
• Łatwiej jest dostarczyć nową funkcję bez konieczności ponownego uruchamiania wszystkiego w środku nocy
• Komponenty systemu mają wyraźniejszy cel, a zatem są prostsze w opracowywaniu, testowaniu i wymianie

Mapa drogowa architektury jest narzędziem, które pomaga wyznaczyć kierunek ewolucji systemu na dwa-trzy lata w przyszłość.

Musi być dobrze dostosowany do planu biznesowego, strategicznego kierunku technologii i branży oraz do umiejętności i możliwości zespołu. Jego znaczenie wzrasta zwłaszcza wraz z wprowadzeniem nowych koncepcji architektonicznych i podejść, takich jak mikrousługi.