Mikroserwisy. Wzorce z przykładami w języku Java

• Druk: 2020
• Seria / cykl: JAVA
• Autor: Chris Richardson
• Tłumacz: Magdalena Rogulska, Mariusz Rogulski
• Wydawca: Wydawnictwo Naukowe PWN

Skuteczne tworzenie aplikacji opartych na mikroserwisach wymaga opanowania nowej wiedzy i praktyk architektonicznych. W tej wyjątkowej książce pionier architektury mikroserwisowej i posiadacz tytułu Java Champion – Chris Richardson – zgromadził, skatalogował i wyjaśnił 44 wzorce rozwiązujące problemy, takie jak dekompozycja usług, zarządzanie transakcjami, zapytania i komunikacja między usługami.
Mikroserwisy. Wzorce z przykładami w języku Java uczy, jak tworzyć i wdrażać wysokiej jakości aplikacje oparte na mikroserwisach. Ten nieoceniony zestaw wzorców projektowych opartych na dziesięcioleciach doświadczeń z systemami rozproszonymi, dodaje także nowe wzorce tworzenia usług i łączenia ich w systemy, które są skalowalne i działają niezawodnie w rzeczywistych warunkach. Ten praktyczny przewodnik to coś więcej niż tylko katalog wzorców. To zbiór porad pomagających w projektowaniu, implementacji, testowaniu i wdrażaniu aplikacji zbudowanej z mikroserwisów.
W książce:
• Jak (i dlaczego!) korzystać z architektury mikroserwisowej
• Strategie dekompozycji usług
• Zarządzanie transakcjami i wzorce zapytań
• Skuteczne strategie testowania
• Wzorce wdrażania, w tym kontenery i środowiska bezserwerowe
Książka jest przeznaczona dla profesjonalnych programistów znających typową architekturę aplikacji korporacyjnych. Zawiera przykłady w języku Java.

• Kategorie:
  1. Ebooki i Audiobooki »
  2. Ebooki »
  3. Ebooki popularnonaukowe i specjalistyczne »
  4. Informatyka
• Język wydania: polski
• ISBN: 978-83-01-21223-0
• ISBN druku: 978-83-01-21192-9
• Liczba stron: 504

przedmowa xxiii
podziękowania xxvi
o książce xxviii
o autorze xxxi
o ilustracji na okładce xxxii
1. Ucieczka z monolitycznego piekła 1
	1.1. Powolny marsz w kierunku monolitycznego piekła 2
		1.1.1. Architektura aplikacji FTGO 3
		1.1.2. Zalety architektury monolitycznej 4
		1.1.3. Życie w monolitycznym piekle 4Kompleksowość przeraża deweloperów 4  
			Rozwój jest powolny 5  
			Ścieżka od zatwierdzenia do wdrożenia jest długa i mozolna 5  
			Skalowanie jest trudne 6  
			Dostarczanie niezawodnego monolitu jest wyzwaniem 6  
			Blokada w coraz bardziej przestarzałym stosie technologicznym 7
	1.2. Dlaczego ta książka jest dla ciebie odpowiednia 7
	1.3. Czego się nauczysz z tej książki 8
	1.4. Architektura mikroserwisowa na ratunek 8
		1.4.1. Sześcian skal i mikroserwisy 9
			Skalowanie w osi X równoważy obciążenia dotyczące żądań między wiele instancji 9  
			Skalowanie w osi Z trasuje żądania na podstawie atrybutu żądania 10  
			Skalowanie w osi Y funkcjonalnie rozkłada aplikację na usługi 11
		1.4.2. Mikroserwisy jako forma modułowości 11
		1.4.3. Każda usługa ma własną bazę danych 12	
		1.4.4. Architektura mikroserwisowa FTGO 12
		1.4.5. Porównanie architektury mikroserwisowej i SOA 13
	1.5. Zalety i wady architektury mikroserwisowej 14
	1.5.1. Zalety architektury mikroserwisowej 14
			Umożliwianie ciągłego dostarczania i wdrażania dużych, złożonych aplikacji 15  
			Każda usługa jest mała i łatwa w utrzymaniu 15  
			Usługi są niezależnie skalowalne 16  
			Lepsza izolacja błędów 16  
			Łatwe eksperymentowanie i wdrażanie nowych technologii 17
		1.5.2. Wady architektury mikroserwisowej 17
			Znalezienie odpowiednich usług jest trudne 17  
			Systemy rozproszone są złożone 17  
			Wdrażanie funkcjonalności obejmujących wiele usług wymaga starannej koordynacji 18  
			Decyzja o przyjęciu jest trudna 18
	1.6. Język wzorców architektury mikroserwisowej 19
		1.6.1. Architektura mikroserwisowa nie jest złotym środkiem 19
		1.6.2. Wzorce i języki wzorców 20Siły: kwestie, które musimy wziąć pod uwagę, kiedy rozwiązujemy problem 21  
			Wynikowy kontekst: konsekwencje zastosowania wzorca 21  
			Wzorce powiązane: pięć różnych rodzajów relacji 22
		1.6.3. Omówienie języka wzorców architektury mikroserwisowej 23
			Wzorce do dekompozycji aplikacji na usługi 23  
			Wzorce komunikacyjne 24  
			Wzorce spójności danych do wdrażania zarządzania transakcjami 25  
			Wzorce odpytywania danych w architekturze mikroserwisowej 26  
			Wzorce wdrażania usług 26  
			Wzorce obserwowalności zapewniają wgląd w zachowanie aplikacji 27  
			Wzorce automatycznego testowania usług 28  
			Wzorce do obsługi potrzeb przekrojowych 28  
			Wzorce bezpieczeństwa 28
	1.7. Poza mikroserwisami: proces i organizacja 29
		1.7.1. Tworzenie oprogramowania i organizacja dostarczania 29
		1.7.2. Proces tworzenia i dostarczania oprogramowania 30
		1.7.3. Ludzka strona wprowadzania mikroserwisów 31
