Tytuł oryginału: Production-Ready Microservices: Building ... · Znajomość skali wzrostu 91...

Tytuł oryginału: Production-Ready Microservices: Building Standardized Systems Across an Engineering Organization

Tłumaczenie: Radosław Meryk

ISBN: 978-83-283-3682-7

© 2017 Helion SA

Authorized Polish translation of the English edition of Production-Ready Microservices, ISBN 9781491965979 © 2017 Susan Fowler.

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

All rights reserved. No part of this book may be reproduced or transmitted in any formor by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani zaich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Wydawnictwo HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku!Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/mikrouMożesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

http://helion.pl/rt/mikrou

http://helion.pl/rf/mikrou

http://helion.pl/ro/mikrou

http://helion.pl

http://ebookpoint.pl/r/4CAKF

3

Spis treści

Przedmowa ........................................................................................ 9

1. Mikrousługi ...................................................................................... 19Od monolitów do mikrousług 20Architektura mikrousług 28Ekosystem mikrousług 31

Warstwa 1.: sprzęt 32Warstwa 2.: komunikacja 34Warstwa 3.: platforma aplikacji 37Warstwa 4.: mikrousługi 41

Wyzwania organizacyjne 42Odwrócone prawo Conwaya 43Techniczny rozrost 45Większe ryzyko awarii 46Rywalizacja o zasoby 47

2. Gotowość do produkcji ...................................................................... 49Wyzwania standaryzacji mikrousług 49Dostępność — cel standaryzacji 50Standardy gotowości do produkcji 52

Stabilność 53Niezawodność 54Skalowalność 55Odporność na awarie i przygotowanie na katastrofy 57

Poleć książkęKup książkę



4 Spis treści

Wydajność 59Monitorowanie 60Dokumentacja 62

Implementacja gotowości do produkcji 64

3. Stabilność i niezawodność ................................................................. 67Zasady budowania stabilnych i niezawodnych mikrousług 67Cykl rozwoju 69Potok wdrożeń 71

Faza przedprodukcyjna 72Faza kanarkowa 78Faza produkcyjna 79Egzekwowanie stabilnego i niezawodnego wdrażania 80

Zależności 82Routing i wykrywanie 84Deprecjacja i wycofywanie 85Ocena mikrousługi 86

Cykl rozwoju 86Potok wdrożeń 87Zależności 87Routing i wykrywanie 87Deprecjacja i wycofywanie 88

4. Skalowalność i wydajność ................................................................. 89Zasady skalowalności i wydajności mikrousług 89Znajomość skali wzrostu 91

Skala wzrostu jakościowego 91Skala wzrostu ilościowego 93

Efektywne wykorzystanie zasobów 93Świadomość zasobów 95

Wymagania dotyczące zasobów 95Wąskie gardła zasobów 96

Planowanie możliwości 97Skalowanie zależności 99




Spis treści 5

Zarządzanie ruchem 100Obsługa i przetwarzanie zadań 102

Ograniczenia związane z językami programowania 102Wydajna obsługa żądań i wydajne przetwarzanie zadań 103

Skalowalne składowanie danych 105Wybór bazy danych w ekosystemach mikrousług 105Wyzwania związane z bazami danych

w architekturze mikrousług 106Ocena mikrousługi 107

Znajomość skali wzrostu 107Efektywne wykorzystanie zasobów 108Świadomość zasobów 108Planowanie możliwości 108Skalowanie zależności 108Zarządzanie ruchem 109Obsługa i przetwarzanie zadań 109Skalowalne składowanie danych 109

5. Odporność na awarie i przygotowanie na katastrofy ........................ 111Zasady budowania mikrousług odpornych na awarie 111Eliminowanie pojedynczych punktów awarii 113Scenariusze katastrof i awarii 115

Typowe awarie w ekosystemie 116Awarie sprzętu 118Awarie na poziomie komunikacji i platformy aplikacji 120Awarie zależności 122Awarie wewnętrzne (mikrousług) 124

Testowanie odporności 126Testowanie kodu 127Testowanie obciążenia 129Testowanie chaosu 133

Wykrywanie awarii i środki zaradcze 135Incydenty i przestoje 136

Odpowiednia kategoryzacja 137Pięć faz reagowania na incydenty 139




6 Spis treści

Ocena mikrousługi 143Eliminowanie pojedynczych punktów awarii 143Scenariusze katastrof i awarii 143Testowanie odporności 143Wykrywanie awarii i środki zaradcze 144

6. Monitorowanie ............................................................................... 145Zasady monitorowania mikrousług 145Kluczowe parametry 147Rejestrowanie 150Pulpity nawigacyjne 152Ostrzeganie 154

Konfigurowanie skutecznego ostrzegania 154Obsługa alertów 156

Dyżury 157Ocena mikrousługi 158

Kluczowe parametry 158Rejestrowanie 159Pulpity nawigacyjne 159Ostrzeganie 159Dyżury 159

7. Dokumentowanie i rozumienie ....................................................... 161Zasady dokumentowania i rozumienia mikrousług 161Dokumentacja mikrousługi 163

Opis 165Diagram architektury 165Informacje kontaktowe i wzywanie dyżurnych 166Linki 167Przewodnik dla nowych programistów

i podręcznik programowania 167Przepływy żądań, punkty końcowe i zależności 168Instrukcje postępowania w nagłych wypadkach 169FAQ 170




Spis treści 7

Rozumienie mikrousługi 171Przeglądy architektury 172Audyty gotowości do produkcji 173Mapy gotowości do produkcji 174Automatyzacja gotowości do produkcji 175

Ocena mikrousługi 176Dokumentacja mikrousługi 176Zrozumienie mikrousługi 177

A Lista kontrolna gotowości do produkcji ........................................... 179

B Oceń swoją mikrousługę ................................................................. 183

Słowniczek ..................................................................................... 191

Skorowidz ...................................................................................... 201




8 Spis treści




19

ROZDZIAŁ 1.

Mikrousługi

W ciągu ostatnich kilku lat branża technologiczna doświadczyła gwałtownychzmian w stosowanej praktycznej architekturze systemów rozproszonych. Zmianyte odwiodły gigantów branży (takich jak Netflix, Twitter, Amazon, eBay i Uber)od budowania monolitycznych aplikacji. Zamiast nich zaczęto stosować ar-chitekturę mikrousług. O ile podstawowe pojęcia dotyczące mikrousług nie sąnowością, o tyle współczesne zastosowanie architektury mikrousług nią jest.Motywację do korzystania z takiej architektury częściowo tworzą wyzwaniaskalowalności, niewystarczająca efektywność systemów, wolne tempo rozwojuoraz trudności z przyjęciem nowych technologii powstające w przypadku próbyobjęcia i wdrożenia złożonych systemów oprogramowania w dużej monoli-tycznej aplikacji.

Przyjęcie architektury mikrousług — czy to od podstaw, czy przez podziałistniejącej monolitycznej aplikacji na niezależnie rozwijane i wdrażane mikro-usługi — rozwiązuje te problemy. Dzięki zastosowaniu architektury mikro-usług aplikacja może być łatwo skalowana zarówno w poziomie, jak i w pionie,znacznie zwiększa się wydajność i szybkość jej rozwoju, a stare technologiełatwo mogą być wymieniane na nowsze.

Jak zobaczymy w tym rozdziale, zastosowanie architektury mikrousług moż-na uznać za naturalny krok w skalowaniu aplikacji. Motywem do dzieleniamonolitycznych aplikacji na mikrousługi są obawy dotyczące skalowalnościi wydajności, ale mikrousługi wprowadzają swoje własne wyzwania. Udany,skalowalny ekosystem mikrousług wymaga obecności stabilnej i wyszukanejinfrastruktury. Ponadto, aby wesprzeć architekturę mikrousług, należy rady-kalnie zmodyfikować strukturę organizacyjną firmy. Struktury zespołów, któ-re są efektem takiej reorganizacji, mogą prowadzić do powstawania silosów




20 Rozdział 1. Mikrousługi

i nadmiernego rozrastania się. Największym wyzwaniem związanym z zasto-sowaniem architektury mikrousług jest jednak potrzeba standaryzacji archi-tektury samych usług oraz określenie dla każdej mikrousługi wymagań doty-czących zaufania i dostępności.

Od monolitów do mikrousługPrawie każde współcześnie napisane oprogramowanie można podzielić natrzy odrębne elementy: fronton (ang. frontend), czyli stronę klienta, zaplecze(ang. backend) oraz pewnego rodzaju magazyn danych (rysunek 1.1). Żądaniasą kierowane do aplikacji za pośrednictwem strony klienta, kod zaplecza re-alizuje główną pracę, a potrzebne dane, które muszą być składowane lub udo-stępniane (bez względu na to, czy tymczasowo w pamięci, czy trwale w baziedanych) są wysyłane lub pozyskiwane z miejsc, w których są przechowywanedane. Nazywamy to architekturą trójwarstwową.

Rysunek 1.1. Architektura trójwarstwowa

Istnieją trzy różne sposoby łączenia tych elementów w celu stworzenia aplika-cji. W większości aplikacji pierwsze dwie części mają wspólną bazę kodu (lubrepozytorium), w której jest przechowywany cały kod warstw strony klientai zaplecza. Części te są uruchamiane jako jeden plik wykonywalny z oddzielnąbazą danych. Innym sposobem jest rozdzielenie kodu frontonu od kodu za-plecza i zapisanie ich w postaci oddzielnych logicznie plików wykonywalnych,którym towarzyszy zewnętrzna bazy danych. W aplikacjach, które nie wyma-gają zewnętrznej bazy danych i przechowują wszystkie dane w pamięci, zwyklewszystkie trzy elementy są w jednym repozytorium. Niezależnie od sposobu,w jaki te elementy są podzielone lub połączone, sama aplikacja jest sumą tychtrzech odrębnych elementów.




Od monolitów do mikrousług 21

Aplikacje są zwykle zaprojektowane, zbudowane i uruchamiane w ten sposóbod początku cyklu ich życia, a architektura aplikacji przeważnie jest niezależnaod produktów oferowanych przez firmę bądź celu samej aplikacji. Wymienionetrzy elementy, które składają się na architekturę trójwarstwową, są obecnew każdej witrynie internetowej, każdej aplikacji telefonicznej, każdym zapleczui frontonie oraz dziwnych ogromnych aplikacjach korporacyjnych. Wszystkieone mają formę jednej z opisanych wcześniej permutacji.

Na początkowych etapach, gdy firma jest młoda, jej aplikacje są proste, a liczbaprogramistów biorących udział w tworzeniu bazy kodu jest mała i zazwyczaj dzieląoni obowiązki związane z tworzeniem i utrzymywaniem bazy kodu. W miaręrozwoju firmy zatrudnianych jest więcej programistów, a do aplikacji doda-wane są nowe funkcjonalności. Wtedy mogą wydarzyć się trzy istotne rzeczy.

