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

Elastyczność techniczna mikroserwisu jest błogosławieństwem dla szybkości rozwoju i efektywnej skalowalności systemu. Ale ta sama elastyczność prowadzi również do wyzwań organizacyjnych, które zmieniają charakter tego, jak zespół inżynierów pracuje na dużą skalę. Szybko napotkamy dwa wyzwania: 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.

9

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!