2. Strategie dekompozycyjne 33
	2.1. Czym dokładnie jest architektura mikroserwisowa? 34
		2.1.1. Czym jest architektura oprogramowania i dlaczego ma ona znaczenie? 34
			Definicja architektury oprogramowania 35  
			Model perspektyw „4+1” w architekturze oprogramowania 35  
			Dlaczego architektura jest ważna? 37
		2.1.2. Przegląd stylów architektonicznych 37
			Styl: architektura warstwowa 37  
			Styl: architektura heksagonalna 38
		2.1.3. Architektura mikroserwisowa jest stylem architektonicznym 40
			Co to jest usługa? 41  
			Czym są luźne powiązania? 42  
			Rola współdzielonych bibliotek 43  
			Rozmiar usługi jest w zasadzie nieważny 43
	2.2. Definiowanie architektury mikroserwisowej aplikacji 44
		2.2.1. Identyfikowanie operacji systemu 45
			Tworzenie wysokopoziomowego modelu domeny 46  
			Określanie operacji systemu 48
		2.2.2. Definiowanie usług z zastosowaniem wzorca dekompozycji według zdolności biznesowych 50
			Zdolności biznesowe określają, co robi organizacja 51  
			Identyfikowanie zdolności biznesowych 51  
			Od zdolności biznesowych do usług 52
		2.2.3. Definiowanie usług z zastosowaniem dekompozycji według wzorca subdomeny 54
		2.2.4. Wytyczne dotyczące dekompozycji 55
			Zasada pojedynczej odpowiedzialności 56  
			Reguła wspólnego domknięcia 56
		2.2.5. Przeszkody w dekompozycji aplikacji na usługi 57
			Opóźnienia sieciowe 57  
			Synchroniczna komunikacja międzyprocesowa ogranicza dostępność 57  
			Utrzymanie spójności danych w usługach 57  
			Uzyskanie spójnego widoku danych 58  
			Dekompozycję utrudniają god classes 58
		2.2.6. Tworzenie API usług 60			
			Przypisywanie operacji systemu do usług 61  
			Określanie API wymaganego do realizowania współpracy między usługami 62
3. Komunikacja międzyprocesowa w architekturze mikroserwisowej 65
	3.1. Przegląd komunikacji międzyprocesowej w architekturze mikroserwisowej 66
		3.1.1. Style interakcji 67
		3.1.2. Definiowanie API w architekturze mikroserwisowej 68
		3.1.3. Ewolucja API 69
			Użycie semantycznego wersjonowania 70  
			Wprowadzanie drobnych, kompatybilnych wstecznie zmian 70  
			Wprowadzanie istotnych zmian 70
		3.1.4. Formaty komunikatów 71		
			Tekstowe formaty komunikatów 71  
			Binarne formaty komunikatów 72
	3.2. Komunikacja z użyciem wzorca synchronicznego zdalnego wywołania procedury 72
		3.2.1. Korzystanie z REST 73
			Model dojrzałości REST 74  
			Specyfikowanie REST API 74  
			Wyzwania związane z pobieraniem wielu zasobów w jednym żądaniu 75  
			Wyzwania związane z mapowaniem operacji na czasowniki HTTP 75  
			Zalety i wady REST 75
		3.2.2. Korzystanie z gRPC 76			
		3.2.3. Postępowanie w przypadku częściowej awarii z użyciem wzorca bezpiecznika 78
			Tworzenie solidnych proxy RPI 79  
			Reagowanie na niedostępne usługi 79
		3.2.4. Użycie wykrywania usług 80
			Wykrywanie usług 81  
			Stosowanie wzorców wykrywania usług na poziomie aplikacji 81  
			Stosowanie wzorców wykrywania usług na poziomie platformy 83
	3.3. Komunikacja z użyciem wzorca asynchronicznego przesyłania komunikatów 85
		3.3.1. Spojrzenie na przesyłanie komunikatów 86
			O komunikatach 86  
			O kanałach komunikatów 86
		3.3.2. Realizacja stylów interakcji za pomocą przesyłania komunikatów 87
			Realizacja żądanie/odpowiedź i asynchroniczne żądanie/odpowiedź 87  
			Realizacja powiadomień jednokierunkowych 88  
			Realizacja publikuj/subskrybuj 89  
			Realizacja publikowanie/asynchroniczna odpowiedź 89
		3.3.3. Tworzenie specyfikacji dla API usługi opartego na przesyłaniu komunikatów 89
			Dokumentowanie operacji asynchronicznych 89  
			Dokumentowanie publikowanych zdarzeń 90
		3.3.4. Użycie brokera komunikatów 90
			Przesyłanie komunikatów bez brokera 91  
			Przesyłanie komunikatów oparte na brokerze 92  
			Realizacja kanałów komunikatów za pomocą brokera 93  
			Korzyści i wady przesyłania komunikatów przez brokerów 93
		3.3.5. Konkurujący odbiorcy i sortowanie komunikatów 94
		3.3.6. Obsługa zduplikowanych komunikatów 95Tworzenie idempotentnej obsługi komunikatów 96  
			Śledzenie komunikatów i odrzucanie duplikatów 96
		3.3.7. Komunikaty transakcyjne 97
			Użycie tabeli bazy danych jako kolejki komunikatów 97  
			Publikowanie zdarzeń z użyciem wzorca publikatora z przeszukiwaniem 98  
			Publikowanie zdarzeń z zastosowaniem wzorca śledzenia dziennika transakcji 99
		3.3.8. Biblioteki i frameworki do przesyłania komunikatów 100
			Proste przesyłanie komunikatów 101  
			Publikowanie zdarzeń domenowych 102  
			Przesyłanie komunikatów oparte na poleceniu/odpowiedzi 102
	3.4. Użycie asynchronicznego przesyłania komunikatów w celu poprawy dostępności 103
			3.4.1. Komunikacja synchroniczna zmniejsza dostępność 103
		3.4.2. Eliminowanie interakcji synchronicznych 105
			Użycie asynchronicznych stylów interakcji 105  
			Replikacja danych 105  
			Zakończenie przetwarzania po zwróceniu odpowiedzi 106