Pierwsza to obserwowany wzrost obciążenia operacyjnego. Praca operacyjna,ogólnie rzecz biorąc, obejmuje zadania związaną z uruchamianiem i utrzyma-niem aplikacji. Wzrost ilości pracy operacyjnej zazwyczaj prowadzi do zatrudnie-nia inżynierów operacyjnych (administratorów systemów, inżynierów TechOpsi tzw. inżynierów DevOps), którzy przejmują większość zadań operacyjnych— związanych ze sprzętem, monitorowaniem oraz obsługą wezwań.

Druga to rezultat prostej arytmetyki: dodawanie nowych funkcji do aplikacjizwiększa zarówno liczbę wierszy kodu w aplikacji, jak i jej złożoność.

Trzecia natomiast to niezbędne skalowanie aplikacji w poziomie i (lub) w pionie.Wzrost ruchu wymusza znaczną skalowalność i wydajność aplikacji, co po-ciąga za sobą potrzebę użycia większej liczby serwerów — hostów aplikacji.Po dodaniu większej liczby serwerów na każdym z nich instalowana jest kopiaaplikacji. Instalowane są też mechanizmy równoważenia obciążenia tak, abyżądania były równomiernie rozkładane pomiędzy serwerami aplikacji (rysu-nek 1.2, przedstawiający fronton, który może zawierać własny mechanizmrównoważenia obciążenia, mechanizm równoważenia obciążenia zaplecza orazserwery zaplecza). Skalowanie w pionie staje się koniecznością, ponieważ apli-kacja rozpoczyna przetwarzanie większej liczby zadań związanych z jej zróż-nicowanym zestawem funkcji. W związku z tym aplikacja jest instalowana nawiększych, bardziej wydajnych serwerach, które mogą obsłużyć większe wy-magania procesora i pamięci (rysunek 1.3).





Rysunek 1.2. Skalowanie aplikacji w poziomie

Rysunek 1.3. Skalowanie aplikacji w pionie

W miarę rozwoju firmy i wzrostu liczby inżynierów, gdy nie jest ona już jed-no-, dwu- ani nawet trzycyfrowa, sprawy zaczynają się trochę bardziej kom-plikować. Z powodu wielu funkcji, łatek i poprawek dodawanych do bazy ko-du przez programistów aplikacja rozrasta się do wielu tysięcy wierszy kodu.Złożoność aplikacji stale rośnie. Trzeba napisać setki (jeśli nie tysiące) testów,





aby sprawdzić, czy wprowadzone zmiany (polegające na modyfikacji choćbytylko jednej lub dwóch linijek) nie naruszyły integralności istniejących tysięcywierszy kodu. Rozwijanie i wdrażanie aplikacji zmienia się w koszmar, testo-wanie staje się uciążliwe i jest przeszkodą dla wdrożenia nawet najbardziejistotnych poprawek, a dług techniczny szybko rośnie. Aplikacje, których cyklżycia pasuje do tego wzorca (mniej lub bardziej), są w środowisku programi-stów czule (i adekwatnie) nazywane monolitami.

Oczywiście nie wszystkie monolityczne aplikacje są złe i nie każda monoli-tyczna aplikacja sprawia wymienione problemy, ale monolity, które nie mająw którymś momencie swojego cyklu życia takich przypadłości, są (jak wynikaz mojego doświadczenia) dość rzadkie. Powodem, dla którego większość mo-nolitów jest podatna na te problemy, jest charakter takich aplikacji — naturamonolitów jest zaprzeczeniem skalowalności w najbardziej ogólnym znaczeniu.Skalowalność wymaga współbieżności i partycjonowania — dwóch rzeczy,które są trudne do osiągnięcia w przypadku monolitu.

Skalowanie aplikacjiSpróbujmy przeprowadzić krótką analizę.

Celem każdego oprogramowania jest przetwarzanie pewnego rodzaju zadań.Bez względu na to, jakie są te zadania, można przyjąć ogólne założenia co dosposobu, w jaki aplikacja ma sobie z nimi radzić: musi je efektywnie wykonywać.

Aby zadania były skutecznie przetwarzane, aplikacja musi obsługiwać pewienrodzaj współbieżności. Oznacza to, że nie może to być tylko jeden proces,który wykonuje całą pracę. W takim przypadku ten proces wybierałby jednozadanie, wykonywałby jego wszystkie niezbędne działania (lub nie!), a na-stępnie przechodziłby do zadania następnego. Taki sposób przetwarzania jestbardzo niewydajny! Aby aplikacja była wydajna, należy zastosować współbież-ność tak, aby każde zadanie mogło być podzielone na mniejsze fragmenty.

Aby wydajnie przetwarzać zadania, można także dzielić i zarządzać poprzezwprowadzenie partycjonowania. W tym przypadku każde zadanie jest nietylko podzielone na małe fragmenty, ale również przetwarzane równolegle.Jeśli mamy kilka zadań, możemy przetwarzać je wszystkie w tym samym czasie,wysyłając je zbioru procesów roboczych, które mogą przetwarzać je rów-nolegle. Aby przetwarzać więcej zadań, można z łatwością skalować rozwią-zanie poprzez dodawanie procesów roboczych do przetwarzania nowychzadań bez wywierania wpływu na wydajność systemu.





Współbieżność i partycjonowanie są trudne do obsłużenia, gdy mamy jedną du-żą aplikację, którą trzeba zainstalować na każdym serwerze i która musi przetwa-rzać wszelkiego rodzaju zadania. Jeśli aplikacja jest choćby odrobinę skompli-kowana, jedynym sposobem na jej skalowanie w obliczu rosnącej listy funkcjii zwiększonego ruchu jest skalowanie sprzętu, na którym jest zainstalowana.

Najlepszym sposobem skalowania aplikacji w celu zapewnienia jej odpo-wiedniej wydajności jest podzielenie jej na wiele małych, niezależnych apli-kacji, z których każda wykonuje jeden typ zadania. Potrzebny jest kolejnykrok w procesie? To proste: wystarczy stworzyć nową aplikację, która wy-konuje tylko ten krok! Trzeba poradzić sobie z większym obciążeniem?Żaden problem: dodajemy więcej procesów roboczych do każdej aplikacji!

Współbieżność i partycjonowanie są trudne do uzyskania w aplikacjach mo-nolitycznych, przez co architektura monolitycznej aplikacji nie może być takwydajna, jak tego oczekujemy.

Ten wzorzec pojawił się w takich firmach jak Amazon, Twitter, Netflix, eBayi Uber — firmach, które uruchamiają aplikacje nie na setkach, lecz na tysią-cach, a nawet setkach tysięcy serwerów, i których aplikacje wyewoluowały dopostaci monolitów i natknęły się na wyzwania skalowalności. Wyzwaniom, jakienapotkały te firmy, udało się sprostać dzięki porzuceniu architektury mono-litycznej aplikacji na rzecz mikrousług.

Podstawowe pojęcie mikrousługi jest proste: to mała aplikacja, która dobrzewykonuje tylko jedno działanie. Mikrousługa jest małym komponentem, któryłatwo wymienić, można go niezależnie rozwijać i niezależnie instalować. Mi-krousługa nie może jednak istnieć samodzielnie. Żadna mikrousługa nie jestwyspą. Jest to część większego systemu, uruchomionego i działającego razemz innymi mikrousługami dla osiągnięcia tego, co normalnie byłoby obsługi-wane przez jedną dużą, samodzielną aplikację.

Celem architektury mikrousług jest stworzenie zbioru małych aplikacji, z któ-rych każda jest odpowiedzialna za wykonywanie jednej funkcji (w przeciwień-stwie do tradycyjnego sposobu budowania jednej aplikacji, która robi wszystko),a także zapewnienie autonomii, niezależności i samodzielności każdej mikro-usługi. Fundamentalna różnica między monolityczną aplikacją i mikrousługąjest następująca: monolityczna aplikacja (rysunek 1.4) zawiera wszystkie cechyi funkcje w jednej aplikacji i jednej bazie kodu, wszystkie są instalowane w tymsamym czasie, każdy serwer jest hostem dla kompletnej kopii aplikacji, natomiast





Rysunek 1.4. Monolit

mikrousługa (rysunek 1.5) zawiera tylko jedną funkcję lub cechę i funkcjonujew ekosystemie mikrousług wraz z innymi mikrousługami, z których każda re-alizuje tylko jedną funkcję lub cechę funkcjonalną.

Rysunek 1.5. Mikrousługi





Istnieje wiele korzyści z zastosowania architektury mikrousług — w tym (alenie tylko) zmniejszenie długu technicznego, poprawa wydajności pracy pro-gramistów, lepsza wydajność testowania, zwiększona skalowalność i łatwośćwdrażania. Firmy, które stosują architekturę mikrousług, zwykle decydują sięna to po zbudowaniu jednej aplikacji i napotkaniu wyzwań skalowalnościi problemów organizacyjnych. Zaczynają od aplikacji monolitycznej, a na-stępnie dzielą monolit na mikrousługi.

Trudności z podziałem monolitu na mikrousługi całkowicie zależą od złożo-ności monolitycznej aplikacji. Podział monolitycznej aplikacji z wieloma funk-cjami na mikrousługi wymaga sporo wysiłku architektonicznego i starannejanalizy. Dodatkową komplikację stanowi potrzeba reorganizacji i restruktu-ryzacji zespołów. Decyzja o przejściu na mikrousługi zawsze musi stać się za-daniem dla całej firmy.

Rozbijanie monolitów na części wymaga kilku kroków. Pierwszym jest zidenty-fikowanie komponentów, które należy napisać w postaci niezależnych usług.To chyba najtrudniejszy krok w całym procesie, ponieważ o ile może istniećwiele prawidłowych sposobów podziału monolitu na komponenty, o tyle ist-nieje znacznie więcej sposobów nieprawidłowych. Prostą i praktyczną zasadąw identyfikacji komponentów jest wskazanie kluczowych funkcjonalności mo-nolitu, a następnie podzielenie ich na małe, niezależne komponenty. Mikro-usługi muszą być jak najprostsze. W przeciwnym razie firma będzie ryzykowałaprawdopodobieństwo zastąpienia jednego monolitu kilkoma mniejszymi, a w mia-rę rozwoju firmy wszystkie one będą narażone na takie same problemy, jakiegenerowała pierwotna aplikacja.

