Скачать книгу

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, logikaprezentacja (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.

35077.jpg

      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.

35109.jpg

      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.

35261.jpg

      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

Скачать книгу