4. Zarządzanie transakcjami z użyciem sag 110
	4.1. Zarządzanie transakcjami w architekturze mikroserwisowej 111
		4.1.1. Potrzeba transakcji rozproszonych w architekturze mikroserwisowej 112
		4.1.2. Problem z rozproszonymi transakcjami 112
		4.1.3. Użycie wzorca sagi do zarządzania spójnością danych 114
			Przykładowa saga: Create Order Saga 114  
			Do wycofania zmian sagi wykorzystują transakcje kompensujące 115
	4.2. Koordynowanie sag 117
		4.2.1. Sagi oparte na choreografii 118
			Realizacja Create Order Saga z wykorzystaniem choreografii 118  
			Niezawodna komunikacja oparta na zdarzeniach 120  
			Zalety i wady sag opartych na choreografii 121
		4.2.2. Sagi oparte na orkiestracji 121
			Realizacja Create Order Saga z wykorzystaniem orkiestracji 122  
			Modelowanie orkiestratorów sagi jako maszyn stanów 123  
			Orkiestracja sagi i komunikaty transakcyjne 124  
			Zalety i wady sag opartych na orkiestracji 125
	4.3. Radzenie sobie z brakiem izolacji 125
		4.3.1. Przegląd anomalii 126
			Utracone aktualizacje 127  
			Brudne odczyty 127
		4.3.2. Przeciwdziałania związane z brakiem izolacji 127
			Struktura sagi 128  
			Blokada semantyczna 129  
			Aktualizacje przemienne 130  
			Podejście pesymistyczne 130  
			Ponowne odczytanie wartości 131  
			Rejestr kroków 131  
			Według korzyści 131
	4.4. Projekt usługi Order Service i sagi Create Order Saga 132
		4.4.1. Klasa OrderService 133
		4.4.2. Implementacja Create Order Saga 134
			Orkiestrator CreateOrderSaga 136  
			Klasa CreateOrderSagaState 137  
			Klasa KitchenServiceProxy 138  
			Framework Eventuate Tram Saga 139
		4.4.3. Klasa OrderCommandHandlers 142
		4.4.4. Klasa OrderServiceConfiguration 143