Po zidentyfikowaniu kluczowych funkcji i prawidłowym przydzieleniu ich doniezależnych mikrousług należy przebudować strukturę organizacyjną firmytak, aby każda mikrousługa była obsługiwana przez zespół inżynierów. Istniejekilka sposobów, aby to zrobić. Pierwszą metodą reorganizacji firmy przy przyję-ciu architektury mikrousług jest wyznaczenie dedykowanego zespołu do każdejmikrousługi. Wielkość zespołu w całości zależy od złożoności i obciążenia mi-krousługi. W zespole powinna się znaleźć wystarczająca liczba programistówi inżynierów niezawodności witryny, aby można było właściwie obsłużyć za-równo rozwój funkcjonalności, jak i bieżącą rotację usługi. Drugą metodą jestprzypisanie kilku usług jednemu zespołowi i powierzenie mu rozwijania usługrównolegle. Ten sposób sprawdza się najlepiej w przypadku, gdy zespoły sązorganizowane wokół konkretnych produktów lub dziedzin biznesowych i są





odpowiedzialne za rozwijanie usług związanych z tymi produktami lub dzie-dzinami. Jeśli firma zdecyduje się na drugą metodę reorganizacji, powinnazadbać, aby programiści nie mieli nadmiernej ilości pracy i nie musieli zma-gać się ze zmęczeniem zadaniem, awariami lub wypaleniem zawodowym.

Kolejnym ważnym elementem zastosowania mikrousług jest stworzenie eko-systemu mikrousług. Zazwyczaj firma obsługująca dużą aplikację monolitycznąposiada dedykowaną organizację infrastruktury odpowiedzialnej za projek-towanie, budowanie i utrzymanie środowiska, w którym działa aplikacja. Gdymonolit zostaje podzielony na mikrousługi, rośnie znaczenie obowiązków zwią-zanych z organizacją infrastruktury w celu dostarczenia stabilnej platformy dlarozwijania i utrzymania mikrousług. Zespoły infrastruktury muszą zapewnićzespołom mikrousług stałą infrastrukturę, która ukrywa większość złożonychinterakcji pomiędzy mikrousługami.

Po wykonaniu tych trzech kroków — podziale aplikacji na komponenty, re-strukturyzacji zespołów inżynieryjnych w celu przydzielenia osób odpowie-dzialnych za każdą mikrousługę oraz rozwinięciu organizacji infrastrukturyw firmie — można rozpocząć migrację. Niektóre zespoły decydują się naprzeniesienie właściwego kodu dla mikrousług bezpośrednio z monolitu dooddzielnej usługi i tworzą „cień” ruchu do monolitu, dopóki nie zyskają prze-konania, że mikrousługa może samodzielnie realizować pożądane funkcjonal-ności. Inne zespoły decydują się na tworzenie usługi od podstaw — zaczynająod czystego konta i generują równoległy ruch monolitu lub przekierowująusługę po pomyślnym przejściu odpowiednich testów. Najlepsze podejście domigracji zależy od funkcjonalności mikrousługi. Z moich doświadczeń wynika,że w większości przypadków oba podejścia sprawdzają się tak samo dobrze.Jednak prawdziwym kluczem do pomyślnej migracji jest dokładny, szczegó-łowy i starannie udokumentowany plan oraz świadomość, że pełna migracjadużego monolitu może zająć kilka długich lat.

Biorąc pod uwagę ogrom pracy związanej z podziałem monolitu na mikro-usługi, lepszą strategią może wydawać się rozpoczęcie od architektury mikro-usług, pominięcie wszystkich wyzwań skalowalności i uniknięcie w ten sposóbdramatu związanego z migracją do mikrousług. Takie podejście może okazaćsię dobre w przypadku niektórych firm. Chciałabym jednak wypowiedziećkilka słów przestrogi. Otóż małe przedsiębiorstwa często nie mają niezbędnejinfrastruktury do utrzymania mikrousług, nawet na bardzo małą skalę, a dobraarchitektura mikrousług wymaga stabilnej, często bardzo złożonej infrastruktury,ta zaś wymaga dużego, dedykowanego zespołu, którego koszty utrzymania są





akceptowalne tylko dla takich firm, które napotkały wyzwania skalowalnościuzasadniające przejście na architekturę mikrousług. Małe firmy po prostu niemają wystarczających możliwości operacyjnych do utrzymania ekosystemumikrousług. Ponadto gdy firma jest we wczesnym stadium rozwoju, to nie-zwykle trudne jest zidentyfikowanie kluczowych obszarów i komponentów,które można wbudować w mikrousługi — aplikacje nowych firm nie majązbyt wielu funkcji ani zbyt wielu oddzielnych obszarów funkcjonalności, któremogłyby zostać odpowiednio podzielone na mikrousługi.

Architektura mikrousługArchitektura mikrousług (rysunek 1.6) nie różni się zbytnio od architekturystandardowej aplikacji opisanej w pierwszej części tego rozdziału (rysunek 1.1).Każda mikrousługa składa się z trzech komponentów: frontonu (strony klienta),jakiegoś kodu zaplecza odpowiedzialnego za zasadnicze zadania oraz sposobuprzechowywania lub pobierania istotnych danych.

Rysunek 1.6. Elementy architektury mikrousług

Fronton — część mikrousługi działająca po stronie klienta — nie jest typowąaplikacją z interfejsem użytkownika, lecz raczej interfejsem programowaniaaplikacji (API) ze statycznymi punktami końcowymi (ang. endpoints). Dobrzezaprojektowane interfejsy API mikrousługi umożliwiają łatwe i skuteczne ko-munikowanie się z mikrousługami oraz wysyłanie żądania do odpowiednichpunktów końcowych API. Na przykład mikrousługa odpowiedzialna za daneklienta może mieć kilka punktów końcowych: get_customer_information,do którego inne usługi mogą wysyłać żądania w celu pobrania informacjio klientach, update_customer_information, do którego inne usługi wysyłajążądania w celu zaktualizowania informacji dla konkretnego klienta, oraz punktkońcowy delete_customer_information, którego usługi mogą używać do usu-wania informacji na temat klienta.




Architektura mikrousług 29

Te punkty końcowe są wydzielone w architekturze i teoretycznie samodzielne.W praktyce współistnieją obok siebie w ramach wspólnego kodu zaplecza, któryprzetwarza każde żądanie. W naszym przykładzie mikrousługi odpowiedzialnejza dane klienta żądanie wysłane do punktu końcowego get_customer_informationwygeneruje zadanie, które przetworzy przychodzące żądanie, określi specy-ficzne filtry lub opcje, które zostały zastosowane w żądaniu, pobierze infor-macje z bazy danych, sformatuje informacje, a następnie prześle je do klienta(mikrousługi), który tego zażądał.

Większość mikrousług przechowuje jakiś rodzaj danych — albo w pamięci(być może przy użyciu pamięci podręcznej), albo w zewnętrznej bazie danych.Jeśli dane są przechowywane w pamięci, nie jest konieczne połączenie siecio-we z zewnętrzną bazą danych, a mikrousługi mogą łatwo przekazać potrzebnedane do klienta. Jeśli dane są przechowywane w zewnętrznej bazie danych,mikrousługa jest zmuszona przekazać osobne żądanie do bazy danych, pocze-kać na odpowiedź, a następnie kontynuować przetwarzanie zadania.

Taka architektura jest konieczna, jeśli mikrousługi mają dobrze współpraco-wać ze sobą. Paradygmat architektury mikrousług wymaga, aby zbiór mikro-usług współpracował ze sobą w celu stworzenia czegoś, co w przeciwnym wy-padku istniałoby jako jedna duża aplikacja. Stąd jeśli zestaw mikrousług mawspółpracować ze sobą skutecznie i wydajnie, to są pewne elementy tej ar-chitektury, które muszą być znormalizowane w całej organizacji.

Punkty końcowe interfejsu API mikrousług powinny być ujednolicone w ca-łej organizacji. Nie znaczy to, że wszystkie mikrousługi powinny mieć takiesame konkretne punkty końcowe, ale że typ punktu końcowego powinien byćtaki sam. Dwoma popularnymi typami punktów końcowych API mikrousługsą REST i Apache Thrift. Spotykałam mikrousługi korzystające z obu typówpunktów końcowych (choć jest to rzadkie, komplikuje monitorowanie i, ogólnierzez biorąc, tego sposobu nie polecam). Wybór typu punktu końcowego jestodzwierciedleniem wewnętrznego działania samej mikrousługi. Typ dyktujetakże jej architekturę: trudno jest stworzyć asynchroniczną mikrousługę, któ-ra komunikuje się za pośrednictwem protokołu HTTP przez punkty końcoweREST, ponieważ taka usługa wymagałaby również dodania punktu końcowegobazującego na komunikatach.

Mikrousługi komunikują się ze sobą za pośrednictwem mechanizmu zdalnegowywoływania procedur (ang. remote procedure call — RPC). Są to wywołania zapośrednictwem sieci, zaprojektowane w taki sposób, aby wyglądały i działały





dokładnie tak, jak lokalne wywołania procedur. Stosowane protokoły zależą odwyborów architektonicznych i organizacyjnego wsparcia, a także od używa-nych punktów końcowych. Na przykład mikrousługa z punktami końcowymiREST prawdopodobnie będzie współdziałać z innymi mikrousługami za po-średnictwem protokołu HTTP, podczas gdy mikrousługa z punktami końco-wymi Thrift może komunikować się z innymi mikrousługami przez HTTP lubza pomocą bardziej spersonalizowanych, wewnętrznych rozwiązań.

Unikaj wersjonowania mikrousług i punktów końcowych

Mikrousługa nie jest biblioteką (nie jest ładowana do pamięciw czasie kompilacji lub w czasie wykonywania programu), leczniezależną aplikacją programową. Ze względu na szybkie temporozwoju mikrousług ich wersjonowanie może łatwo stać siękoszmarem firmy. Może ono implikować sytuacje, w którychprogramiści usług klienckich są związani używaniem konkret-nych (nieaktualnych, nieutrzymywanych) wersji mikrousługiwe własnym kodzie. Mikrousługi powinny być traktowane jakożywe, zmieniające się komponenty, a nie jak statyczne wyda-nia bądź biblioteki. Wersjonowanie punktów końcowych APIjest kolejnym antywzorcem, którego z tych samych powodównależy unikać.

Każdy typ punktu końcowego i każdy protokół używany do komunikacjiz innymi mikrousługami ma swoje zalety i wady. Decyzje architektonicznedotyczące mikrousług nie powinny być podejmowane przez indywidualnychprogramistów budujących mikrousługi, lecz powinny być częścią projektu ar-chitektury ekosystemu mikrousług jako całość (do tego tematu powrócimyw następnym podrozdziale).

