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

Spis treści ebooka Mikroserwisy. Wzorce z przykładami w języku Java

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