5. Projektowanie logiki biznesowej w architekturze mikroserwisowej 146
	5.1. Wzorce organizacji logiki biznesowej 147
		5.1.1. Projektowanie logiki biznesowej z użyciem wzorca skryptu transakcji 149
		5.1.2. Projektowanie logiki biznesowej z użyciem wzorca modelu domeny 150
		5.1.3. Domain-Driven Design 151
	5.2. Projektowanie modelu domeny z użyciem wzorca agregatu DDD 152
		5.2.1. Problem z rozmytymi granicami 153
		5.2.2. Agregaty mają wyraźne granice 154
			Agregaty są granicami spójności 154  
			Kluczowa jest identyfikacja agregatów 155
		5.2.3. Zasady agregatów 155
			Zasada 1: Odniesienie tylko do korzenia agregatu 155  
			Zasada 2: Odniesienia między agregatami muszą korzystać z kluczy głównych 156  
			Zasada 3: Jedna transakcja tworzy lub aktualizuje jeden agregat 156
		5.2.4. Ziarnistość agregatu 157
		5.2.5. Projektowanie logiki biznesowej z agregatami 158
	5.3. Publikowanie zdarzeń domenowych 159
		5.3.1. Dlaczego publikować zdarzenia związane ze zmianą stanu? 160
		5.3.2. Czym jest zdarzenie domenowe? 160
		5.3.3. Wzbogacanie zdarzeń 161
		5.3.4. Identyfikowanie zdarzeń domenowych 162
		5.3.5. Generowanie i publikowanie zdarzeń domenowych 163
			Generowanie zdarzeń domenowych 163  
			Jak niezawodnie publikować zdarzenia domenowe? 165
		5.3.6. Pobieranie zdarzeń domenowych 167
	5.4. Logika biznesowa Kitchen Service 167
		5.4.1. Agregat Ticket 169
			Struktura klasy Ticket 169  
			Zachowanie agregatu Ticket 170  
			Usługa KitchenService 171  
			Klasa KitchenServiceCommandHandler 171
	5.5. Logika biznesowa Order Service 172
		5.5.1. Agregat Order 174
			Struktura agregatu Order 174  
			Maszyna stanów agregatu Order 175  
			Metody agregatu Order 176
		5.5.2. Klasa OrderService 179
6. Rozwijanie logiki biznesowej za pomocą pozyskiwania zdarzeń 182
	6.1. Wykorzystywanie wzorca pozyskiwania zdarzeń do tworzenia logiki biznesowej 183
		6.1.1. Problemy tradycyjnego utrwalania 184
			Niedopasowanie między modelem obiektowym a relacyjnym 184  
			Brak zagregowanej historii 185  
			Wdrożenie dzienników zdarzeń jest uciążliwe i podatne na błędy 185  
			Publikowanie zdarzeń jest powiązane z logiką biznesową 185
		6.1.2. Pozyskiwanie zdarzeń 185Pozyskiwanie zdarzeń utrwala agregaty, korzystając ze zdarzeń 185  
			Zdarzenia reprezentują zmiany stanu 187  
			Metody agregatów dotyczą zdarzeń 188  
			Agregat Order wykorzystujący pozyskiwanie zdarzeń 190
		6.1.3. Obsługa jednoczesnych aktualizacji z użyciem optymistycznego blokowania 192
		6.1.4. Pozyskiwanie zdarzeń i publikowanie zdarzeń 193
			Użycie przeszukiwania do publikowania zdarzeń 193  
			Wykorzystanie śledzenia dziennika transakcji do niezawodnego publikowania zdarzeń 194
		6.1.5. Użycie migawek do poprawy wydajności 194	
		6.1.6. Idempotentne przetwarzanie komunikatów 195
			Idempotentne przetwarzanie komunikatów z magazynem zdarzeń używającym RDBMS 196  
			Idempotentne przetwarzanie komunikatów z magazynem zdarzeń używającym NoSQL 196
		6.1.7. Rozwój zdarzeń domenowych 197
			Ewolucja schematu zdarzeń 197  
			Zarządzanie zmianami schematu przez rzutowanie w górę 198
		6.1.8. Zalety pozyskiwania zdarzeń 198
			Niezawodne publikowanie zdarzeń domenowych 199  
			Zachowywanie historii agregatów 199  
			Zwykle pomaga uniknąć problemu niedopasowania między modelem relacyjnym a obiektowym 199  
			Oferuje programistom maszynę czasu 199
		6.1.9. Wady pozyskiwania zdarzeń 199
			Inny model programowania powodujący wzrost krzywej uczenia się 200  
			Złożoność aplikacji opartej na przesyłaniu komunikatów 200  
			Ewolucja zdarzeń może być trudna 200  
			Usuwanie danych jest trudne 200  
			Wykonywanie zapytań do magazynu zdarzeń jest trudne 201
	6.2. Implementowanie magazynu zdarzeń 201
		6.2.1. Jak działa magazyn zdarzeń Eventuate Local 202
			Schemat bazy danych zdarzeń Eventuate Local 202  
			Pobieranie zdarzeń przez subskrybowanie brokera zdarzeń Eventuate Local 204  
			Przekaźnik zdarzeń Eventuate Local propaguje zdarzenia z bazy danych do brokera komunikatów 204
		6.2.2. Środowisko klienta Eventuate dla Javy 205
			Definiowanie agregatów za pomocą klasy ReflectiveMutableCommandProcessingAggregate 206  
			Definiowanie poleceń agregatu 206  
			Definiowanie zdarzeń domenowych 206  
			Tworzenie, wyszukiwanie i aktualizacja agregatów za pomocą klasy AggregateRepository 207  
			Subskrybowanie zdarzeń domenowych 208
	6.3. Łączne używanie sag i pozyskiwania zdarzeń 208
		6.3.1. Realizacja sag opartych na choreografii z wykorzystaniem pozyskiwania zdarzeń 209
		6.3.2. Tworzenie sagi opartej na orkiestracji 210
			Tworzenie orkiestratora sagi podczas korzystania z magazynu zdarzeń opartego na RDMBS 210  
			Tworzenie orkiestratora sagi podczas korzystania z magazynu zdarzeń opartego na NoSQL 211
		6.3.3. Tworzenie uczestnika sagi opartej na pozyskiwaniu zdarzeń 212
			Idempotentna obsługa komunikatów poleceń 213  
			Atomowe wysyłanie komunikatów zwrotnych 213  
			Przykład uczestnika sagi opartej na pozyskiwaniu zdarzeń 213
		6.3.4. Projektowanie orkiestratorów sagi z użyciem pozyskiwania zdarzeń 216
			Utrzymywanie orkiestratora sagi z użyciem pozyskiwania zdarzeń 216  
			Niezawodne wysyłanie komunikatów poleceń 216  
			Dokładnie jednokrotne przetwarzanie odpowiedzi 217