Pisanie mikrousług daje programistom dużo swobody — poza wyborami organi-zacyjnymi dotyczącymi punktów końcowych API i protokołów komunikacyj-nych programiści mają swobodę tworzenia wewnętrznej implementacji mikro-usług. Mikrousługi mogą być zaimplementowane w dowolnym języku — w Go,Javie, Erlangu lub Haskellu. Istnieje tylko jeden warunek: programista musi wziąćpod uwagę punkty końcowe i protokoły komunikacyjne. Rozwijanie mikrousługnie różni się zbytnio od tworzenia autonomicznych aplikacji. Istnieją do tegopewne zastrzeżenia, o czym przekonamy się w ostatniej części niniejszego roz-działu („Wyzwania organizacyjne”). Swoboda programistów w zakresie wyborujęzyka wiąże się bowiem z ogromnymi kosztami ponoszonymi przez organizację.




Ekosystem mikrousług 31

Mikrousługa może być traktowana jako czarna skrzynka: wprowadzamy doniej pewne informacje poprzez wysyłanie żądań do punktów końcowych i otrzy-mujemy wyniki. Jeśli to, czego chcemy i potrzebujemy, otrzymamy od mikro-usługi w rozsądnym czasie i bez absurdalnych błędów, to znaczy, że spełniłaswoje zadanie i nie trzeba rozumieć niczego więcej poza znajomością punk-tów końcowych i oceną poprawności działania usługi.

Na tym kończy się opis specyfiki architektury mikrousług — nie dlatego, żetemat został wyczerpany, ale ponieważ każdy z kolejnych rozdziałów książkizostał poświęcony opisom sposobu doprowadzenia mikrousług do doskona-łego stanu czarnej skrzynki.

Ekosystem mikrousługMikrousługi nie istnieją w izolacji. Środowisko, w którym mikrousługi są bu-dowane i uruchamiane i w którym odbywają się interakcje między nimi, tomiejsce, gdzie one żyją. Złożoność wielkoskalowego środowiska mikrousługmożna porównać do zawiłości ekologicznych tropikalnego lasu, pustyni luboceanu. Uznanie tego środowiska za ekosystem — ekosystem mikrousług —pomaga w przyjęciu architektury mikrousług.

W dobrze zaprojektowanych, zrównoważonych ekosystemach mikrousługi sąwyabstrahowane z infrastruktury. Są oddzielone od sprzętu, sieci, kompilacjii potoku wdrożeń, a także mechanizmu wykrywania usług i równoważeniaobciążenia. To wszystko jest częścią infrastruktury ekosystemu mikrousług,a budowanie, standaryzacja i utrzymywanie tej infrastruktury w stanie stabil-nym, skalowalnym, odpornym na awarie i niezawodnym ma kluczowe zna-czenie dla sukcesu działania mikrousług.

Infrastruktura musi podtrzymywać ekosystem mikrousług. Celem wszystkichinżynierów infrastruktury i architektów powinno być wyeliminowanie koniecz-ności uwzględniania niskopoziomowych szczegółów działania infrastrukturypodczas rozwijania mikrousług. Powinni oni dążyć do zbudowania stabilnejinfrastruktury, którą można skalować — takiej, na której bazie programiścimogą łatwo zbudować i uruchomić mikrousługi. Rozwijanie mikrousługachw ramach stabilnego ekosystemu mikrousług powinno przypominać tworze-nie niewielkich, samodzielnych aplikacji. Wymaga to bardzo wyrafinowanej,najwyższej klasy infrastruktury.





Ekosystem mikrousług można podzielić na cztery warstwy (rysunek 1.7), choćgranice każdej z tych warstw nie zawsze są jasno zdefiniowane, niektóre elementyinfrastruktury dotykają bowiem wszystkich części stosu. Trzy niższe warstwyto warstwy infrastruktury: na dole stosu znajduje się warstwa sprzętu, a nad niąwarstwa komunikacji (która przenika do czwartej warstwy) oraz platformaaplikacji. Pojedyncze mikrousługi mieszczą się w czwartej warstwie (najwyższej).

Rysunek 1.7. Czterowarstwowy model ekosystemu mikrousług

Warstwa 1.: sprzętNa samym dole ekosystemu mikrousług znajduje się warstwa sprzętu. Są torzeczywiste maszyny: materialne, fizyczne komputery, na których działająwszystkie narzędzia i mikrousługi. Serwery te są zamontowane na półkachw centrach danych, chłodzone za pomocą drogich systemów HVAC i zasilaneenergią elektryczną. To serwery wielu różnych typów: niektóre są zoptymali-zowane pod kątem baz danych, natomiast inne — dla zadań intensywniewymagających procesora. Mogą być własnością firmy lub być wynajęte od do-stawców chmury, takich jak Amazon Web Services’ Elastic Compute Cloud(AWS EC2), Google Cloud Platform (GCP) lub Microsoft Azure.

Wybór konkretnego sprzętu jest zdeterminowany tym, kim są właściciele ser-werów. Jeśli nasza firma prowadzi własne centra danych, wybór sprzętu należydo nas. Możemy zoptymalizować wybór serwerów zgodnie ze specyficznymipotrzebami. Jeśli korzystamy z serwerów w chmurze (co jest najczęściej spo-tykanym scenariuszem), wybór jest ograniczony do tego, co oferuje dostawcausług w chmurze. Wybór pomiędzy tzw. gołym metalem a dostawcą w chmurze(lub dostawcami) nie jest łatwą decyzją. Trzeba wziąć pod uwagę koszty, do-stępność, niezawodność i wydatki operacyjne.





Zarządzanie serwerami jest częścią warstwy sprzętu. Każdy serwer musi mieć za-instalowany system operacyjny, który powinien być ustandaryzowany na wszyst-kich serwerach. Nie istnieje jedyna słuszna odpowiedź na pytanie o system opera-cyjny, którego należy użyć dla ekosystemu mikrousług. Odpowiedź na to pytaniezależy całkowicie od budowanej aplikacji, języków, w jakich będzie ona zapisana,oraz bibliotek i narzędzi wymaganych przez mikrousługi. Większość ekosyste-mów mikrousług działa na jakiejś wersji Linuxa. Zazwyczaj jest to CentOS, De-bian lub Ubuntu, choć firmy posługujące się platformą .NET oczywiście dokonająinnego wyboru. Nad warstwą sprzętu mogą być umieszczone warstwy złożonez dodatkowych abstrakcji: izolacja i abstrakcja zasobów (w postaci oferowanejprzez takie technologie jak Docker i Apache Mesos) również należą do tej war-stwy, podobnie jak bazy danych (dedykowane lub współdzielone).

Mechanizmy instalowania systemu operacyjnego i konfigurowania (ang. provi-sioning) sprzętu należą do pierwszej warstwy nad samymi serwerami. Każdyhost musi być przygotowany i skonfigurowany, a po zainstalowaniu systemuoperacyjnego należy wykorzystać narzędzie do zarządzania konfiguracją (naprzykład Ansible, Chef lub Puppet) w celu zainstalowania wszystkich aplikacjii wprowadzenia wszystkich koniecznych ustawień konfiguracyjnych.

Hosty wymagają właściwych mechanizmów monitorowania (na przykład zapomocą takich narzędzi jak Nagios) oraz rejestrowania. Dzięki tym mechani-zmom, jeśli cokolwiek się wydarzy (awaria dysku bądź sieci lub znaczny wzrostwykorzystania procesora), problemy będzie można łatwo zdiagnozować, zła-godzić i rozwiązać. Mechanizmy monitorowania na poziomie hosta szczegó-łowo omówiłam w rozdziale 6., „Monitorowanie”.

Warstwa 1.: sprzęt — podsumowanieWarstwa sprzętu ekosystemu mikrousług obejmuje:

serwery fizyczne(własność firmy lub wynajęte od dostawców usługw chmurze);

bazy danych (dedykowane lub współdzielone); system operacyjny; mechanizmy izolacji i abstrakcji zasobów; zarządzanie konfiguracją; monitorowanie na poziomie hosta; rejestrowanie na poziomie hosta.





Warstwa 2.: komunikacjaDruga warstwa ekosystemu mikrousług to warstwa komunikacji. Warstwa ko-munikacji przenika do wszystkich innych warstw ekosystemu (w tym platformyaplikacji i warstwy mikrousług), ponieważ to ona obsługuje całą komunikacjęmiędzy usługami. Granice pomiędzy warstwą komunikacji a wszystkimi in-nymi warstwami ekosystemu mikrousług są słabo zdefiniowane. O ile granicenie są zbyt wyraźne, o tyle elementy są wyraźne: druga warstwa ekosystemu mi-krousług zawsze zawiera punkty końcowe sieci, DNS, RPC i API, a także wy-krywanie usług, rejestr usług i równoważenie obciążenia.

Omawianie elementów sieci i DNS warstwy komunikacji wykracza poza zakrestej książki. Dlatego tutaj skoncentrujemy się na punktach końcowych RPC i API,wykrywaniu usługi, rejestrze usług i równoważeniu obciążenia.

RPC, punkty końcowe i przesyłanie komunikatów

Mikrousługi komunikują się ze sobą przez sieć za pomocą zdalnych wywołańprocedury (RPC) lub przesyłania komunikatów (ang. messaging) do punktówkońcowych API innych mikrousług (lub, w przypadku przesyłania komuni-katów, do brokera komunikatów, który kieruje komunikat do odpowiedniegoadresata). Podstawowa idea jest prosta: za pomocą określonego protokołumikrousługa wysyła dane w standardowym formacie przez sieć do innejusługi (być może do punktu końcowego API innej mikrousługi) albo do bro-kera komunikatów, który dba o przesłanie danych do punktu końcowego APIinnej mikrousługi.

Istnieje kilka paradygmatów komunikacji mikrousług. Pierwszy z nich,HTTP+REST/THRIFT, jest najczęściej spotykany. W przypadku paradygmatuHTTP+REST/THRIFT usługi komunikują się ze sobą przez sieć za pomocąprotokołu HTTP (ang. Hypertext Transfer Protocol). Wysyłają żądania dospecyficznych punktów końcowych REST (od ang. representational state trans-fer) — za pomocą różnych metod, np. GET, POST itp. — lub specyficznych punk-tów końcowych Apache Thrift (albo jednych i drugich) i odbierają z nich od-powiedzi. Dane są zwykle formatowane i wysyłane jako JSON (lub jako tzw.bufory protokołu — ang. protocol buffers) przez protokół HTTP.





HTTP + REST to najbardziej dogodna forma komunikacji mikrousług. Niema dla niej żadnych niespodzianek, jest łatwa w konfiguracji oraz najbardziejstabilna i niezawodna — głównie dlatego, że trudno ją nieprawidłowo zaim-plementować. Minusem przyjęcia tego paradygmatu jest to, że metoda ta jestz konieczności synchroniczna (blokująca).

