Mikroserwisy. wzorce z przykładami w języku java, AZ#AA3EF153EB/DL-ebwm/epub (Wydawnictwo Naukowe PWN)

Tytuł Mikroserwisy. Wzorce z przykładami w języku Java Autor Chris Richardson Język polski Wydawnictwo Wydawnictwo Naukowe PWN Tłumaczenie Magdalena Rogulska, Mariusz Rogulski ISBN 978-83-01-21223-0 Rok wydania 2020 Wydanie 1 ilość stron 504 Format mobi, epub Spis treści 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. Atuty 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 nieprzystępne 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 adekwatna 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 dużo 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ę informacji 12 1.4.4. Architektura mikroserwisowa FTGO 12 1.4.5. Porównanie architektury mikroserwisowej i SOA 13 1.5. Atuty i wady architektury mikroserwisowej 14 1.5.1. Zalety architektury mikroserwisowej 14 Umożliwianie ciągłego dostarczania i wdrażania pokaźnych, złożonych aplikacji 15 Każda usługa jest śladowa i nieskomplikowana w utrzymaniu 15 Usługi są niezależnie skalowalne 16 ulepszona izolacja błędów 16 przystępne eksperymentowanie i wdrażanie nowych technice 17 1.5.2. Wady architektury mikroserwisowej 17 Znalezienie stosownych usług jest nieprzystępne 17 Systemy rozproszone są złożone 17 Wdrażanie funkcjonalności obejmujących mnóstwo usług wymaga dokładnej koordynacji 18 Decyzja o przyjęciu jest nieprzystępna 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 zabrać pod uwagę, kiedy rozwiązujemy problem 21 Wynikowy kontekst: konsekwencje wykorzystania wzorca 21 Wzorce powiązane: pięć przeróż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 informacji 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. Cykl tworzenia i dostarczania oprogramowania 30 1.7.3. Ludzka strona wprowadzania mikroserwisów 31 2. Strategie dekompozycyjne 33 2.1. Czym precyzyjnie 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 fason: architektura warstwowa 37 fason: architektura heksagonalna 38 2.1.3. Architektura mikroserwisowa jest stylem architektonicznym 40 Co to jest usługa? 41 Czym są swobodne powiązania? 42 Rola współdzielonych bibliotek 43 wymiar 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 wykorzystaniem 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 przystępność 57 Utrzymanie spójności informacji 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 pomię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 zastosowanie semantycznego wersjonowania 70 Wprowadzanie drobnych, kompatybilnych wstecznie zmian 70 Wprowadzanie widocznych zmian 70 3.1.4. Formaty komunikatów 71 Tekstowe formaty komunikatów 71 Binarne formaty komunikatów 72 3.2. Komunikacja z wykorzystaniem 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. Nowoczesnanie w sytuacji częściowej awarii z wykorzystaniem wzorca bezpiecznika 78 Tworzenie mocnych proxy RPI 79 Reagowanie na niedostępne usługi 79 3.2.4. Zastosowanie wykrywania usług 80 Wykrywanie usług 81 stosowanie wzorców wykrywania usług na poziomie aplikacji 81 używanie wzorców wykrywania usług na poziomie platformy 83 3.3. Komunikacja z wykorzystaniem 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 przy pomocy 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. Wykorzystanie 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 poprzez 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 zastosowanie tabeli bazy informacji 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 zniża przystępność 103 3.4.2. Likwidowanie interakcji synchronicznych 105 zastosowanie asynchronicznych stylów interakcji 105 Replikacja informacji 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ą informacji 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 zastosowaniem choreografii 118 bezusterkowa komunikacja oparta na zdarzeniach 120 atuty i wady sag opartych na choreografii 121 4.2.2. Sagi oparte na orkiestracji 121 Realizacja Create Order Saga z użyciem 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 wykorzystaniem wzorca skryptu transakcji 149 5.1.2. Projektowanie logiki biznesowej z wykorzystaniem 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 pomiędzy agregatami muszą korzystać z kluczy głównych 156 Zasada 3: Jedna transakcja tworzy albo 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 bezusterkowo 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 przy pomocy pozyskiwania zdarzeń 182 6.1. Użytkowanie wzorca pozyskiwania zdarzeń do tworzenia logiki biznesowej 183 6.1.1. Problemy klasycznego utrwalania 184 Niedopasowanie pomię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 zastosowanie przeszukiwania do publikowania zdarzeń 193 wykorzystanie śledzenia dziennika transakcji do niezawodnego publikowania zdarzeń 194 6.1.5. Wykorzystanie migawek do poprawy efektywnoś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 poprzez rzutowanie w górę 198 6.1.8. Mocne strony pozyskiwania zdarzeń 198 niezawodne publikowanie zdarzeń domenowych 199 Zachowywanie historii agregatów 199 w głównej mierze pomaga uniknąć problemu niedopasowania pomię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ć skomplikowana 200 eliminowanie danych jest nieprzystępne 200 realizowanie zapytań do magazynu zdarzeń jest skomplikowane 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 przy pomocy 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 w trakcie 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 wykorzystaniem pozyskiwania zdarzeń 216 Utrzymywanie orkiestratora sagi z wykorzystaniem pozyskiwania zdarzeń 216 bezawaryjne wysyłanie komunikatów poleceń 216 skrupulatnie jednokrotne przetwarzanie odpowiedzi 217 7. Implementowanie zapytań w architekturze mikroserwisowej 219 7.1. Tworzenie zapytań z użyciem wzorca kompilacji API 220 7.1.1. Operacja zapytania findOrder() 220 7.1.2. Wzorzec kombinacji API 221 7.1.3. Implementowanie operacji zapytania findOrder() z wykorzystaniem wzorca kompilacji API 223 7.1.4. Problemy projektowe związane z wzorcem kompilacji 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 powiększone koszty ogólne 226 Ryzyko zmniejszonej przystę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 zezwala na produktywną implementację zapytań w architekturze mikroserwisowej 234 pozwala na produktywną implementację zróżnicowanych zapytań 234 gwarantuje 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 informacji widoku 236 Bazy danych SQL kontra NoSQL 237 Wspieranie operacji aktualizacji 238 7.3.2. Projekt modułu dostępu do informacji 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 przy pomocy AWS DynamoDB 241 7.4.1. Moduł OrderHistoryEventHandlers 243 7.4.2. Modelowanie informacji i projektowanie zapytań przy pomocy 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żywania spowodowany klientem wykonującym mnóstwo 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 oglądarce 258 Projektowanie API dla aplikacji zewnętrznych 258 8.2. Wzorzec bramy API 259 8.2.1. Wzorzec bramy API 259Przekierowywanie żądań 260 kombinacja API 260 Translacja protokołów 261 Brama API oferuje każdemu klientowi unikalne 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. Atuty i wady bramy API 266 mocne strony 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 efektywność i skalowalność 268 użycie abstrakcji programowania reaktywnego 269 innowacyjnanie w przypadku częściowej awarii 270 Bycie prawidłowym obywatelem w architekturze aplikacji 270 8.3. Implementowanie bramy API 271 8.3.1. Skorzystanie z gotowego artykułu/usługi bramy API 271 Brama API AWS 271 AWS Application Load Balancer 272 użycie typu brama API 272 8.3.2. Opracowanie własnej bramy API 272 zastosowanie 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 realizowanie zapytań GraphQL 284 przyłączanie schematu do danych 285 Optymalizacja ładowania przy pomocy 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 wykorzystaniem obiektów rodzaju mock i stub 296 zróżnicowane warianty testów 297 użycie 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 użyciem 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 dedykowanych do testowania konsumenta w zakresie asynchronicznej interakcji żądanie/odpowiedź 335 10.2. Tworzenie testów części 336 10.2.1. Definiowanie testów akceptacyjnych 337 10.2.2. Pisanie testów akceptacyjnych z zastosowaniem Gherkina 338 realizowanie specyfikacji Gherkina przy pomocy Cucumber 339 10.2.3. Projektowanie testów składników 340 wewnątrzprocesowe testy elementów 340 Pozaprocesowe testowanie komponentu 341 Jak tworzyć obiekty stubs dla usług w pozaprocesowych testach składnikó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 klasycznej 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 wykorzystanie JWT do przekazywania tożsamości użytkownika i roli 357 zastosowanie OAuth 2.0 w architekturze mikroserwisowej 358 11.2. Projektowanie konfigurowalnych usług 361 11.2.1. Wykorzystanie konfiguracji zewnętrznej opartej na udostępnianiu 363 11.2.2. Wykorzystanie konfiguracji zewnętrznej opartej na pobieraniu 364 11.3. Projektowanie obserwowalnych usług 366 11.3.1. Zastosowanie 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. Użytkowanie wzorca agregacji dzienników 369 W jaki sposób usługa tworzy dziennik? 370 Infrastruktura agregacji dzienników 371 11.3.3. Stosowanie wzorca rozproszonego śledzenia 371 wykorzystanie 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. Używanie wzorca śledzenia wyjątków 377 11.3.6. Stosowanie wzorca dzienników inspekcji 379 Dodawanie kodu dzienników inspekcji do logiki biznesowej 379 wykorzystanie programowania aspektowego 379 użycie pozyskiwania zdarzeń 379 11.4. Tworzenie usług przy pomocy 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 zestawów oryginalnych dla języka 387 12.1.1. Mocne strony wzorca usługi jako kompletu niepowtarzalnego dla języka 389 szybkie wdrażanie 390 sprawne wykorzystanie zasobów 390 12.1.2. Wady wzorca usługi jako zestawu specyficznego dla języka 390 Brak enkapsulacji stosu technicznego 390 Brak możliwości ograniczenia zasobów zużywanych poprzez 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 nieprzystępne 391 12.2. Wdrażanie usług z zastosowaniem wzorca usługi jako maszyny wirtualnej 391 12.2.1. Zalety wdrażania usług jako maszyn wirtualnych 393 Obraz maszyny wirtualnej hermetyzuje stos techniczny 393 Instancje usług są izolowane 393 użycie wyrafinowanej infrastruktury chmurowej 393 12.2.2. Wady wdrażania usług jako sprzętów 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 przy pomocy wzorca usługi jako kontenera 394 12.3.1. Wdrażanie usług przy pomocy Dockera 396 Budowanie obrazu Dockera 397 Wysyłanie obrazu Dockera do rejestru 398 Uruchamianie kontenera Dockera 398 12.3.2. Atuty 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 przy pomocy 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. Wykorzystanie 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 przy pomocy 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 poprzez usługi AWS 419 Definiowanie zaplanowanych funkcji lambda 419 powodowanie funkcji lambda za pomocą żądania usługi sieciowej 419 12.5.4. Zalety zastosowania funkcji lambda 420 12.5.5. Wady zastosowania funkcji lambda 420 12.6. Wdrażanie usługi RESTful z zastosowaniem AWS Lambda i AWS Gateway 421 12.6.1. Projekt AWS Lambda wersji Restaurant Service 421 Klasa FindRestaurantRequestHandler 423 Wstrzykiwanie zależności z wykorzystaniem 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 wszelkiego 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 informacji 441 Replikowanie informacji 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, żeby 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 danych 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 informacje 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 informacji 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