7. Implementowanie zapytań w architekturze mikroserwisowej 219
	7.1. Tworzenie zapytań z użyciem wzorca kompozycji API 220
		7.1.1. Operacja zapytania findOrder() 220
		7.1.2. Wzorzec kompozycji API 221
		7.1.3. Implementowanie operacji zapytania findOrder() z wykorzystaniem wzorca kompozycji API 223
		7.1.4. Problemy projektowe związane z wzorcem kompozycji API 224
			Kto powinien odgrywać rolę API Composer? 224  
			API Composer powinien stosować model programowania reaktywnego 226
		7.1.5. Wady i zalety wzorca kompozycji API 226
			Zwiększone koszty ogólne 226  
			Ryzyko zmniejszonej dostępności 226  
			Brak spójności danych transakcyjnych 227
	7.2. Korzystanie z wzorca CQRS 227
		7.2.1. Motywacja do korzystania z CQRS 228
			Realizacja operacji zapytania findOrderHistory() 228  
			Wymagające zapytanie dotyczące pojedynczej usługi findAvailableRestaurants() 230  
			Konieczność oddzielenia obowiązków 230
		7.2.2. Przegląd CQRS 231
			CQRS oddziela polecenia od zapytań 231  
			CQRS i usługi tylko dla zapytań 232
		7.2.3. Zalety CQRS 234
			Umożliwia wydajną implementację zapytań w architekturze mikroserwisowej 234  
			Umożliwia wydajną implementację zróżnicowanych zapytań 234  
			Zapewnia wykonywanie zapytań w aplikacji opartej na pozyskiwaniu zdarzeń 234  
			Poprawia separację obowiązków 234
		7.2.4. Wady CQRS 235
			Bardziej złożona architektura 235  
			Konieczność radzenia sobie z opóźnieniem replikacji 235
	7.3. Projektowanie widoków CQRS 236
		7.3.1. Wybór magazynu danych widoku 236
			Bazy danych SQL kontra NoSQL 237  
			Wspieranie operacji aktualizacji 238
		7.3.2. Projekt modułu dostępu do danych 238
			Obsługa jednoczesnych aktualizacji 239  
			Idempotentne procedury obsługi zdarzeń 239  
			Umożliwienie aplikacji klienckiej korzystania z ostatecznie spójnego widoku 240
		7.3.3. Dodawanie i aktualizacja widoków CQRS 241
			Budowanie widoków CQRS z użyciem zarchiwizowanych zdarzeń 241  
			Stopniowe budowanie widoków CQRS 241
	7.4.Implementowanie widoku CQRS za pomocą AWS DynamoDB 241
		7.4.1. Moduł OrderHistoryEventHandlers 243
		7.4.2. Modelowanie danych i projektowanie zapytań za pomocą DynamoDB 243
			Projektowanie tabeli ftgo-order-history 244  
			Zdefiniowanie indeksu dla zapytania findOrderHistory 245  
			Realizacja zapytania findOrderHistory 245  
			Stronicowanie wyników zapytania 246  
			Aktualizowanie zamówień 247  
			Wykrywanie zduplikowanych zdarzeń 247
		7.4.3. Klasa OrderHistoryDaoDynamoDb 248
			Metoda addOrder() 248  
			Metoda notePickedUp() 249  
			Metoda idempotentUpdate() 249  
			Metoda findOrderHistory() 250