Drugim paradygmatem komunikacyjnym jest przesyłanie komunikatów (ang.messaging). Metoda ta jest asynchroniczna (nieblokująca), ale nieco bardziejskomplikowana. Mechanizm przesyłania komunikatów działa w następującysposób: mikrousługa wysyła dane (komunikat) przez sieć (HTTP lub za po-mocą innego protokołu) do brokera komunikatów, który kieruje komunikacjędo innych mikrousług.

Mechanizm przesyłania komunikatów występuje w kilku odmianach. Dwienajbardziej popularne to publikuj-subskrybuj (pubsub) i żądanie-odpowiedź(ang. request-response). W modelu pubsub klienty dokonują subskrypcjitematu (ang. topic) i otrzymują wiadomość za każdym razem, gdy wydawcaopublikuje wiadomość w ramach tego tematu. Modele żądanie-odpowiedź sąprostsze: klient wysyła żądanie do usługi (lub brokera komunikatów) i otrzy-muje odpowiedź zawierającą żądane informacje. Istnieją technologie przesy-łania komunikatów, które są unikatową mieszanką obu modeli. Przykłademmoże być Apache Kafka. Dla mikrousług napisanych w Pythonie można wy-korzystać systemy przesyłania komunikatów (i przetwarzania zadań) Celeryi Redis (lub Celery z RabbitMQ): Celery przetwarza zadania i (lub) komuni-katy, wykorzystując w roli brokera systemy Redis lub RabbitMQ.

Mechanizm przesyłania komunikatów ma kilka istotnych wad, które trzebazłagodzić. Rozwiązania bazujące na przesyłaniu komunikatów, jeśli są od po-czątku projektowane z myślą o skalowalności, mogą być w takim samym stop-niu skalowalne (albo nawet bardziej) jak te, które bazują na HTTP + REST.Ze swojej natury mechanizmy przesyłania komunikatów nie są tak samo ła-twe do zmiany i aktualizacji, a ich scentralizowany charakter (choć może sięwydawać korzystny) może prowadzić do powstawania kolejek. Brokery stająsię natomiast punktami awarii dla całego ekosystemu. Jeśli nie zostaną zasto-sowane odpowiednie środki zaradcze, to asynchroniczny charakter mechani-zmu przesyłania komunikatów może prowadzić do wyścigów i nieskończonychpętli. Jeżeli mechanizm przesyłania komunikatów zostanie zaimplementowanywraz z zabezpieczeniami przeciwko tym problemom, to może osiągnąć takąsamą stabilność i wydajność jak rozwiązanie synchroniczne.





Wykrywanie usługi, rejestr usług i równoważenie obciążenia

W architekturze monolitycznej ruch musi być wysyłany tylko do jednej apli-kacji i odpowiednio dystrybuowany do serwerów będących hostami aplikacji.W architekturze mikrousług ruch musi być odpowiednio kierowany do dużejliczby różnych aplikacji, a następnie odpowiednio rozprowadzany do serwe-rów obsługujących każdą konkretną mikrousługę. Aby można było sprawniei skutecznie to zrealizować, architektura mikrousług wymaga zaimplemento-wania w warstwie komunikacji trzech technologii: wykrywania usługi, rejestruusług i równoważenia obciążenia.

Ogólnie rzecz biorąc, gdy mikrousługa A chce skierować żądanie do mikro-usługi B, to musi znać adres IP i port egzemplarza, na którym działa mikro-usługa B. Dokładniej mówiąc, warstwa komunikacji pomiędzy mikrousługamimusi znać adresy IP i porty mikrousług, tak aby mogła odpowiednio kierowaćżądania. Ta funkcjonalność jest realizowana przez mechanizm wykrywaniausługi (np. etcd, Consul, Hyperbahn lub ZooKeeper), który dba o to, aby żą-dania były kierowane dokładnie tam, gdzie powinny być wysyłane, oraz aby(co bardzo ważne) były kierowane tylko do egzemplarzy o dobrej kondycji.Mechanizm wykrywania usługi potrzebuje rejestru usług, który jest bazą da-nych portów i adresów IP wszystkich mikrousług w ekosystemie.

Dynamiczne skalowanie i przypisane porty

W architekturze mikrousług porty i adresy IP mogą się zmie-niać (i zmieniają się) cały czas — zwłaszcza w przypadku ska-lowania i instalowania mikrousług (w szczególności z wyko-rzystaniem warstwy abstrakcji sprzętu, na przykład ApacheMesos). Jednym ze sposobów podejścia do zadań wykrywaniai routingu jest przypisanie do każdej mikrousługi statycznychportów (zarówno w warstwie frontonu, jak i zaplecza).

Jeśli wszystkie mikrousługi nie występują wyłącznie w jednym egzemplarzu(co jest bardzo mało prawdopodobne), to w różnych częściach warstwy ko-munikacji ekosystemu mikrousług potrzebne są mechanizmy równoważeniaobciążenia. Na bardzo ogólnym poziomie równoważenie obciążenia działaw następujący sposób: jeśli mikrousługa jest zainstalowana na dziesięciuróżnych egzemplarzach, to oprogramowanie równoważenia obciążenia(i/lub sprzętu) dba o dystrybucję ruchu pomiędzy wszystkimi egzemplarzami.





Równoważenie obciążenia sieciowego jest potrzebne w każdym miejscu eko-systemu, w którym wysyłane jest żądanie do aplikacji. To oznacza, że każdyduży ekosystem mikrousług jest złożony z wielu warstw równoważenia obcią-żenia. Powszechnie używanymi do tego celu systemami równoważenia ob-ciążenia są Amazon Web Services Elastic Load Balancer, Netflix Eureka,HAProxy i Nginx.

Warstwa 2.: komunikacja — podsumowanieWarstwa komunikacji ekosystemu mikrousług obejmuje:

sieć;

DNS;

zdalne wywołania procedur (RPC);

punkty końcowe;

przesyłanie komunikatów;

wykrywanie usług;

rejestr usług;

równoważenie obciążenia.

Warstwa 3.: platforma aplikacjiPlatforma aplikacji jest trzecią warstwą ekosystemu mikrousług. Zawiera wszyst-kie wewnętrzne narzędzia i usługi, które są niezależne od mikrousług. Ta war-stwa jest wypełniona scentralizowanymi, działającymi w całym ekosystemienarzędziami i usługami, które muszą być budowane w taki sposób, aby zespołyrozwoju mikrousług nie były zmuszone do projektowania, budowania lub utrzy-mywania niczego poza własną mikrousługą.

Dobra platforma aplikacji jest wyposażona w samoobsługowe wewnętrzne na-rzędzia dla programistów, standardowy proces wytwarzania oprogramowania,scentralizowany i zautomatyzowany system kompilacji i publikowania, auto-matyczne testowanie, ustandaryzowane i scentralizowane rozwiązanie wdra-żania oraz scentralizowany mechanizm rejestrowania i monitorowania na po-ziomie mikrousługi. Wiele szczegółów dotyczących wymienionych elementówomówiłam w kolejnych rozdziałach. Tutaj opiszę zwięźle kilka z nich, aby za-prezentować wprowadzenie podstawowych pojęć.





Samoobsługowe wewnętrzne narzędzia programistyczne

Do kategorii samoobsługowych wewnętrznych narzędzi programistycznychmożna zakwalifikować sporo elementów. Przydział składników, które należądo tej kategorii, zależy nie tylko od potrzeb programistów, ale również od po-ziomu abstrakcji zarówno infrastruktury, jak i ekosystemu jako całości. Klu-czem do określenia narzędzi, które muszą zostać zbudowane, jest w pierwszejkolejności podzielenie stref odpowiedzialności, a następnie określenie zadań,które programiści powinni móc zrealizować w celu zaprojektowania, zbudo-wania i utrzymania swoich usług.

W firmie, która przyjęła architekturę mikrousług, obowiązki powinny byćuważnie oddelegowane do różnych zespołów inżynierskich. Łatwym sposo-bem osiągnięcia tego celu jest stworzenie podorganizacji inżynierskiej dlakażdej warstwy ekosystemu mikrousług, wraz z innymi zespołami, które two-rzą pomosty dla poszczególnych warstw. Każda z tych organizacji inżynier-skich, funkcjonując quasi-niezależnie, jest odpowiedzialna za wszystko, codzieje się w jej warstwie: zespoły TechOps są odpowiedzialne za warstwę 1.,zespoły infrastruktury są odpowiedzialne za warstwę 2., zespoły platformyaplikacji są odpowiedzialne za warstwę 3., natomiast zespoły mikrousług sąodpowiedzialne za warstwę 4. (to jest oczywiście bardzo uproszczony widok,ale pozwala zaprezentować ogólną koncepcję).

W ramach tego schematu organizacyjnego, za każdym razem, gdy inżynierpracujący w którejś z wyższych warstw musi stworzyć, skonfigurować lub wy-korzystać jakiś element z niższej warstwy, powinien mieć możliwość skorzy-stania z samoobsługowego narzędzia. Na przykład zespół pracujący nad me-chanizmem przesyłania komunikatów dla ekosystemu powinien zbudowaćsamoobsługowe narzędzie, które może być wykorzystane przez programistęzespołu mikrousługi do łatwego skonfigurowania mechanizmu komunikatówdla swojej usługi bez konieczności rozumienia wszystkich zawiłości systemuobsługi komunikatów.

Istnieje wiele powodów, dla których warto dysponować scentralizowanymi,samoobsługowymi narzędziami dla każdej warstwy. W zróżnicowanym eko-systemie mikrousług przeciętny inżynier w danym zespole nie posiada wiedzy(lub ma bardzo niewielką wiedzę) na temat sposobu działania usług i syste-mów w innych zespołach. Nie jest możliwe, aby każdy inżynier mógł stać sięekspertem w każdej usłudze i w każdym systemie w czasie, gdy pracuje nad wła-snymi. Poszczególni programiści będą wiedzieli bardzo niewiele poza swoimi





własnymi usługami, ale razem, wszyscy programiści pracujący w ramach ekosys-temu, będą kolektywnie wiedzieć wszystko. Zamiast próby edukowania każdegoprogramisty w zakresie zawiłości każdego narzędzia i każdej usługi w ekosys-temie, lepiej zbudować trwałe, łatwe w użyciu interfejsy użytkownika dla każ-dej części ekosystemu, a następnie przeszkolić innych ze sposobu korzystaniaz nich. Należy zamienić wszystkie narzędzia w czarne skrzynki, a następniedokładnie udokumentować, w jaki sposób działają i jak należy ich używać.

