Mikroserwisy w akcji. Отсутствует
techniczną różnorodność oraz izolację.
2.6.1. Techniczna różnorodność
Wyobraźmy sobie, że SimpleBank zbudował duży system mikroserwisowy składający się z 1000 usług. Właścicielem każdej usługi jest mały zespół inżynierów, a każdy z nich korzysta z preferowanych języków, ulubionych narzędzi, własnych skryptów do wdrażania, preferowanych zasad projektowania, preferowanych zewnętrznych bibliotek9 itd.
Poświęćmy chwilę, aby wyobrazić sobie jak dużo wysiłku wiąże się z utrzymaniem i wsparciem tak wielu różnych podejść. Chociaż mikroserwisy umożliwiają wybór różnych języków i frameworków dla każdej usługi, łatwo zauważyć, że bez wyboru rozsądnych standardów i ograniczeń system stanie się niezrozumiały i kruchy.
Łatwo zauważyć, że ta frustracja pojawia się także w mniejszej skali. Rozważmy dwie usługi: transakcje na rachunku i zlecenia – które mają dwa różne zespoły. Pierwsza usługa generuje dobrze ustrukturyzowany dziennik dla każdego żądania, zawierający pomocne informacje diagnostyczne, takie jak czasy, identyfikator żądania i identyfikator aktualnie wydanej wersji:
service=api
git_commit=d670460b4b4aece5915caf5c68d12f560a9fe3e4
request_id=55f10e07-ec6c
request_ip=1.2.3.4
request_path=/users
response_status=500
error_id=a323-da321
parameters={ id: 1 }
user_id=123
timing_total_ms=223
Druga usługa generuje anemiczne komunikaty w trudnym do przeanalizowania formacie:
Processed /users in 223ms with response 500
Widać, że nawet w tym prostym przykładzie formatu komunikatu z dziennika spójność i standaryzacja spowodują łatwiejsze zdiagnozowanie problemów i śledzenie żądań w wielu usługach. Konieczne jest uzgodnienie rozsądnych standardów na wszystkich poziomach systemu mikroserwisowego w celu zarządzania rozbieżnościami i złożonością.
2.6.2. Izolacja
W rozdziale 1 wspomnieliśmy o prawie Conwaya. W firmie, która wykorzystuje mikroserwisy, prawdziwe może być odwrócenie tego prawa – struktura firmy jest zdeterminowana przez architekturę jej produktu.
To sugeruje, że zespoły programistyczne będą w coraz większym stopniu odzwierciedlać mikroserwisy – będą wysoce wyspecjalizowane, aby dobrze wykonywać jedną rzecz. Każdy zespół będzie właścicielem i będzie odpowiedzialny za kilka blisko powiązanych mikroserwisów. Podsumowując, twórcy będą wiedzieć wszystko, co trzeba wiedzieć o systemie, ale indywidualnie będą mieć wąski zakres specjalizacji. Wraz ze wzrostem bazy klientów SimpleBanku i złożonością produktu specjalizacja ta będzie się pogłębiać.
Taka konfiguracja może stanowić ogromne wyzwanie. Mikroserwisy mają ograniczony zakres same w sobie i nie działają w izolacji. Dlatego te niezależne zespoły muszą ściśle współpracować, aby zbudować aplikację działającą bezproblemowo, nawet jeśli ich cele jako zespołu prawdopodobnie odnoszą się do ich węższego obszaru własności. Podobnie, wąskie spojrzenie może kusić zespół do optymalizacji pod kątem lokalnych problemów i preferencji, a nie potrzeb całej firmy. W najgorszym przypadku może to prowadzić do konfliktu między zespołami, czego z kolei skutkiem może być wolniejsze wdrażanie i mniej niezawodny produkt.
2.7. Co dalej?
W tym rozdziale ustaliliśmy, że mikroserwisy dobrze pasują do SimpleBanku, zaprojektowaliśmy nową funkcjonalność i rozważaliśmy, jak można uczynić tę funkcjonalność gotową do produkcji. Mamy nadzieję, że to studium przypadku pokazało, że podejście do opracowywania aplikacji oparte na mikroserwisach jest zarówno fascynujące, jak i wymagające!
W kolejnych rozdziałach przedstawimy techniki i narzędzia, które trzeba znać, aby uruchomić dobrą aplikację mikroserwisową. Chociaż mikroserwisy mogą prowadzić do elastycznego i wysoce produktywnego rozwoju, uruchamianie wielu rozproszonych usług jest o wiele bardziej wymagające niż uruchamianie pojedynczej aplikacji. Aby uniknąć niestabilności, musimy mieć możliwość projektowania i wdrażania usług gotowych do produkcji: przejrzystych, odpornych na błędy, niezawodnych i skalowalnych.
W części 2 skupimy się na projektowaniu. Skuteczne zaprojektowanie systemu rozproszonych, współzależnych usług wymaga starannego rozważenia zakresu systemu i sposobu interakcji tych usług. Możliwość określenia właściwych granic między odpowiedzialnością, a co za tym idzie – budowania wysoce spójnych i luźno powiązanych usług, jest jedną z najcenniejszych umiejętności dla każdego praktyka mikroserwisowego.
■ Mikroserwisy mają duże zastosowanie w systemach o wielu wymiarach złożoności – na przykład o szerokiej ofercie produktów w globalnych wdrożeniach i pod nadzorem regulatorów.
■ Podczas projektowania mikroserwisów kluczowe znaczenie ma zrozumienie domeny produktu.
■ Interakcje serwisowe mogą podlegać orkiestracji lub choreografii. To drugie zwiększa złożoność, ale może prowadzić do luźniej powiązanego systemu.
■ Bramy API to wspólny wzorzec do upraszczania i ukrywania złożoności architektury mikroserwisowej dla użytkowników frontendowych lub zewnętrznych.
■ Można powiedzieć, że usługa jest gotowa do produkcji, jeśli można zaufać, że sprosta wymaganiom produkcyjnym.
■ Można być pewnym usługi, jeśli można ją niezawodnie wdrożyć i monitorować.
■ Monitorowanie usług powinno obejmować agregację dzienników i kontrole działania na poziomie usługi.
■ Mikroserwisy mogą ulec awarii z powodu problemów ze sprzętem, komunikacją i zależnościami, a nie tylko z powodu błędów w kodzie.
■ Gromadzenie metryk biznesowych, dzienników oraz śledzenie międzyusługowe ma kluczowe znaczenie do zrozumienia obecnego i przeszłego operacyjnego zachowania aplikacji mikroserwisowej.
■ Techniczna różnorodność i izolacja będą coraz bardziej wymagające dla firm inżynierskich, ponieważ liczba mikroserwisów (i zespołów wspierających) się zwiększa.
■ Aby uniknąć różnorodności i izolacji, standardy i dobre praktyki muszą być podobne w wielu zespołach, niezależnie od podstaw technicznych.
Część 2
Projekt
W tej części przyjrzymy się projektowaniu aplikacji mikroserwisowych. Zaczniemy od ogólnego spojrzenia – architektury całej aplikacji, a następnie zejdziemy niżej, aby dowiedzieć się, jak określić zakres usług i połączyć je ze sobą. Nauczymy się projektować niezawodne usługi oraz tworzyć uniwersalny framework dla mikroserwisu, który można wielokrotnie wykorzystywać.
3. Architektura aplikacji mikroserwisowej
Niniejszy rozdział dotyczy:
■ ogólnego spojrzenia na aplikację mikroserwisową;
■ czterech poziomów architektury mikroserwisowej: platformy, usługi, granicy i klienta;
■ wzorców komunikacji między usługami;
■ projektowania bram API oraz fasad consumer-driven jako granic aplikacji.
W rozdziale 2 nową funkcjonalność dla SimpleBanku zaprojektowaliśmy jako zestaw mikroserwisów i odkryliśmy,
Niestety, nie jest to tylko problem mikroserwisów, chociaż jest on wzmocniony przez sztywne granice komponentów i jawną własność usług. Wcześniej w mojej karierze spotkałem się z pojedynczym projektem Ruby, który korzystał z sześciu różnych bibliotek klienta HTTP!