8. Wzorce zewnętrznych API 253
	8.1. Problemy z projektowaniem zewnętrznego API 254
		8.1.1. Problemy z projektowaniem API dla mobilnego klienta FTGO 255
			Gorszy komfort użytkowania spowodowany klientem wykonującym wiele zapytań 257  
			Brak enkapsulacji wymaga od programistów frontendu, aby zmieniali swój kod krok w krok ze zmianami w backendzie 257  
			Usługi mogą wykorzystywać mechanizmy IPC nieprzyjazne dla klientów 257
		8.1.2. Problemy z projektowaniem API dla innych typów klientów 258
			Problemy z projektowaniem API dla aplikacji webowych 258  
			Problemy z projektowaniem API dla aplikacji JavaScript działających w przeglądarce 258  
			Projektowanie API dla aplikacji zewnętrznych 258
	8.2. Wzorzec bramy API 259
		8.2.1. Wzorzec bramy API 259Przekierowywanie żądań 260  
			Kompozycja API 260  
			Translacja protokołów 261  
			Brama API oferuje każdemu klientowi specyficzne API 262  
			Implementowanie funkcji brzegowych 262  
			Architektura bramy API 263  
			Model własności bramy API 264  
			Korzystanie z wzorca Backends for Frontends 264
		8.2.2. Zalety i wady bramy API 266
			Zalety bramy API 266  
			Wady bramy API 267
		8.2.3. Netflix jako przykład bramy API 267
		8.2.4. Problemy z projektowaniem bramy API 267
			Wydajność i skalowalność 268  
			Użycie abstrakcji programowania reaktywnego 269  
			Postępowanie w przypadku częściowej awarii 270  
			Bycie dobrym obywatelem w architekturze aplikacji 270
	8.3. Implementowanie bramy API 271
		8.3.1. Skorzystanie z gotowego produktu/usługi bramy API 271
			Brama API AWS 271  
			AWS Application Load Balancer 272  
			Użycie produktu typu brama API 272
		8.3.2. Opracowanie własnej bramy API 272
			Użycie Netflix Zuul 273  
			O Spring Cloud Gateway 273  
			Klasa OrderConfiguration 275  
			Klasa OrderHandlers 276  
			Klasa OrderService 278  
			Klasa ApiGatewayApplication 279
		8.3.3. Realizacja bramy API za pomocą GraphQL 279
			Definiowanie schematu GraphQL 281  
			Wykonywanie zapytań GraphQL 284  
			Podłączanie schematu do danych 285  
			Optymalizacja ładowania za pomocą grupowania i buforowania 287  
			Integracja serwera Apollo GraphQL z Expressem 288  
			Tworzenie klienta GraphQL 290
9. Testowanie mikroserwisów: część 1 292
	9.1. Strategie testowania w architekturze mikroserwisowej 294
		9.1.1. Testowanie 295Pisanie testów automatycznych 295  
			Testowanie z użyciem obiektów typu mock i stub 296  Różne rodzaje testów 297  
			Wykorzystanie kwadrantu testowego do kategoryzacji testów 298  
			Wykorzystanie piramidy testów jako przewodnika w wysiłkach związanych z testowaniem 299
		9.1.2. Wyzwania związane z testowaniem mikroserwisów 300
			Test kontraktowy ukierunkowany na klienta 302  
			Testowanie usług z wykorzystaniem Spring Cloud Contract 304  
			Konsumenckie testy kontraktowe API przesyłania komunikatów 306
		9.1.3. Strumień wdrażania 306
	9.2. Pisanie testów jednostkowych dla usługi 307
		9.2.1. Projektowanie testów jednostkowych dla encji 310
		9.2.2. Pisanie testów jednostkowych dla obiektów wartości 310
		9.2.3. Opracowywanie testów jednostkowych dla sag 311
		9.2.4. Pisanie testów jednostkowych dla usług domenowych 313
		9.2.5. Opracowywanie testów jednostkowych dla kontrolerów 314
		9.2.6. Pisanie testów jednostkowych dla procedur obsługi zdarzeń i komunikatów 316
10. Testowanie mikroserwisów: część 2 319
	10.1. Pisanie testów integracyjnych 320
		10.1.1. Testy integracyjne trwałości 322
		10.1.2. Testy integracyjne interakcji żądanie/odpowiedź wykorzystującej REST 323
			Przykładowy kontrakt dla REST API 325  
			Integracyjny test kontraktowy ukierunkowany na klienta dla Order Service 325  
			Test integracyjny po stronie konsumenta dla OrderServiceProxy z API Gateway 326
		10.1.3. Testy integracyjne interakcji publikuj/subskrybuj 328
			Kontrakt dla publikowania zdarzenia OrderCreated 329  
			Test kontraktowy ukierunkowany na konsumenta dla Order Service 329  
			Test kontraktowy po stronie konsumenta dla Order History Service 330
		10.1.4. Kontraktowe testy integracyjne interakcji asynchroniczne żądanie/odpowiedź 332
			Przykładowy kontrakt dla asynchronicznego żądania/odpowiedzi 333  
			Kontraktowy test integracyjny po stronie konsumenta dla interakcji asynchroniczne żądanie/odpowiedź 334  
			Pisanie testów kontraktowych po stronie dostawcy przeznaczonych do testowania konsumenta w zakresie asynchronicznej interakcji żądanie/odpowiedź 335
	10.2. Tworzenie testów komponentów 336
		10.2.1. Definiowanie testów akceptacyjnych 337
		10.2.2. Pisanie testów akceptacyjnych z użyciem Gherkina 338
			Wykonywanie specyfikacji Gherkina za pomocą Cucumber 339
		10.2.3. Projektowanie testów komponentów 340
			Wewnątrzprocesowe testy komponentów 340  
			Pozaprocesowe testowanie komponentu 341  
			Jak tworzyć obiekty stubs dla usług w pozaprocesowych testach komponentów 341
		10.2.4. Pisanie testów komponentów dla Order Service z FTGO 342
			Klasa OrderServiceComponentTestStepDefinitions 343  
			Uruchamianie testów komponentów 345
	10.3. Pisanie testów end-to-end 346
		10.3.1. Projektowanie testów end-to-end 347
		10.3.2. Pisanie testów end-to-end 347
		10.3.3. Uruchamianie testów end-to-end 348