Drugim powodem dobrego budowania tych narzędzi jest fakt, że nie chcemydopuścić do tego, aby programista z innego zespołu mógł wprowadzić zna-czące zmiany do usługi lub systemu — zwłaszcza jeśli te zmiany mogłybyspowodować awarię. Jest to szczególnie prawdziwe i istotne dla usług i sys-temów należących do niższych warstw (warstwa 1., warstwa 2. i warstwa 3.).Zezwolenie nieekspertom na wprowadzanie zmian w obrębie tych warstw lubwymaganie (albo, co gorsza, żądanie) od nich, by stali się ekspertami w tychdziedzinach, to przepis na katastrofę. Jednym z obszarów, w których możedojść do nieprzewidzianych sytuacji, jest zarządzanie konfiguracją: zezwole-nie programistom zespołów mikrousług na wprowadzanie zmian w konfigu-racji systemu bez odpowiedniej wiedzy fachowej może — w przypadku, gdyzmiana wpływa na inny element niż ich własna usługa — doprowadzić doprzestojów produkcyjnych na dużą skalę.

Cykl rozwoju

Gdy programiści wprowadzają zmiany w istniejących mikrousługach lub tworząnowe mikrousługi, warto zadbać o bardziej skuteczny proces rozwoju poprzezuproszczenie i ujednolicenie procesu oraz zautomatyzowanie jak największejliczby jego elementów. Szczegóły standaryzacji stabilnego i niezawodnego pro-cesu rozwoju omówiłam w rozdziale 4., „Skalowalność i wydajność”. Jest jednakkilka elementów, które powinny się znaleźć w trzeciej warstwie ekosystemumikrousług, aby stabilny i niezawodny rozwój był możliwy.

Pierwszym wymaganiem jest scentralizowany system kontroli wersji, w którymjest przechowywany, śledzony, wersjonowany i przeszukiwany cały kod. Za-zwyczaj funkcjonalność ta jest realizowana za pomocą systemu podobnego doGitHub albo samodzielnego repozytorium git lub svn powiązanego z pewne-go rodzaju narzędziem współpracy takim jak Phabrictor. Wykorzystanie tychnarzędzi pozwala na łatwe utrzymywanie i przeglądnie kodu.





Drugie wymaganie to stabilne, wydajne środowisko programistyczne. Środowi-ska programistyczne w ekosystemach mikrousług są bardzo trudne do zaim-plementowania ze względu na skomplikowane zależności każdej z mikrousługod innych usług, ale są absolutnie niezbędne. Niektóre organizacje inżynierskiepreferują, aby wszystkie zadania programistyczne były realizowane lokalnie(na laptopie programisty), ale to może prowadzić do niepoprawnych instalacji,ponieważ programista nie uzyskuje dokładnego obrazu działania jego zmianw kodzie w środowisku produkcyjnym. Najbardziej stabilnym i niezawodnymsposobem zaprojektowania środowiska programistycznego jest stworzenie lu-strzanej kopii środowiska produkcyjnego (takiego, które nie jest środowiskiemprzedprodukcyjnym, kanarkowym ani produkcyjnym) uwzględniającej wszyst-kie skomplikowane łańcuchy zależności.

Testowanie, kompilowanie, pakietowanie i wydawanie

Etapy testowania, kompilowania, pakietowania i wydawania występujące po-między fazami rozwoju i wdrażania powinny być w maksymalnym stopniuustandaryzowane i scentralizowane. Po zakończeniu cyklu rozwoju i zaewi-dencjonowaniu wszystkich zmian w kodzie należy uruchomić wszystkie nie-zbędne testy oraz automatycznie zbudować i utworzyć pakiety dla wszystkichnowych wydań. Dokładnie do tego celu służą narzędzia ciągłej integracji, a go-towe rozwiązania (takie jak Jenkins) są bardzo zaawansowane i proste w kon-figuracji. Narzędzia te ułatwiają automatyzację całego procesu, pozostawiającbardzo mało miejsca na ludzki błąd.

Potok wdrożeń

Potok wdrożeń (ang. deployment pipeline) jest procesem, w ramach któregonowy kod trafia na serwery produkcyjne po przeprowadzeniu cyklu rozwojuoraz następujących po nim krokach testowania, kompilowania, pakietowaniai wydawania. Wdrożenia w ekosystemie mikrousług, w którym setki wdrożeńdziennie nie są niczym niezwykłym, mogą się bardzo szybko skomplikować.Zbudowanie oprzyrządowania wdrażania oraz standaryzacja praktyk wdraża-nia dla wszystkich zespołów programistycznych nierzadko są koniecznością.Zasady budowy stabilnych i niezawodnych (gotowych do produkcji) potokówwdrożeń omówiłam szczegółowo w rozdziale 3., „Stabilność i niezawodność”.





Rejestrowanie i monitorowanie

Każda mikrousługa powinna być wyposażona w mechanizm rejestrowania napoziomie mikrousługi wszystkich żądań kierowanych do mikrousługi (włącz-nie z wszystkimi ważnymi informacjami) oraz odpowiedzi udzielanych na teżądania. Ze względu na naturę programowania mikrousług — szybkie tempo— często nie jest możliwe odtworzenie błędów w kodzie, ponieważ nie mamożliwości odtworzenia stanu systemu w momencie wystąpienia awarii. Do-bry mechanizm rejestrowania na poziomie mikrousług dostarcza programi-stom informacji, których potrzebują do pełnego zrozumienia stanu usługiw określonym czasie w przeszłości lub teraźniejszości. Mechanizm monitoro-wania na poziomie mikrousługi wszystkich kluczowych charakterystyk mikro-usług jest niezbędny z podobnych powodów: dokładne, przeprowadzane w czasierzeczywistym monitorowanie pozwala programistom zapoznać się z kondycjąi stanem ich usługi. Mechanizmy rejestrowania i monitorowania na poziomiemikrousługi omówiłam bardziej szczegółowo w rozdziale 6., „Monitorowanie”.

Warstwa 3.: platforma aplikacji — podsumowanieWarstwa platformy aplikacji ekosystemu mikrousług obejmuje:

samoobsługowe wewnętrzne narzędzia programistyczne;

środowisko programistyczne;

narzędzia do testowania, kompilowania, pakietowaniai i wydawania;

potok wdrożeń;

rejestrowanie na poziomie mikrousługi;

monitorowanie na poziomie mikrousługi.

Warstwa 4.: mikrousługiNa samej górze ekosystemu mikrousług jest warstwa mikrousług. W tej war-stwie mieszczą się mikrousługi oraz wszystko, co jest z nimi związane. Są onecałkowicie wyabstrahowane od niższych warstw infrastruktury. Są oddzieloneod sprzętu, wdrażania, wykrywania usług, równoważenia obciążenia i komu-nikacji. Od warstwy mikrousług nie są oddzielone jedynie konfiguracje spe-cyficzne dla każdej usługi, umożliwiające posługiwanie się narzędziami.





Powszechną praktyką w inżynierii oprogramowania jest centralizacja wszyst-kich konfiguracji aplikacji, tak aby konfiguracje dla konkretnego narzędzia lubzestawu narzędzi (np. zarządzanie konfiguracją, izolacja zasobów lub narzędziawdrażania) były przechowywane razem z narzędziem. Na przykład niestan-dardowe konfiguracje wdrażania aplikacji często są przechowywane nie ra-zem z kodem aplikacji, lecz z kodem narzędzia wdrażania. Praktyka ta dobrzesię sprawdza dla architektury monolitycznej, a nawet dla małych ekosyste-mów mikrousług, ale w rozbudowanych ekosystemach mikrousług złożonychz setek mikrousług i dziesiątek wewnętrznych narzędzi (z których każde maoddzielną niestandardową konfigurację) praktyka ta prowadzi raczej do bała-ganu: programiści zespołów mikrousług muszą wprowadzać zmiany w bazachkodu narzędzi w niższych warstwach, a czasami zapominają, gdzie są prze-chowywane określone konfiguracje (lub czy w ogóle one istnieją). W celu zła-godzenia tego problemu wszystkie konfiguracje specyficzne dla mikrousług mogąbyć przechowywane w repozytorium mikrousług i powinny być dostępne dlanarzędzi i systemów z warstw znajdujących się niżej.

Warstwa 4.: mikrousługi — podsumowanieWarstwa mikrousług ekosystemu mikrousług obejmuje:

mikrousługi;

wszystkie konfiguracje specyficzne dla mikrousługi.

Wyzwania organizacyjneZastosowanie architektury mikrousług rozwiązuje najpilniejsze wyzwania cha-rakterystyczne dla architektury aplikacji monolitycznych. Mikrousług nie doty-czą wyzwania skalowalności, braku wydajności bądź trudności w przyjęciunowych technologii, są one bowiem zoptymalizowane pod kątem skalowalno-ści, wydajności oraz szybkości pracy programisty. W branży, w której nowetechnologie szybko trafiają na rynek, czysto organizacyjne koszty utrzymy-wania i usprawniania skomplikowanych aplikacji monolitycznych są po pro-stu niepotrzebne. Biorąc to pod uwagę, trudno sobie wyobrazić powody, dlaktórych ktoś miałby być niechętny podzieleniu monolitu na mikrousługi albomieć obiekcje co do budowania ekosystemu mikrousług od podstaw.




Wyzwania organizacyjne 43

Mikrousługi wydają się rozwiązaniem magicznym (i w pewnym sensie oczy-wistym), ale my wiemy o nich więcej. W książce The Mythical Man-MonthFrederick Brooks wyjaśnił, dlaczego nie istnieją „srebrne kule” w inżynieriioprogramowania. Koncepcję tę podsumował w następujący sposób: „Nie ist-nieje żaden proces rozwoju ani technologia czy technika zarządzania, któresame w sobie obiecują poprawę — w wydajności, niezawodności i prostocie— choćby o jeden rząd wielkości na dekadę”.

Kiedy ktoś zaprezentuje nam technologię, która obiecuje drastyczne ulepszenia,powinniśmy zwrócić uwagę na kompromisy, z jakimi wiąże się jej zastosowanie.Zastosowanie mikrousługi oferuje większą skalowalność i wydajność. Powin-niśmy jednak wiedzieć, że cechy te są związane z kosztami dla pewnej częścicałego systemu.

Istnieją cztery szczególnie ważne kompromisy wynikające z zastosowania ar-chitektury mikrousług. Pierwszym jest zmiana w strukturze organizacyjnej,która zmierza do izolacji i słabej komunikacji pomiędzy zespołami — jest tokonsekwencja odwróconego prawa Conwaya. Drugi to dramatyczny rozrosttechnologiczny. Jest on niezwykle kosztowny nie tylko dla całej organizacji,ale również wnosi znaczne koszty dla każdego inżyniera. Trzecim kompromi-sem jest zwiększone ryzyko awarii całego systemu. Czwarty kompromis to ry-walizacja o zasoby infrastruktury i zasoby inżynieryjne.

