Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 33

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 się na budowaniu funkcjonalności, a nie na detalach;

■ usługi – w tej warstwie budowane usługi współdziałają ze sobą, zapewniając biznesowe i techniczne zdolności wspierane przez platformę;

■ granica – klienci będą wchodzić w interakcje z aplikacją przez zdefiniowaną granicę, która udostępnia posiadaną funkcjonalność w celu zaspokojenia potrzeb użytkowników zewnętrznych;

■ klient – aplikacje klienckie, takie jak strony internetowe i aplikacje mobilne, wchodzą w interakcję z backendem mikroserwisowym.

Na rysunku 3.4 pokazano te warstwy architektoniczne. Powinniśmy móc je zastosować do dowolnej aplikacji mikroserwisowej, niezależnie od wybranej technologii.

Rysunek 3.4. Czteropoziomowy model architektury aplikacji mikroserwisowych

Każda warstwa jest oparta na zdolnościach niższych warstw; na przykład poszczególne usługi wykorzystują strumienie wdrażania, infrastrukturę i mechanizmy komunikacji, które zapewnia niższa platforma mikroserwisowa. Aby dobrze zaprojektować aplikację mikroserwisową, potrzebne są doświadczenie i inwestycje na wszystkich warstwach.

Wspaniale! Teraz mamy model, z którym możemy pracować. W kolejnych pięciu podrozdziałach przejdziemy przez każdą warstwę w tym modelu architektonicznym i omówimy, w jaki sposób przyczynia się ona do budowania trwałych, elastycznych i ewolucyjnych aplikacji mikroserwisowych.