11. Opracowywanie usług gotowych do produkcji 349
	11.1. Opracowywanie bezpiecznych usług 350
		11.1.1. Przegląd kwestii bezpieczeństwa w tradycyjnej aplikacji monolitycznej 351
		11.1.2. Realizacja kwestii bezpieczeństwa w architekturze mikroserwisowej 354
			Obsługa uwierzytelniania w bramie API 355  
			Obsługa autoryzacji 357  
			Użycie JWT do przekazywania tożsamości użytkownika i roli 357  
			Użycie OAuth 2.0 w architekturze mikroserwisowej 358
	11.2. Projektowanie konfigurowalnych usług 361
		11.2.1. Użycie konfiguracji zewnętrznej opartej na udostępnianiu 363
		11.2.2. Użycie konfiguracji zewnętrznej opartej na pobieraniu 364
	11.3. Projektowanie obserwowalnych usług 366
		11.3.1. Użycie wzorca API kontroli działania 367
			Realizacja punktu końcowego kontroli działania 369  
			Wywołanie punktu końcowego kontroli działania 369
		11.3.2. Stosowanie wzorca agregacji dzienników 369
			W jaki sposób usługa generuje dziennik? 370  
			Infrastruktura agregacji dzienników 371
		11.3.3. Stosowanie wzorca rozproszonego śledzenia 371
			Użycie biblioteki instrumentacji 373  
			Serwer rozproszonego śledzenia 374
		11.3.4. Stosowanie wzorca metryk aplikacji 375
			Zbieranie metryk na poziomie usługi 376  
			Dostarczanie metryk do usługi metryk 377
		11.3.5. Stosowanie wzorca śledzenia wyjątków 377
		11.3.6. Stosowanie wzorca dzienników inspekcji 379
			Dodawanie kodu dzienników inspekcji do logiki biznesowej 379  
			Użycie programowania aspektowego 379  
			Użycie pozyskiwania zdarzeń 379
	11.4. Tworzenie usług za pomocą wzorca szkieletów mikroserwisowych 380
		11.4.1. Korzystanie ze szkieletu mikroserwisowego 381
		11.4.2. Od szkieletu mikroserwisowego do service mesh 381
12. Wdrażanie mikroserwisów 384
	12.1. Wdrażanie usług jako pakietów specyficznych dla języka 387
		12.1.1. Zalety wzorca usługi jako pakietu specyficznego dla języka 389
			Szybkie wdrażanie 390  
			Efektywne wykorzystanie zasobów 390
		12.1.2. Wady wzorca usługi jako pakietu specyficznego dla języka 390
			Brak enkapsulacji stosu technologicznego 390  
			Brak możliwości ograniczenia zasobów zużywanych przez instancję usługi 391  
			Brak izolacji podczas uruchamiania wielu instancji usługi na tej samej maszynie 391  
			Automatyczne określenie miejsca umieszczenia instancji usługi jest trudne 391
	12.2. Wdrażanie usług z użyciem wzorca usługi jako maszyny wirtualnej 391
		12.2.1. Zalety wdrażania usług jako maszyn wirtualnych 393
			Obraz maszyny wirtualnej hermetyzuje stos technologiczny 393  
			Instancje usług są izolowane 393  
			Wykorzystanie wyrafinowanej infrastruktury chmurowej 393
		12.2.2. Wady wdrażania usług jako maszyn wirtualnych 394
			Mniej wydajne wykorzystanie zasobów 394  
			Wolne wdrożenia 394  
			Narzut związany z administracją systemem 394
	12.3. Wdrażanie usług za pomocą wzorca usługi jako kontenera 394
		12.3.1. Wdrażanie usług za pomocą Dockera 396
			Budowanie obrazu Dockera 397  
			Wysyłanie obrazu Dockera do rejestru 398  
			Uruchamianie kontenera Dockera 398
		12.3.2. Zalety wdrażania usług jako kontenerów 399
		12.3.3. Wady wdrażania usług jako kontenerów 400
	12.4. Wdrażanie aplikacji FTGO za pomocą Kubernetesa 400
		12.4.1. Kubernetes 400
			Architektura Kubernetesa 402  
			Kluczowe pojęcia Kubernetesa 403
		12.4.2. Wdrażanie Restaurant Service w Kubernetesie 404
			Tworzenie service w Kubernetesie 406  
			Wdrażanie bramy API 407
		12.4.3. Wdrożenia bez przestojów 408
		12.4.4. Użycie service mesh w celu oddzielenia wdrożenia od wydania 409
			Service mesh Istio 410  
			Wdrażanie usługi za pomocą Istio 412  
			Tworzenie reguł routingu do wersji v1 413  
			Wdrażanie wersji 2 Consumer Service 415  
			Przekierowywanie części testowego ruchu do wersji 2 415  
			Kierowanie produkcyjnego ruchu do wersji 2 416
	12.5. Wdrażanie usług za pomocą wzorca wdrożenia bezserwerowego 417
		12.5.1. Bezserwerowe wdrażanie za pomocą AWS Lambda 417
		12.5.2. Tworzenie funkcji lambda 418
		12.5.3. Wywoływanie funkcji lambda 419
			Obsługa żądań HTTP 419  
			Obsługa zdarzeń generowanych przez usługi AWS 419  
			Definiowanie zaplanowanych funkcji lambda 419  
			Wywoływanie funkcji lambda za pomocą żądania usługi sieciowej 419
		12.5.4. Zalety użycia funkcji lambda 420
		12.5.5. Wady użycia funkcji lambda 420
	12.6. Wdrażanie usługi RESTful z użyciem AWS Lambda i AWS Gateway 421
		12.6.1. Projekt AWS Lambda wersji Restaurant Service 421
			Klasa FindRestaurantRequestHandler 423  
			Wstrzykiwanie zależności z użyciem klasy AbstractAutowiringHttpRequestHandler 424  
			Klasa AbstractHttpHandler 425
		12.6.2. Pakowanie usługi jako pliku ZIP 426
		12.6.3. Wdrażanie funkcji lambda z użyciem frameworka Serverless 426