Odwrócone prawo ConwayaKoncepcja prawa Conwaya (nazwa pochodzi od nazwiska programisty MelvinaConwaya) sformułowanego w 1968 roku jest następująca: architektura systemujest określona przez strukturę komunikacyjną i organizacyjną firmy. Odwró-cone prawo Conwaya również jest prawdziwe i w szczególności odnosi się doekosystemu mikrousług: struktura organizacyjna firmy jest określona przezarchitekturę jej produktu. Ponad 40 lat po opublikowaniu prawa Conwayazarówno ono, jak i jego odwrotność nadal wydają się prawdziwe. Strukturaorganizacyjna firmy Microsoft — gdybyśmy spróbowali naszkicować ją w for-mie architektury systemu — przypomina architekturę jej produktów. To sa-mo dotyczy Google’a, Amazona i wszystkich innych dużych firm technolo-gicznych. Firmy, które przyjmują architekturę mikrousług, nie są wyjątkiemod tej reguły.





Architektura mikrousług składa się z dużej liczby małych, odizolowanychod siebie, niezależnych mikrousług. Odwrócone prawo Conwaya wymaga, abystruktura organizacyjna dowolnej firmy stosującej architekturę mikrousługskładała się z dużej liczby bardzo małych, odizolowanych od siebie i niezależ-nych zespołów. Struktury zespołu, które się z tego wywodzą, nieuchronnieprowadzą do powstawania silosów i rozrastania się. Problemy stają się corazwiększe w miarę wzrostu zaawansowania, współbieżności i wydajności eko-systemu mikrousług.

Odwrócone prawo Conwaya oznacza również, że programiści pod pewnymiwzględami będą przypominali mikrousługi: będą zdolni do wykonywaniajednej rzeczy i (miejmy nadzieję) będą ją wykonywać bardzo dobrze, ale będąodseparowani (pod względem odpowiedzialności, wiedzy dziedzinowej i do-świadczenia) od reszty ekosystemu. Łącznie wszyscy programiści wspólniedziałający w ramach ekosystemu mikrousług wiedzą wszystko, co trzeba wie-dzieć na temat tego ekosystemu, ale indywidualnie są bardzo wyspecjalizowani— znają tylko fragmenty ekosystemu, za które są odpowiedzialni.

Stwarza to nieunikniony problem organizacyjny: mimo że mikrousługi musząbyć tworzone w izolacji (co prowadzi do powstania odizolowanych, autono-micznych zespołów), to nie funkcjonują w izolacji, a jeśli produkt ma dobrzedziałać, muszą ze sobą współpracować. To wymaga, aby te odizolowane, nieza-leżnie działające zespoły współpracowały ze sobą ściśle i często. Jest to trudnedo osiągnięcia, zważywszy na fakt, że cele i projekty większości zespołów(skodyfikowane w ich celach i kluczowych rezultatach — ang. objectives andkey results, OKR) są specyficzne dla mikrousługi, nad którą zespół pracuje.

Istnieje również olbrzymia luka komunikacyjna pomiędzy zespołami mikro-usług a zespołami infrastruktury. Trzeba zadbać o jej wypełnienie. Na przy-kład zespoły platformy aplikacji powinny budować usługi i narzędzia plat-formy, które będą używane przez wszystkie zespoły mikrousług, ale zebraniewymagań i potrzeb od setek zespołów mikrousług przed stworzeniem jedne-go niewielkiego projektu może potrwać miesiące (a nawet lata). Nakłonieniezespołów programistów i zespołów infrastruktury do wspólnej pracy nie jestłatwym zadaniem.

Istnieje pokrewny problem wynikający z odwróconego prawa Conwaya, któryrzadko występuje w firmach stosujących architekturę monolityczną, a mia-nowicie trudność działania organizacji operacyjnych. W przypadku monolitumożna z łatwością obsadzić personel organizacji operacyjnej i ustanowić dyżury





pracy personelu z aplikacją. Jest to natomiast bardzo trudne do osiągnięciaw architekturze mikrousług, ponieważ wymaga przydzielenia do każdej mi-krousługi zarówno zespołu programistycznego, jak i zespołu operacyjnego.W konsekwencji zespoły programistów mikrousług muszą być odpowiedzial-ne za realizację obowiązków operacyjnych i zadań powiązanych z ich mikro-usługami. Nie ma oddzielnej organizacji operacyjnej, która mogłaby przyj-mować zgłoszenia, nie ma również dedykowanych inżynierów operacyjnychodpowiedzialnych za monitorowanie — zgłoszenia dotyczące swoich usługmuszą przyjmować sami programiści.

Techniczny rozrostDrugi minus, techniczny rozrost (ang. technical sprawl), jest powiązany z pierw-szym. O ile prawo Conwaya i jego odwrócona wersja przewidują rozrost orga-nizacyjny i tworzenie silosów mikrousług, o tyle drugi rodzaj rozrostu (związanyz technologiami, narzędziami i tym podobnymi elementami) także jest nie-unikniony w architekturze mikrousług. Techniczny rozrost może przejawiaćsię na wiele różnych sposobów. W tym rozdziale opiszę kilka najczęstszych.

Przyczyny, dla których stosowanie architektury mikrousług prowadzi do tech-nicznego rozrostu, są łatwe do zauważenia, jeśli przyjrzymy się dużemu eko-systemowi składającemu się z tysiąca mikrousług. Załóżmy, że każdą z tychmikrousług obsługuje zespół złożony z sześciu programistów, a każdy pro-gramista używa swojego własnego zestawu ulubionych narzędzi i bibliotek i pra-cuje w swoich własnych ulubionych językach programowania. Każdy z tychzespołów programistycznych stosuje własny sposób wdrażania, własne para-metry monitorowania i alertów, własne biblioteki zewnętrzne i zależności we-wnętrzne. Wykorzystuje spersonalizowane skrypty do uruchamiania na kom-puterach produkcyjnych. I tak dalej.

Jeśli tych zespołów jest kilka tysięcy, oznacza to, że w ramach jednego syste-mu stosowanych jest tysiące sposobów na wykonanie jednej rzeczy. Istniejetysiąc sposobów na wdrażanie, tysiąc bibliotek do utrzymania, tysiąc różnychsposobów ostrzegania, monitorowania, testowania i obsługiwania awarii.Jedynym sposobem na zmniejszenie rozrostu technicznego jest standaryzacjana wszystkich poziomach ekosystemu mikrousług.

Inny rodzaj technicznego rozrostu jest związany z wyborem języka. Mikro-usługi słyną z obietnicy większej swobody dla programistów — swobody wy-boru dowolnych języków i bibliotek. Ogólnie rzecz biorąc, jest to możliwe i może





być stosowane w praktyce, ale w miarę rozwoju ekosystemu mikrousług czę-sto staje się niepraktyczne, kosztowne i niebezpieczne. Aby zobaczyć, dlaczegomoże to stać się problemem, rozważmy następujący scenariusz. Załóżmy, żemamy ekosystem mikrousług zawierający dwieście usług. Wyobraźmy sobie,że niektóre z tych mikrousług są napisane w Pythonie, inne w JavaScripcie,jeszcze inne w Haskellu, kilka innych w Go, a jeszcze kilka innych w Ruby,Javie i C++. Dla każdego wewnętrznego narzędzia, dla każdego systemu i dlakażdej usługi w ramach każdej warstwy ekosystemu trzeba napisać bibliotekidla każdego z tych języków.

Zastanówmy się przez chwilę, ile pracy związanej z utrzymaniem i progra-mowaniem trzeba wykonać dla każdego z tych języków, aby zapewnić wyma-gany poziom wsparcia. Jest jej ogromnie dużo. Tylko nieliczne organizacjeinżynierskie mogą sobie pozwolić na przydzielenie zasobów umożliwiającychsprostanie tym zadaniom. Bardziej realistyczny od obsługi dużej liczby języ-ków jest wybór ich niewielkiej liczby i zadbanie o to, aby wszystkie bibliotekii narzędzia były dostępne i zgodne z tymi językami.

Ostatnim rodzajem technicznego rozrostu, jaki omówię w tym rozdziale, jestdług techniczny, który zwykle odnosi się do pracy, jaką trzeba wykonać zewzględu na to, że pewną pracę wykonano tak, aby zrobić ją szybko, ale niew najlepszy i najbardziej optymalny sposób. Zważywszy na to, że zespołyprogramowania mikrousług publikują nowe funkcjonalności w szybkim tem-pie, dług techniczny często narasta niepostrzeżenie w tle. Gdy pojawiają sięprzestoje z powodu awarii, wtedy prace wykonywane w rezultacie przepro-wadzanych analiz incydentu rzadko są rozwiązaniem optymalnym — zespołyprogramowania mikrousług zazwyczaj stosują poprawki, które rozwiązują pro-blem szybko i są wystarczająco dobre w danej chwili. Wszelkie lepsze rozwią-zania są odkładane na później.

Większe ryzyko awariiMikrousługi są dużymi, złożonymi, rozproszonymi systemami składającymi sięz wielu małych, niezależnych fragmentów, które stale się zmieniają. Realia pra-cy ze złożonymi systemami tego rodzaju są takie, że pojedyncze komponentyulegają awariom. Awarie komponentów są częste i przebiegają w sposób, któ-rego nikt nie potrafi przewidzieć. Tu objawia się trzecia wada architekturymikrousług: większe ryzyko awarii systemów.





Istnieją sposoby przygotowania się do awarii, łagodzenia błędów, gdy one wy-stąpią, i testowania limitów i granic zarówno poszczególnych komponentów,jak i ekosystemu jako całości. Opiszę je w rozdziale 5., „Odporność na awariei przygotowanie na katastrofy”. Warto jednak zapamiętać, że bez względu nato, jak wiele testów odporności uruchomimy, niezależnie od liczby scenariu-szy błędów i katastrof, które weźmiemy pod uwagę, nie możemy zaprzeczyćfaktowi, że system kiedyś ulegnie awarii. Jedyne, co można zrobić, to jak naj-lepiej przygotować się na tę ewentualność.

Rywalizacja o zasobyPodobnie jak w innych ekosystemach w świecie przyrody, w ekosystemie mi-krousług występuje ostra konkurencja o zasoby. Każda organizacja inży-nieryjna ma ograniczone zasoby: skończoną liczbę zasobów inżynierskich(zespoły, programiści) oraz skończone zasoby sprzętu i infrastruktury (fi-zycznych komputerów, sprzętu w chmurze, przestrzeni w bazach danych itd.),a każdy z zasobów kosztuje firmę mnóstwo pieniędzy.

