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

Rozwój mikroserwisów jest wspierany przez pięć zasad kulturowych i architektonicznych:

■ autonomię,

■ odporność,

■ przejrzystość,

■ automatyzację,

■ ukierunkowanie.

Zasady te powinny wpływać na decyzje techniczne i organizacyjne podczas budowania i uruchamiania aplikacji mikroserwisowych. Przeanalizujmy każdą z nich.

AUTONOMIA

Ustaliliśmy, że mikroserwisy są autonomiczne – każda usługa działa i zmienia się niezależnie od innych. W celu zapewnienia autonomii nasze usługi musimy zaprojektować tak, aby były:

■ luźno powiązane – dzięki interakcji za pośrednictwem jasno zdefiniowanych interfejsów lub generowanych zdarzeń każdy mikroserwis może pozostawać niezależny od wewnętrznej implementacji współpracowników; na przykład usługa obsługi zleceń, którą wprowadziliśmy wcześniej, nie powinna być świadoma sposobu implementacji usługi transakcji na rachunku – zilustrowano to na rysunku 1.3;

■ niezależnie wdrażane – usługi będą tworzone równolegle, często przez wiele zespołów, gdyż konieczność ich łącznego wydawania doprowadziłaby do ryzykownych i niepewnych wdrożeń; najlepsze jest korzystanie z mniejszych usług, aby umożliwić ich szybkie, częste i małe wydania.

Autonomia jest także kulturą. Ważne jest, aby delegować odpowiedzialność i własność usług do zespołów odpowiedzialnych za wpływ na biznes. Jak ustaliliśmy, projekt organizacyjny ma wpływ na projektowanie systemu. Przejrzystość usług pozwala zespołom na iteracyjne budowanie i podejmowanie decyzji, oparte na lokalnym kontekście i celu. Ponadto, taki model jest idealny do promowania kompleksowej własności, gdy zespół jest odpowiedzialny za usługę zarówno w okresie rozwoju, jak i na produkcji.

Rysunek 1.3. Można luźno wiązać usługi komunikujące się za pomocą określonych kontraktów i ukrywające szczegóły implementacji

UWAGA  W rozdziale 13 omówimy rozwijanie odpowiedzialnych i autonomicznych zespołów inżynierskich i pokażemy, dlaczego jest to kluczowe podczas pracy z mikroserwisami.

ODPORNOŚĆ

Mikroserwisy są naturalnym mechanizmem izolowania awarii – jeśli wdrażamy je niezależnie, awaria aplikacji lub infrastruktury może wpłynąć tylko na część naszego systemu. Ponadto, możliwość wdrażania mniejszych fragmentów funkcjonalności powinna pomóc w stopniowej zmianie systemu, nie narażać na ryzykowny Wielki Wybuch związany z nową funkcjonalnością.

Ponownie rozważmy narzędzie inwestycyjne. Jeśli usługa obsługi giełdy jest niedostępna, złożenie zlecenia na giełdzie nie będzie możliwe. Użytkownik może jednak zażądać złożenia zlecenia, a usługa może je odebrać później, gdy będzie dostępna podrzędna funkcjonalność.

Mimo że dzielenie aplikacji na wiele usług może izolować awarię, to zwiększa także liczbę punktów awarii. Ponadto musimy wziąć pod uwagę, co się stanie, gdy wystąpi awaria, aby zapobiec kaskadzie awarii. W zakresie projektowania obejmuje to zarówno preferowanie asynchronicznej interakcji tam, gdzie jest to możliwe, jak i odpowiednie stosowanie bezpieczników i limitów czasowych, natomiast w zakresie działania – stosowanie sprawdzonych technik ciągłego dostarczania i solidną kontrolę aktywności systemu.

PRZEJRZYSTOŚĆ

Najważniejsze, byśmy wiedzieli, kiedy wystąpiła awaria, a aplikacja mikroserwisowa – w odróżnieniu od jednego systemu – zależy od interakcji i zachowania wielu usług, prawdopodobnie zbudowanych przez różne zespoły. W każdym momencie system powinien być przejrzysty i możliwy do monitorowania, aby zapewnić nadzór i diagnozowanie problemów.

Każda usługa w aplikacji będzie generować metryki biznesowe, operacyjne i infrastrukturalne, dzienniki aplikacji oraz ślady żądań. W związku z tym musimy się liczyć z tym, że będziemy mieć ogromną ilość danych.

AUTOMATYZACJA

Może się wydawać sprzeczne z intuicją, że złagodzenie problemów związanych z rosnącą aplikacją może odbyć się dzięki budowaniu wielu usług. To prawda, że mikroserwisy są bardziej złożoną architekturą niż pojedyncza aplikacja. Wykorzystując automatyzację i dążąc do spójności infrastruktury między usługami, można znacznie obniżyć koszt zarządzania tą dodatkową złożonością. Należy użyć automatyzacji, aby zapewnić poprawność wdrożeń i działanie systemu.

To nie przypadek, że popularność architektury mikroserwisowej jest analogią do coraz powszechniejszej adaptacji technik DevOps, w szczególności infrastructure-as-code, oraz rozwoju środowisk infrastrukturalnych, które są w pełni programowalne przez interfejsy API (takie jak AWS lub Azure). Te dwa trendy sprawiły, że mikroserwisy są osiągalne dla mniejszych zespołów.

UKIERUNKOWANIE

Wreszcie, bardzo ważne jest, aby swoje wysiłki na rzecz rozwoju ukierunkować w sposób właściwy. Powinniśmy dążyć do uporządkowania swoich usług, a więc i swoich zespołów, zgodnie z koncepcjami biznesowymi – doprowadzi to do większej spójności.

Aby zrozumieć, dlaczego jest to ważne, rozważmy alternatywę. Wiele tradycyjnych SOA wdraża warstwy techniczne aplikacji oddzielnie: interfejs użytkownika, logikę biznesową, integrację, dane. Na rysunku 1.4 porównano architekturę SOA i mikroserwisową.

Takie użycie horyzontalnej dekompozycji w SOA jest problematyczne, ponieważ spójna funkcjonalność zostaje rozproszona w wielu systemach. Nowe funkcjonalności mogą wymagać skoordynowanych wydań dla wielu usług i mogą być niedopuszczalnie połączone z innymi na tym samym abstrakcyjnym poziomie technicznym.

Z kolei architektura mikroserwisowa powinna być zorientowana na pionowy rozkład; każda usługa powinna być dostosowana do jednej funkcjonalności biznesowej, obejmując wszystkie odpowiednie warstwy techniczne.

UWAGA  W rzadkich przypadkach sensowne może być budowanie usługi implementującej zdolności techniczne, takiej jak integracja z usługą podmiotu zewnętrznego, jeśli wymaga tego wiele innych usług.

Powinniśmy także pamiętać o konsumentach swoich usług. Aby zapewnić stabilny system, musimy mieć pewność, że rozwój odbywa się spokojnie i zachowuje kompatybilność wsteczną – jawnie lub przez uruchamianie wielu wersji usługi – aby nie zmuszać innych zespołów do aktualizacji lub zerwania skomplikowanych interakcji między usługami.

Praca zgodnie z tymi pięcioma zasadami pomoże nam dobrze rozwinąć mikroserwisy, prowadząc do systemów, które są wysoce podatne na zmiany oraz skalowalne i stabilne.

Rysunek 1.4. SOA vs. architektura mikroserwisowa