Mikroserwisy w akcji. Отсутствует
jak jest projektowana aplikacja mikroserwisowa, aby składała się z czterech poziomów – platformy, usługi, granicy i klienta – oraz dowiemy się, czym one są i jak się łączą, aby dostarczyć aplikacje ukierunkowane na klienta. Podkreślimy także rolę szkieletów zdarzeń w budowaniu aplikacji mikroserwisowych na dużą skalę i omówimy różne wzorce do budowania granic aplikacji, takie jak bramy API. Na koniec wspomnimy o najnowszych trendach w budowaniu interfejsów użytkownika dla aplikacji mikroserwisowych, takich jak mikrofrontendy i kompozycje frontendów.
3.1. Architektura jako całość
Jako projektanci chcemy tworzyć oprogramowanie podatne na zmiany. Na nasze oprogramowanie ma wpływ wiele bodźców: nowe wymagania, usterki, potrzeby rynkowe, nowi klienci, wzrost itd. Najlepiej, abyśmy mogli odpowiadać na te naciski w stałym tempie. Aby to osiągnąć, nasze podejście do rozwoju powinno zmniejszać tarcie i minimalizować ryzyko.
Nasz zespół inżynierów z czasem usunie wszelkie przeszkody w rozwoju, a system będzie ewoluował. Chcemy mieć możliwość szybkiego i płynnego zastąpienia dowolnego składnika systemu, który stanie się przestarzały. Pragniemy mieć zespoły, które mogą stać się całkowicie autonomiczne i odpowiedzialne za części większego systemu. Chcemy także, aby te zespoły współistniały bez potrzeby ciągłej synchronizacji i bez blokowania innych zespołów. W tym celu należy pomyśleć o architekturze – planie tworzenia aplikacji.
3.1.1. Od monolitów do mikroserwisu
W przypadku aplikacji monolitycznej głównym produktem jest pojedyncza aplikacja. Ta aplikacja jest podzielona poziomo na różne warstwy techniczne – w typowej aplikacji trójwarstwowej będą to dane, logika i prezentacja (rys. 3.1) – oraz pionowo na różne obszary biznesowe. Wzorce, takie jak MVC, i frameworki, takie jak Rails i Django, odzwierciedlają model trójwarstwowy. Każda warstwa udostępnia usługi wyższemu poziomowi: warstwa danych zapewnia trwałość, warstwa logiki wykonuje konkretne działania, a warstwa prezentacji przedstawia wyniki użytkownikowi końcowemu.
Rysunek 3.1. Architektura typowej trójwarstwowej aplikacji monolitycznej
Pojedynczy mikroserwis jest podobny do monolitu: przechowuje dane, wykonuje pewną logikę biznesową oraz przekazuje dane i wyniki do konsumentów za pośrednictwem API. Każdy mikroserwis jest właścicielem biznesowych lub technicznych zdolności aplikacji i w celu wykonania zadania współdziała z innymi mikroserwisami. Na rysunku 3.2 przedstawiono ogólną architekturę pojedynczej usługi.
Rysunek 3.2. Ogólna architektura pojedynczego mikroserwisu
UWAGA W rozdziale 4 szczegółowo omówimy określanie zakresu mikroserwisów – jak definiować ich granice i odpowiedzialność.
W monolitycznej aplikacji nasza architektura jest ograniczona do granic samej aplikacji. W aplikacji mikroserwisowej planujemy coś, co będzie ewoluować zarówno pod względem wielkości, jak i zakresu. Pomyślmy o tym jak o mieście – budowanie monolitu przypomina budowanie wieżowca, podczas gdy budowa aplikacji mikroserwisowej jest jak budowanie otoczenia – trzeba zbudować infrastrukturę (kanalizację, drogi, kable) oraz warunki do rozwoju (strefa przemysłowa kontra domy mieszkalne).
Ta analogia podkreśla znaczenie uwzględnienia nie tylko samych komponentów, ale także sposobu, w jaki się łączą, miejsca ich umieszczenia i sposobu ich jednoczesnego budowania. Chcemy, aby nasz plan zachęcał do rozwoju w dobrym kierunku, zamiast dyktować lub wymuszać pewną strukturę w całości aplikacji.
Co najważniejsze, nie uruchamiamy mikroserwisu w izolacji; każda usługa żyje w środowisku, które umożliwia jej budowanie, wdrażanie i uruchamianie w porozumieniu z innymi mikroserwisami. Nasza architektura aplikacji powinna zatem obejmować całe takie środowisko.
3.1.2. Rola architekta
Gdzie w tym wszystkim znajdują się architekci oprogramowania? Wiele firm zatrudnia architektów oprogramowania, chociaż skuteczność i podejście do tej roli jest bardzo różne.
Aplikacje mikroserwisowe umożliwiają szybkie zmiany: ewoluują, gdy zespoły budują nowe usługi, wycofują istniejące usługi, refaktoryzują istniejące funkcjonalności itd. Naszym zadaniem jako architekta lub technicznego lidera jest umożliwienie ewolucji, a nie zajmowanie się projektem. Jeśli aplikacja mikroserwisowa jest miastem, to my jesteśmy planistami pracującymi dla rady miejskiej.
Zadaniem architekta jest upewnienie się, że podstawy techniczne aplikacji wspierają szybkie tempo i płynność. Architekt powinien mieć globalną perspektywę i upewnić się, że globalne potrzeby aplikacji są spełnione, kierując się jej ewolucją, a także tym, że:
■ aplikacja jest dostosowana do szerszych celów strategicznych firmy;
■ zespoły mają wspólny zestaw wartości technicznych i oczekiwań;
■ przekrojowe aspekty – takie jak obserwowalność, wdrażanie i komunikacja między usługami – spełniają potrzeby wielu zespołów;
■ cała aplikacja jest elastyczna i plastyczna w obliczu zmian;
Aby osiągnąć te cele, architekt powinien kierować rozwojem dzięki:
■ zasadom – wytycznym, których zespół powinien przestrzegać, aby osiągnąć wyższe cele techniczne lub organizacyjne;
■ modelom koncepcyjnym – ogólnym modelom relacji systemowych i wzorców na poziomie aplikacji.
3.1.3. Zasady architektoniczne
Zasady są wytycznymi (lub czasem regułami), których zespoły powinny przestrzegać, aby osiągnąć cele wyższego poziomu. Informują o praktyce zespołowej. Na rysunku 3.3 przedstawiono taki model. Jeśli celem produktu jest na przykład sprzedanie go przedsiębiorstwom wrażliwym na ochronę prywatności i bezpieczeństwo, możemy określić następujące zasady:
■ praktyki rozwojowe muszą być zgodne z uznanymi normami zewnętrznymi (np. ISO 27001),
■ wszystkie dane muszą być przenaszalne i przechowywane z uwzględnieniem wymagań bezpieczeństwa,
■ dane osobowe muszą być monitorowane i możliwe do prześledzenia za pomocą aplikacji.
Rysunek 3.3. Podejście architektoniczne oparte na zasadach technicznych
Zasady są elastyczne. Mogą i powinny się zmieniać, aby odzwierciedlać priorytety działalności i ewolucję techniczną naszej aplikacji. Na przykład na wczesnym etapie możemy nadać priorytet dopasowaniu produktu do rynku, podczas gdy bardziej dojrzała aplikacja może wymagać skoncentrowania się na wydajności i skalowalności.
3.1.4. Cztery warstwy aplikacji mikroserwisowej
Architektura powinna odzwierciedlać jasny model koncepcyjny wysokiego poziomu. Model jest użytecznym narzędziem do wnioskowania o strukturze technicznej aplikacji. Model wielopoziomowy, podobnie jak trójwarstwowy model przedstawiony na rysunku 3.1, jest wspólnym podejściem do struktury aplikacji odzwierciedlającym warstwy abstrakcji i odpowiedzialności w całym systemie.
W dalszej części rozdziału omówimy czterowarstwowy model aplikacji mikroserwisowej:
■ platforma – platforma mikroserwisowa zapewnia narzędzia, infrastrukturę i prymitywy wysokiego poziomu w celu wspierania szybkiego rozwoju, działania i wdrażania mikroserwisów; dojrzała warstwa umożliwia inżynierom skupienie