POLECAMY
Autor:
Wydawca:
Format:
epub, mobi
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.
Rok wydania | 2020 |
---|---|
Liczba stron | 504 |
Kategoria | Programowanie |
Wydawca | Wydawnictwo Naukowe PWN |
Tłumaczenie | Magdalena Rogulska, Mariusz Rogulski |
ISBN-13 | 978-83-01-21223-0 |
Numer wydania | 1 |
Język publikacji | polski |
Informacja o sprzedawcy | ePWN sp. z o.o. |
POLECAMY
Ciekawe propozycje
Wzorce osobowe w prawie karnym
do koszyka
Wzorce projektowe uczenia maszynowego
do koszyka
Wzorce zwyciężania
do koszyka
Wzorce zwyciężania
do koszyka
Gender w literaturze dla dzieci i...
do koszyka
Księga Scrum. Sprawdzone wzorce
do koszyka
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. Zalety architektury monolitycznej | 4 |
1.1.3. Życie w monolitycznym piekleKompleksowość 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ńPozyskiwanie 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. TestowaniePisanie 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 |