13. Refaktoryzacja do mikroserwisów 429
	13.1. Refaktoryzacja do mikroserwisów 430
		13.1.1. Dlaczego warto refaktoryzować monolit? 431
		13.1.2. Duszenie monolitu 431
			Szybkie i częste prezentowanie wartości dodanej 433  
			Minimalizacja zmian w monolicie 434  
			Techniczne aspekty infrastruktury wdrożeniowej: nie potrzebujemy wszystkiego od razu 434
	13.2. Strategie refaktoryzacji monolitu do mikroserwisów 434
		13.2.1. Realizacja nowych funkcjonalności jako usług 435
			Integracja nowej usługi z monolitem 435  
			Kiedy zaimplementować nową funkcjonalność jako usługę 435
		13.2.2. Oddzielanie warstwy prezentacji od backendu 437
		13.2.3. Wyodrębnianie zdolności biznesowych do usług 438
			Podział modelu domeny 440  
			Refaktoryzacja bazy danych 441  
			Replikowanie danych w celu uniknięcia rozległych zmian 442  
			Jakie usługi wyodrębniać i kiedy 443
	13.3. Projektowanie, w jaki sposób usługa i monolit będą współpracować 444
		13.3.1. Projektowanie kodu integrującego 445
			Projektowanie API kodu integrującego 445  
			Wybór stylu interakcji i mechanizmu IPC 446  
			Projektowanie Anti-Corruption Layer 448  
			Jak monolit publikuje i subskrybuje zdarzenia domenowe 449
		13.3.2. Utrzymywanie spójności danych w usłudze i monolicie 450
			Wyzwanie związane ze zmianą monolitu, aby wspierał transakcje kompensujące 451  
			Sagi nie zawsze wymagają od monolitu wspierania transakcji kompensujących 452  
			Określanie kolejności wyodrębniania usług w celu uniknięcia konieczności implementacji transakcji kompensujących w monolicie 453
		13.3.3. Obsługa uwierzytelniania i autoryzacji 455
			LoginHandler monolitu ustawia plik cookie USERINFO 456  
			Brama API mapuje plik cookie USERINFO na nagłówek Authorization 456
	13.4. Wdrażanie nowej funkcjonalności jako usługi: obsługa niezrealizowanych zamówień 457
		13.4.1. Projekt Delayed Delivery Service 458
		13.4.2. Projektowanie kodu integrującego dla Delayed Delivery Service 459
			Pobieranie informacji kontaktowych klienta z wykorzystaniem CustomerContactInfoRepository 460  
			Publikowanie i pobieranie zdarzeń domenowych Order i Restaurant 460
	13.5. Rozbijanie monolitu: wyodrębnianie zarządzania dostawami 461
		13.5.1. Przegląd istniejącej funkcjonalności związanej z zarządzaniem dostawami 461
		13.5.2. Przegląd Delivery Service 463
		13.5.3. Projekt modelu domeny Delivery Service 464
			Określenie encji i ich pól, które są częścią zarządzania dostawami 464  
			Decydowanie, które dane przenieść do Delivery Service 465  
			Projekt logiki domeny Delivery Service 466
		13.5.4. Projekt kodu integrującego Delivery Service 467
			Projekt API Delivery Service 467  
			W jaki sposób Delivery Service będzie uzyskiwał dostęp do danych monolitu FTGO? 468  
			W jaki sposób monolit FTGO będzie uzyskiwał dostęp do danych Delivery Service? 468
		13.5.5. Dostosowanie monolitu FTGO do współpracy z Delivery Service 468
			Definiowanie interfejsu DeliveryService 468  
			Refaktoryzacja monolitu w celu wywoływania interfejsu DeliveryService 469  
			Implementacja interfejsu DeliveryService 470  
			Przełączanie funkcjonalności 470
indeks 473