Gdy ekosystem mikrousług zawiera dużą liczbę mikrousług i wiele rozbudo-wanych i skomplikowanych platform aplikacji, rywalizacja pomiędzy zespołamio zasoby sprzętu i infrastruktury staje się nieunikniona: każda usługa i każdenarzędzie będą prezentowane jako równie ważne. Ich skalowanie będzie przed-stawiane jako to, które ma najwyższy priorytet.

Na podobnej zasadzie, gdy zespoły platformy aplikacji proszą o specyfikacjei potrzeby od zespołów mikrousług, aby mogły właściwie zaprojektować swojesystemy i narzędzia, każdy zespół programowania mikrousług twierdzi, że jegopotrzeby są najważniejsze, i będzie rozczarowany (i potencjalnie bardzo sfru-strowany), jeśli jego potrzeby nie zostaną uwzględnione. Tego rodzaju rywali-zacja o zasoby inżynierskie może prowadzić do niechęci między zespołami.

Ostatni typ rywalizacji o zasoby jest najbardziej oczywisty: rywalizacja międzymenedżerami, zespołami oraz różnymi działami inżynieryjnymi (organizacjami)o inżynierów. Pomimo wzrostu liczby absolwentów kierunków informatycznychoraz dostępności licznych kursów programowania (tzw. bootcampów) znale-zienie naprawdę dobrych programistów jest bardzo trudne. Dobrzy progra-miści należą do najbardziej niezastąpionych i ograniczonych zasobów. Gdyistnieją setki lub tysiące zespołów, w których mogą pracować nieliczni nowiinżynierowie, wtedy każdy zespół będzie się upierał, że to on potrzebuje do-datkowych inżynierów bardziej niż inne zespoły.





Nie ma sposobu, aby rywalizacji o zasoby uniknąć, choć istnieją sposoby, abynieco ją złagodzić. Najbardziej skuteczne wydaje się organizowanie lub kate-goryzowanie zespołów pod względem ich znaczenia i ważności dla ogólnejdziałalności oraz udzielenie zespołom dostępu do zasobów na podstawie ichpriorytetu lub znaczenia. Istnieją wady takiego podejścia, ponieważ jego sto-sowanie może powodować niewystarczające dbanie o obsadę zespołów pra-cujących nad narzędziami programistycznymi oraz porzucanie projektów,których znaczenie polega na kształtowaniu przyszłości (np. przyjęcie nowychtechnologii w infrastrukturze).




201

Skorowidz

Aalert skłaniający do działania, 191alokacja zasobów, 191API, 193architektura

mikrousług, 28trójwarstwowa, 20, 191

audyty gotowości do produkcji, 173automatyzacja

gotowości do produkcji, 175, 191testowania kodu, 128testowania obciążenia, 131

awarie, 46, 57, 111typowe, 116, 118warstwy

komunikacji, 120, 122mikrousług, 125platformy aplikacji, 120, 122sprzętu, 118, 119

wewnętrzne, 124zależności, 122, 124zewnętrzne, 191

Bbaza danych, 105, 106błędy wewnętrzne, 191broker komunikatów, 114

budowanie stabilnych mikrousług, 67buforowanie defensywne, 191

Ccel standaryzacji, 50ciągła integracja, 191cykl rozwoju, 39, 69, 86, 183, 192czas

całkowity, 51działania, 51przestoju, 51realizacji zamówienia, 98

częściowa faza przedprodukcyjna, 75, 192zagrożenia, 76

Ddebugowanie, 152dedykowany sprzęt, 192deprecjacja, 85, 88, 185, 192diagram architektury, 165, 192dokumentacja, 62, 161

mikrousługi, 163, 170, 176, 189dostawcy usług w chmurze, 192dynamiczne skalowanie, 36dystrybucja ruchu kanarkowego, 78dyżury, 157, 159, 189dzielenie monolitu, 192




202 Skorowidz

Eefektywne wykorzystanie zasobów, 93,

108, 185ekosystem mikrousług, 31, 192eliminowanie pojedynczych punktów

awarii, 113, 143, 187

FFAQ, 170faza

kanarkowa, 78, 192produkcyjna, 79przedprodukcyjna, 72, 192

częściowa, 75pełna, 73

fazy reagowania na incydenty, 139dalsze działania, 142koordynacja, 140łagodzenie, 141ocena, 140rozwiązanie, 141

Ggoły metal, 193gotowość do produkcji, 50, 52, 64

audyty, 173automatyzacja, 175lista kontrolna, 179mapy, 174

Iidentyfikowanie dodatkowych wymagań

zasobów, 95implementacja gotowości do produkcji,

64incydenty, 136, 139informacje kontaktowe, 166infrastruktura, 193instrukcje postępowania, 169

interfejs programowania aplikacji, 193inżynier niezawodności witryny, 193inżynierowie operacyjni, 193

Jjęzyki programowania, 102

Kkandydat do produkcji, 193kategoryzacja

incydentów i przestojów, 138mikrousług, 138

kluczowe parametry, 147, 149, 158, 188,193

komentarze, 164kompilowanie, 40komunikacja

publikuj – subskrybuj, 193żądanie – odpowiedź, 193

konfigurowanie skutecznegoostrzegania, 154

kontrola gotowości do produkcji, 194koszt

niespełnionych kontraktów SLA, 123niestabilnego procesu rozwoju, 69

książka procedur awaryjnych, 194

Llinki, 167lista kontrolna gotowości do produkcji,

194logi, 152

Mmapy gotowości do produkcji, 174, 194mikrousługi, 19, 25, 194

dokumentacja, 163, 189gotowe do produkcji, 68monitorowanie, 188




Skorowidz 203

niezawodne, 67, 179, 183ocena, 86, 107, 143, 158, 176odporne na awarie, 112, 180, 187przygotowane na katastrofy, 113,

180, 187skalowalne, 180, 185stabilne, 67, 179, 183udokumentowane, 181właściwie monitorowane, 181wydajne, 180, 185zasady monitorowania, 145zasady skalowalności, 89zasady wydajności, 89zrozumiałe, 181

model ekosystemu mikrousług, 32platforma aplikacji, 37warstwa komunikacji, 34warstwa mikrousług, 41warstwa sprzętu, 32

monitorowanie, 41, 60, 188, 194mikrousług, 145parametrów, 147

monolit, 25, 194

Nnarzędzia programistyczne, 38niezawodność, 54, 67notacja dziewiątek, 51

Oobliczanie dostępności, 51obsługa

alertów, 156zadań, 102, 109, 186żądań, 103

ocenagotowości do produkcji, 194mikrousługi, 86, 107, 143, 158, 176

odporność na awarie, 57, 111, 187odwrócone prawo Conwaya, 43, 194

ograniczenia języków programowania, 102określanie progów, 155opis, 165ostrzeganie, 154, 159, 189, 195

Ppakietowanie, 40parametry

hosta i infrastruktury, 195mikrousługi, 195

partycjonowanie, 195parzystość hostów, 195pełna faza przedprodukcyjna, 73, 195

zagrożenia, 74planowanie

możliwości, 97, 108, 185zdolności produkcyjnych, 195

platforma aplikacji, 37pliki README, 164podręcznik programowania, 167pojedyncze punkty awarii, 112–114, 195połączenie z bazą danych, 107porty, 36

dla wersji kanarkowych, 79dla wersji produkcyjnych, 79

potok wdrożeń, 40, 71, 87, 184, 195prawo Conwaya, 43, 195produkcja, 49, 196próg alarmowy, 196przeglądy architektury, 172, 196przepływy żądań, 168, 196przestoje, 136, 196przesyłanie komunikatów, 34przetwarzanie zadań, 102, 103, 109, 186przewodnik, 167przygotowania na katastrofy, 57, 111, 187pulpity nawigacyjne, 152, 159, 189, 196punkty

awarii, 115końcowe, 28, 34, 168, 196




204 Skorowidz

Rrejestrowanie, 41, 150, 159, 188, 196

bez wersjonowania, 150usług, 36, 196

repozytorium, 196routing, 84, 87, 184rozumienie, 161

mikrousługi, 171równość hostów, 72równoważenie obciążenia, 36, 196RPC, 34, 199rywalizacja o zasoby, 47ryzyko awarii, 46

Ssamoobsługowe narzędzia wewnętrzne,

38, 197scenariusze katastrof i awarii, 115, 143, 187skala wzrostu, 91, 107, 185

ilościowego, 93, 197jakościowego, 91, 99, 197

skalowalne składowanie danych, 105,109, 186

skalowanie, 55, 89aplikacji w pionie, 22, 96, 197aplikacji w poziomie, 22, 197zależności, 99, 108, 186

SRE, site reliability engineer, 9, 193stabilność, 53, 67standardy gotowości do produkcji, 52standaryzacja mikrousług, 49szybkość programowania, 197

Śśrodki zaradcze, 135, 144, 188środowisko

kanarkowe, 71programistyczne, 197

świadomość zasobów, 108, 185

Ttechniczny rozrost, 45testowanie, 40, 70

chaosu, 133kodu, 127, 197obciążenia, 129–132odporności, 126, 143, 188

testycałościowe, 198integracyjne, 127, 198jednostkowe, 127, 198lint, 127, 198od końca do końca, 128

Wwarstwa

komunikacji, 34, 198mikrousług, 41, 198platformy aplikacji, 198sprzętu, 32, 198

wąskie gardła zasobów, 95, 96, 198wdrażanie, 198

niezawodne, 80stabilne, 80

wdrożenia usługifaza produkcyjna, 72faza przedprodukcyjna, 72

wersjonowaniemikrousług, 30punktów końcowych, 30

współbieżność, 199współdzielenie zasobów sprzętowych,

94, 199wybór bazy danych, 105wycofywanie, 85, 88, 185, 199wydajność, 59, 89wydawanie, 40wykrywanie, 84, 87, 184

awarii, 135, 144, 188przestojów, 153usług, 36, 199




Skorowidz 205

wymagania dotyczącedokumentacji, 63monitorowania, 61niezawodności, 55odporności na awarie, 58skalowalności, 56stabilności, 54wydajności, 59zasobów, 95, 199

wzywanie dyżurnych, 166

Zzależności, 82, 87, 168, 184, 199zarządzanie ruchem, 100, 109, 186

zasadydokumentowania, 161monitorowania mikrousług, 145rozumienia mikrousług, 161, 177,

190zasoby, 47, 93, 95, 199

sprzętowe, 199zdalne wywołanie procedury, 199zespół dyżurny, 199znajomość skali wzrostu, 107




Notatki




http://program-partnerski.helion.pl

Date post:	27-Feb-2019
Category:	Documents
Upload:	dothu
View:	226 times
Download:	0 times

Tytuł oryginału: Production-Ready Microservices: Building ... · Znajomość skali wzrostu 91...

Documents