Читать книгу Mikroserwisy. Wzorce z przykładami w języku Java - Chris Richardson - Страница 5
Spis treści
Оглавление1. Ucieczka z monolitycznego piekła
1.1. Powolny marsz w kierunku monolitycznego piekła
1.1.1. Architektura aplikacji FTGO
1.1.2. Zalety architektury monolitycznej
1.1.3. Życie w monolitycznym piekle
Kompleksowość przeraża deweloperów
Ścieżka od zatwierdzenia do wdrożenia jest długa i mozolna
Dostarczanie niezawodnego monolitu jest wyzwaniem
Blokada w coraz bardziej przestarzałym stosie technologicznym
1.2. Dlaczego ta książka jest dla ciebie odpowiednia
1.3. Czego się nauczysz z tej książki?
1.4. Architektura mikroserwisowa na ratunek
1.4.1. Sześcian skal i mikroserwisy
Skalowanie w osi X równoważy obciążenia dotyczące żądań między wiele instancji
Skalowanie w osi Z trasuje żądania na podstawie atrybutu żądania
Skalowanie w osi Y funkcjonalnie rozkłada aplikację na usługi
1.4.2. Mikroserwisy jako forma modułowości
1.4.3. Każda usługa ma własną bazę danych
1.4.4. Architektura mikroserwisowa FTGO
1.4.5. Porównanie architektury mikroserwisowej i SOA
1.5. Zalety i wady architektury mikroserwisowej
1.5.1. Zalety architektury mikroserwisowej
Umożliwianie ciągłego dostarczania i wdrażania dużych, złożonych aplikacji
Każda usługa jest mała i łatwa w utrzymaniu
Usługi są niezależnie skalowalne
Łatwe eksperymentowanie i wdrażanie nowych technologii
1.5.2. Wady architektury mikroserwisowej
Znalezienie odpowiednich usług jest trudne
Systemy rozproszone są złożone
Wdrażanie funkcjonalności obejmujących wiele usług wymaga starannej koordynacji
Decyzja o przyjęciu jest trudna
1.6. Język wzorców architektury mikroserwisowej
1.6.1. Architektura mikroserwisowa nie jest złotym środkiem
1.6.2. Wzorce i języki wzorców
Wzorce powiązane: pięć różnych rodzajów relacji
1.6.3. Omówienie języka wzorców architektury mikroserwisowej
Wzorce do dekompozycji aplikacji na usługi
Wzorce komunikacyjne
Wzorce spójności danych do wdrażania zarządzania transakcjami
Wzorce odpytywania danych w architekturze mikroserwisowej
Wzorce wdrażania usług
Wzorce obserwowalności zapewniają wgląd w zachowanie aplikacji
Wzorce automatycznego testowania usług
Wzorce do obsługi potrzeb przekrojowych
Wzorce bezpieczeństwa
1.7. Poza mikroserwisy: proces i organizacja
1.7.1. Tworzenie oprogramowania i organizacja dostarczania
1.7.2. Proces tworzenia i dostarczania oprogramowania
1.7.3. Ludzka strona wprowadzania mikroserwisów
2. Strategie dekompozycyjne
2.1. Czym dokładnie jest architektura mikroserwisowa?
2.1.1. Czym jest architektura oprogramowania i dlaczego ma ona znaczenie?
Definicja architektury oprogramowania
Model perspektyw „4+1” w architekturze oprogramowania
Dlaczego architektura jest ważna
2.1.2. Przegląd stylów architektonicznych
Styl: architektura warstwowa
Styl: architektura heksagonalna
2.1.3. Architektura mikroserwisowa jest stylem architektonicznym
Co to jest usługa?
Czym są luźne powiązania?
Rola współdzielonych bibliotek
Rozmiar usługi jest w zasadzie nieważny
2.2. Definiowanie architektury mikroserwisowej aplikacji
2.2.1. Identyfikowanie operacji systemu
Tworzenie wysokopoziomowego modelu domeny
Definiowanie operacji systemu
2.2.2. Definiowanie usług z zastosowaniem wzorca dekompozycji według zdolności biznesowych
Zdolności biznesowe określają, co robi organizacja
Identyfikowanie zdolności biznesowych
Od zdolności biznesowych do usług
2.2.3. Definiowanie usług z zastosowaniem dekompozycji według wzorca subdomeny
2.2.4. Wytyczne dotyczące dekompozycji
Zasada pojedynczej odpowiedzialności
Reguła wspólnego domknięcia
2.2.5. Przeszkody w dekompozycji aplikacji na usługi
Opóźnienia sieciowe
Synchroniczna komunikacja międzyprocesowa ogranicza dostępność
Utrzymanie spójności danych w usługach
Uzyskanie spójnego widoku danych
Dekompozycję utrudniają god classes
2.2.6. Tworzenie API usług
Przypisywanie operacji systemu do usług
Określanie API wymaganego do realizowania współpracy między usługami
3. Komunikacja międzyprocesowa w architekturze mikroserwisowej
3.1. Przegląd komunikacji międzyprocesowej w architekturze mikroserwisowej
3.1.1. Style interakcji
3.1.2. Definiowanie API w architekturze mikroserwisowej
3.1.3. Ewolucja API
Użycie semantycznego wersjonowania
Wprowadzanie drobnych, kompatybilnych wstecznie zmian
Wprowadzanie istotnych zmian
3.1.4. Formaty komunikatów
Tekstowe formaty komunikatów
Binarne formaty komunikatów
3.2. Komunikacja z użyciem wzorca synchronicznego zdalnego wywołania procedury
3.2.1. Korzystanie z REST
Model dojrzałości REST
Specyfikowanie REST API
Wyzwania związane z pobieraniem wielu zasobów w jednym żądaniu
Wyzwania związane z mapowaniem operacji na czasowniki HTTP
Zalety i wady REST
3.2.2. Korzystanie z gRPC
3.2.3. Postępowanie w przypadku częściowej awarii z użyciem wzorca bezpiecznika
Tworzenie solidnych proxy RPI
Reagowanie na niedostępne usługi
3.2.4. Użycie wykrywania usług
Wykrywanie usług
Stosowanie wzorców wykrywania usług na poziomie aplikacji
Stosowanie wzorców wykrywania usług na poziomie platformy
3.3. Komunikacja z użyciem wzorca asynchronicznego przesyłania komunikatów
3.3.1. Spojrzenie na przesyłanie komunikatów
O komunikatach
O kanałach komunikatów
3.3.2. Realizacja stylów interakcji za pomocą przesyłania komunikatów
Realizacja żądanie/odpowiedź i asynchroniczne żądanie/odpowiedź
Realizacja powiadomień jednokierunkowych
Realizacja publikuj/subskrybuj
Realizacja publikowanie/asynchroniczna odpowiedź
3.3.3. Tworzenie specyfikacji dla API usługi opartego na przesyłaniu komunikatów
Dokumentowanie operacji asynchronicznych
Dokumentowanie publikowanych zdarzeń
3.3.4. Użycie brokera komunikatów
Przesyłanie komunikatów bez brokera
Przesyłanie komunikatów oparte na brokerze
Realizacja kanałów komunikatów za pomocą brokera
Zalety i wady przesyłania komunikatów przez brokerów
3.3.5. Konkurujący odbiorcy i sortowanie komunikatów
3.3.6. Obsługa zduplikowanych komunikatów
Tworzenie idempotentnej obsługi komunikatów
Śledzenie komunikatów i odrzucanie duplikatów
3.3.7. Komunikaty transakcyjne
Użycie tabeli bazy danych jako kolejki komunikatów
Publikowanie zdarzeń z użyciem wzorca publikatora z przeszukiwaniem
Publikowanie zdarzeń z zastosowaniem wzorca śledzenie dziennika transakcji
3.3.8. Biblioteki i frameworki do przesyłania komunikatów
Proste przesyłanie komunikatów
Publikowanie zdarzeń domenowych
Przesyłanie komunikatów oparte na poleceniu/odpowiedzi
3.4. Użycie asynchronicznego przesyłania komunikatów w celu poprawy dostępności
3.4.1. Komunikacja synchroniczna zmniejsza dostępność
3.4.2. Eliminowanie interakcji synchronicznych
Użycie asynchronicznych stylów interakcji
Replikacja danych
Zakończenie przetwarzania po zwróceniu odpowiedzi
4. Zarządzanie transakcjami z użyciem sag
4.1. Zarządzanie transakcjami w architekturze mikroserwisowej
4.1.1. Potrzeba transakcji rozproszonych w architekturze mikroserwisowej
4.1.2. Problem z rozproszonymi transakcjami
4.1.3. Użycie wzorca sagi do zarządzania spójnością danych
Przykładowa saga: Create Order Saga
Do wycofania zmian sagi wykorzystują transakcje kompensujące
4.2. Koordynowanie sag
4.2.1. Sagi oparte na choreografii
Realizacja Create Order Saga z wykorzystaniem choreografii
Niezawodna komunikacja oparta na zdarzeniach
Zalety i wady sag opartych na choreografii
4.2.2. Sagi oparte na orkiestracji
Realizacja Create Order Saga z wykorzystaniem orkiestracji
Modelowanie orkiestratorów sagi jako maszyn stanów
Orkiestracja sagi i komunikaty transakcyjne
Zalety i wady sag opartych na orkiestracji
4.3. Radzenie sobie z brakiem izolacji
4.3.1. Przegląd anomalii
Utracone aktualizacje
Brudne odczyty
4.3.2. Przeciwdziałania związane z brakiem izolacji
Struktura sagi
Blokada semantyczna
Aktualizacje przemienne
Podejście pesymistyczne
Ponowne odczytanie wartości
Rejestr kroków
Według korzyści
4.4. Projekt usługi Order Service i sagi Create Order Saga
4.4.1. Klasa OrderService
4.4.2. Implementacja Create Order Saga
Orkiestrator CreateOrderSaga
Klasa CreateOrderSagaState
Klasa KitchenServiceProxy
Framework Eventuate Tram Saga
4.4.3. Klasa OrderCommandHandlers
4.4.4. Klasa OrderServiceConfiguration
5. Projektowanie logiki biznesowej w architekturze mikroserwisowej
5.1. Wzorce organizacji logiki biznesowej
5.1.1. Projektowanie logiki biznesowej z użyciem wzorca skryptu transakcji
5.1.2. Projektowanie logiki biznesowej z użyciem wzorca modelu domeny
5.1.3. Domain-Driven Design
5.2. Projektowanie modelu domeny z użyciem wzorca agregatu DDD
5.2.1. Problem z rozmytymi granicami
5.2.2. Agregaty mają wyraźne granice
Agregaty są granicami spójności
Kluczowa jest identyfikacja agregatów
5.2.3. Zasady agregatów
Zasada 1: Odniesienie tylko do korzenia agregatu
Zasada 2: Odniesienia między agregatami muszą korzystać z kluczy głównych
Zasada 3: Jedna transakcja tworzy lub aktualizuje jeden agregat
5.2.4. Ziarnistość agregatu
5.2.5. Projektowanie logiki biznesowej z agregatami
5.3. Publikowanie zdarzeń domenowych
5.3.1. Dlaczego publikować zdarzenia związane ze zmianą stanu?
5.3.2. Czym jest zdarzenie domenowe?
5.3.3. Wzbogacanie zdarzeń
5.3.4. Identyfikowanie zdarzeń domenowych
5.3.5. Generowanie i publikowanie zdarzeń domenowych
Generowanie zdarzeń domenowych
Jak niezawodnie publikować zdarzenia domenowe?
5.3.6. Pobieranie zdarzeń domenowych
5.4. Logika biznesowa Kitchen Service
5.4.1. Agregat Ticket
Struktura klasy Ticket
Zachowanie agregatu Ticket
Usługa domenowa KitchenService
Klasa KitchenServiceCommandHandler
5.5. Logika biznesowa Order Service
5.5.1. Agregat Order
Struktura agregatu Order
Maszyna stanów agregatu Order
Metody agregatu Order
5.5.2. Klasa OrderService
6. Rozwijanie logiki biznesowej za pomocą pozyskiwania zdarzeń
6.1. Wykorzystywanie wzorca pozyskiwania zdarzeń do tworzenia logiki biznesowej
6.1.1. Problemy tradycyjnego utrwalania
Niedopasowanie między modelem obiektowym a relacyjnym
Brak historii agregatu
Wdrożenie dzienników zdarzeń jest uciążliwe i podatne na błędy
Publikowanie zdarzeń jest powiązane z logiką biznesową
6.1.2. Pozyskiwanie zdarzeń
Pozyskiwanie zdarzeń utrwala agregaty korzystając ze zdarzeń
Zdarzenia reprezentują zmiany stanu
Metody agregatów dotyczą zdarzeń
Agregat Order wykorzystujący pozyskiwanie zdarzeń
6.1.3. Obsługa jednoczesnych aktualizacji z użyciem optymistycznego blokowania
6.1.4. Pozyskiwanie zdarzeń i publikowanie zdarzeń
Użycie przeszukiwania do publikowania zdarzeń
Wykorzystanie śledzenia dziennika transakcji do niezawodnego publikowania zdarzeń
6.1.5. Użycie migawek do poprawy wydajności
6.1.6. Idempotentne przetwarzanie komunikatów
Idempotentne przetwarzanie komunikatów z magazynem zdarzeń opartym na RDBMS
Idempotentne przetwarzanie komunikatów z magazynem zdarzeń opartym na NoSQL
6.1.7. Rozwój zdarzeń domenowych
Ewolucja schematu zdarzeń
Zarządzanie zmianami schematu przez rzutowanie w górę
6.1.8. Zalety pozyskiwania zdarzeń
Niezawodnie publikowanie zdarzeń domenowych
Zachowywanie historii agregatów
Zwykle pomaga uniknąć problemu niedopasowania między modelem relacyjnym a obiektowym
Oferuje programistom maszynę czasu
6.1.9. Wady pozyskiwania zdarzeń
Inny model programowania powodujący wzrost krzywej uczenia się
Złożoność aplikacji opartej na przesyłaniu komunikatów
Ewolucja zdarzeń może być trudna
Usuwanie danych jest trudne
Wykonywanie zapytań do magazynu zdarzeń jest trudne
6.2. Implementowanie magazynu zdarzeń
6.2.1. Jak działa magazyn zdarzeń Eventuate Local
Schemat bazy danych zdarzeń Eventuate Local
Pobieranie zdarzeń przez subskrybowanie brokera zdarzeń Eventuate Local
Przekaźnik zdarzeń Eventuate Local propaguje zdarzenia z bazy danych do brokera komunikatów
6.2.2. Środowisko klienta Eventuate dla Javy
Definiowanie agregatów za pomocą klasy ReflectiveMutableCommandProcessingAggregate
Definiowanie poleceń agregatu
Definiowanie zdarzeń domenowych
Tworzenie, wyszukiwanie i aktualizacja agregatów za pomocą klasy AggregateRepository
Subskrybowanie zdarzeń domenowych
6.3. Łączne używanie sag i pozyskiwania zdarzeń
6.3.1. Realizacja sag opartych na choreografii z wykorzystaniem pozyskiwania zdarzeń
6.3.2. Tworzenie sagi opartej na orkiestracji
Tworzenie orkiestratora sagi podczas korzystania z magazynu zdarzeń opartego na RDMBS
Tworzenie orkiestratora sagi podczas korzystania z magazynu zdarzeń opartego na NoSQL
6.3.3. Tworzenie uczestnika sagi opartej na pozyskiwaniu zdarzeń
Idempotentna obsługa komunikatów poleceń
Atomowe wysyłanie komunikatów zwrotnych
Przykład uczestnika sagi opartej na pozyskiwaniu zdarzeń
6.3.4. Projektowanie orkiestratorów sagi z użyciem pozyskiwania zdarzeń
Utrzymywanie orkiestratora sagi z użyciem pozyskiwania zdarzeń
Niezawodne wysyłanie komunikatów poleceń
Dokładnie jednokrotne przetwarzanie odpowiedzi
7. Implementowanie zapytań w architekturze mikroserwisowej
7.1. Tworzenie zapytań z użyciem wzorca kompozycji API
7.1.1. Operacja zapytania findOrder()
7.1.2. Wzorzec kompozycji API
7.1.3. Implementowanie operacji zapytania findOrder() z wykorzystaniem wzorca kompozycji API
7.1.4. Problemy projektowe związane z wzorcem kompozycji API
Kto powinien odgrywać rolę API Composer?
7.1.5. Wady i zalety wzorca kompozycji API
Zwiększone koszty ogólne
Brak spójności danych transakcyjnych
7.2. Korzystanie z wzorca CQRS
7.2.1. Motywacja do korzystania z CQRS
Realizacja operacji zapytania findOrderHistory()
Wymagające zapytanie dotyczące pojedynczej usługi: findAvailableRestaurants()
Konieczność oddzielenia obowiązków
7.2.2. Przegląd CQRS
CQRS oddziela polecenia od zapytań
CQRS i usługi tylko dla zapytań
7.2.3. Zalety CQRS
7.2.4. Wady CQRS
Bardziej złożona architektura
Konieczność radzenia sobie z opóźnieniem replikacji
7.3. Projektowanie widoków CQRS
7.3.1. Wybór magazynu danych widoku
Bazy danych SQL kontra NoSQL
Wspieranie operacji aktualizacji
7.3.2. Projekt modułu dostępu do danych
Obsługa jednoczesnych aktualizacji
Idempotentne procedury obsługi zdarzeń
Umożliwienie aplikacji klienckiej korzystania z ostatecznie spójnego widoku
7.3.3. Dodawanie i aktualizacja widoków CQRS
Budowanie widoków CQRS z użyciem zarchiwizowanych zdarzeń
Stopniowe budowanie widoków CQRS
7.4. Implementowanie widoku CQRS za pomocą AWS DynamoDB
7.4.1. Moduł OrderHistoryEventHandlers
7.4.2. Modelowanie danych i projektowanie zapytań za pomocą DynamoDB
Projektowanie tabeli ftgo-order-history
Zdefiniowanie indeksu dla zapytania findOrderHistory
Realizacja zapytania findOrderHistory
Stronicowanie wyników zapytania
Aktualizowanie zamówień
Wykrywanie zduplikowanych zdarzeń
7.4.3. Klasa OrderHistoryDaoDynamoDb
Metoda addOrder()
Metoda notePickedUp()
Metoda idempotentUpdate()
Metoda findOrderHistory()
8. Wzorce zewnętrznych API
8.1. Problemy z projektowaniem zewnętrznego API
8.1.1. Problemy z projektowaniem API dla mobilnego klienta FTGO
Gorszy komfort użytkowania spowodowany klientem wykonującym wiele zapytań
Brak enkapsulacji wymaga od programistów frontendu, aby zmieniali swój kod krok w krok ze zmianami w backendzie
Usługi mogą wykorzystywać mechanizmy IPC nieprzyjazne dla klientów
8.1.2. Problemy z projektowaniem API dla innych typów klientów
Problemy z projektowaniem API dla aplikacji webowych
Problemy z projektowaniem API dla aplikacji JavaScript działających w przeglądarce
Projektowanie API dla aplikacji zewnętrznych
8.2. Wzorzec bramy API
8.2.1. Wzorzec bramy API
Przekierowywanie żądań
Kompozycja API
Translacja protokołów
Brama API oferuje każdemu klientowi specyficzne API
Implementowanie funkcji brzegowych
Architektura bramy API
Model własności bramy API
Korzystanie z wzorca Backends for Frontends
8.2.2. Zalety i wady bramy API
Zalety bramy API
Wady bramy API
8.2.3. Netflix jako przykład bramy API
8.2.4. Problemy z projektowaniem bramy API
Wydajność i skalowalność
Użycie abstrakcji programowania reaktywnego
Postępowanie w przypadku częściowej awarii
Bycie dobrym obywatelem w architekturze aplikacji
8.3. Implementowanie bramy API
8.3.1. Skorzystanie z gotowego produktu/usługi bramy API
Brama API AWS
AWS Application Load Balancer
Użycie produktu typu brama API
8.3.2. Opracowanie własnej bramy API
Użycie Netflix Zuul
O Spring Cloud Gateway
Klasa OrderConfiguration
Klasa OrderHandlers
Klasa OrderService
Klasa ApiGatewayApplication
8.3.3. Realizacja bramy API za pomocą GraphQL
Definiowanie schematu GraphQL
Wykonywanie zapytań GraphQL
Podłączanie schematu do danych
Optymalizacja ładowania za pomocą grupowania i buforowania
Integracja serwera Apollo GraphQL z Expressem
Tworzenie klienta GraphQL
9. Testowanie mikroserwisów: część 1
9.1. Strategie testowania w architekturze mikroserwisowej
9.1.1. Testowanie
Pisanie testów automatycznych
Testowanie z użyciem obiektów typu mock i stub
Różne rodzaje testów
Wykorzystanie kwadrantu testowego do kategoryzacji testów
Wykorzystanie piramidy testów jako przewodnika w wysiłkach związanych z testowaniem
9.1.2. Wyzwania związane z testowaniem mikroserwisów
Test kontraktowy ukierunkowany na klienta
Testowanie usług z wykorzystaniem Spring Cloud Contract
Konsumenckie testy kontraktowe API przesyłania komunikatów
9.1.3. Strumień wdrażania
9.2. Pisanie testów jednostkowych dla usługi
9.2.1. Projektowanie testów jednostkowych dla encji
9.2.2. Pisanie testów jednostkowych dla obiektów wartości
9.2.3. Opracowywanie testów jednostkowych dla sag
9.2.4. Pisanie testów jednostkowych dla usług domenowych
9.2.5. Opracowywanie testów jednostkowych dla kontrolerów
9.2.6. Pisanie testów jednostkowych dla procedur obsługi zdarzeń i komunikatów
10. Testowanie mikroserwisów: część 2
10.1. Pisanie testów integracyjnych
10.1.1. Testy integracyjne trwałości
10.1.2. Testy integracyjne interakcji żądanie/odpowiedź opartej na REST
Przykładowy kontrakt dla API REST
Integracyjny test kontraktowy ukierunkowany na klienta dla Order Service
Test integracyjny po stronie konsumenta dla OrderServiceProxy z API Gateway
10.1.3. Testy integracyjne interakcji publikuj/subskrybuj
Kontrakt dla publikowania zdarzenia OrderCreated
Test kontraktowy ukierunkowany na konsumenta dla Order Service
Test kontraktowy po stronie konsumenta dla Order History Service
10.1.4. Kontraktowe testy integracyjne interakcji asynchroniczne żądanie/odpowiedź
Przykładowy kontrakt dla asynchronicznego żądania/odpowiedzi
Kontraktowy test integracyjny po stronie konsumenta dla interakcji asynchroniczne żądanie/odpowiedź
Pisanie testów kontraktowych po stronie dostawcy przeznaczonych do testowania konsumenta w zakresie asynchronicznej interakcji żądanie/odpowiedź
10.2. Tworzenie testów komponentów
10.2.1. Definiowanie testów akceptacyjnych
10.2.2. Pisanie testów akceptacyjnych z użyciem Gherkina
Wykonywanie specyfikacji Gherkina za pomocą Cucumber
10.2.3. Projektowanie testów komponentów
Wewnątrzprocesowe testy komponentów
Pozaprocesowe testowanie komponentu
Jak tworzyć obiekty stubs dla usług w pozaprocesowych testach komponentów
10.2.4. Pisanie testów komponentów dla Order Service z FTGO
Klasa OrderServiceComponentTestStepDefinitions
Uruchamianie testów komponentów
10.3. Pisanie testów end-to-end
10.3.1. Projektowanie testów end-to-end
10.3.2. Pisanie testów end-to-end
10.3.3. Uruchamianie testów end-to-end
11. Opracowywanie usług gotowych do produkcji
11.1. Opracowywanie bezpiecznych usług
11.1.1. Przegląd kwestii bezpieczeństwa w tradycyjnej aplikacji monolitycznej
11.1.2. Realizacja kwestii bezpieczeństwa w architekturze mikroserwisowej
Obsługa uwierzytelniania w bramie API
Obsługa autoryzacji
Użycie JWT do przekazywania tożsamości użytkownika i roli
Użycie OAuth 2.0 w architekturze mikroserwisowej
11.2. Projektowanie konfigurowalnych usług
11.2.1. Użycie konfiguracji zewnętrznej opartej na udostępnianiu
11.2.2. Użycie konfiguracji zewnętrznej opartej na pobieraniu
11.3. Projektowanie obserwowalnych usług
11.3.1. Użycie wzorca API kontroli działania
Realizacja punktu końcowego kontroli działania
Wywołanie punktu końcowego kontroli działania
11.3.2. Stosowanie wzorca agregacji dzienników
W jaki sposób usługa generuje dziennik
Infrastruktura agregacji dzienników
11.3.3. Stosowanie wzorca rozproszonego śledzenia
Użycie biblioteki instrumentacji
Serwer rozproszonego śledzenia
11.3.4. Stosowanie wzorca metryk aplikacji
Zbieranie metryk na poziomie usługi
Dostarczanie metryk do usługi metryk
11.3.5. Stosowanie wzorca śledzenia wyjątków
11.3.6. Stosowanie wzorca dzienników inspekcji
Dodawanie kodu dzienników inspekcji do logiki biznesowej
Użycie programowania aspektowego
Użycie pozyskiwania zdarzeń
11.4. Tworzenie usług za pomocą wzorca szkieletów mikroserwisowych
11.4.1. Korzystanie ze szkieletu mikroserwisowego
11.4.2. Od szkieletu mikroserwisowego do service mesh
12. Wdrażanie mikroserwisów
12.1. Wdrażanie usług jako pakietów specyficznych dla języka
12.1.1. Zalety wzorca Usługa jako pakiet specyficzny dla języka
Szybkie wdrażanie
Efektywne wykorzystanie zasobów
12.1.2. Wady wzorca Usługa jako pakiet specyficzny dla języka
Brak enkapsulacji stosu technologicznego
Brak możliwości ograniczenia zasobów zużywanych przez instancję usługi
Brak izolacji podczas uruchamiania wielu instancji usługi na tej samej maszynie
Automatyczne określenie miejsca umieszczenia instancji usługi jest trudne
12.2. Wdrażanie usług z użyciem wzorca usługi jako maszyny wirtualnej
12.2.1. Zalety wdrażania usług jako maszyn wirtualnych
Obraz maszyny wirtualnej hermetyzuje stos technologiczny
Instancje usług są izolowane
Wykorzystanie wyrafinowanej infrastruktury chmurowej
12.2.2. Wady wdrażania usług jako maszyn wirtualnych
Mniej wydajne wykorzystanie zasobów
Wolne wdrożenia
Narzut związany z administracją systemem
12.3. Wdrażanie usług za pomocą wzorca usługi jako kontenera
12.3.1. Wdrażanie usług za pomocą Dockera
Budowanie obrazu Dockera
Wysyłanie obrazu Dockera do rejestru
Uruchamianie kontenera Dockera
12.3.2. Zalety wdrażania usług jako kontenerów
12.3.3. Wady wdrażania usług jako kontenerów
12.4. Wdrażanie aplikacji FTGO za pomocą Kubernetesa
12.4.1. Kubernetes
Architektura Kubernetesa
Kluczowe pojęcia Kubernetesa
12.4.2. Wdrażanie Restaurant Service w Kubernetesie
Tworzenie service w Kubernetesie
Wdrażanie bramy API
12.4.3. Wdrożenia bez przestojów
12.4.4. Użycie service mesh w celu oddzielenia wdrożenia od wydania
Service mesh Istio
Wdrażanie usługi za pomocą Istio
Tworzenie reguł routingu do wersji v1
Wdrażanie wersji 2 Consumer Service
Przekierowywanie części testowego ruchu do wersji 2
Kierowanie produkcyjnego ruchu do wersji 2
12.5. Wdrażanie usług za pomocą wzorca wdrożenia bezserwerowego
12.5.1. Bezserwerowe wdrażanie za pomocą AWS Lambda
12.5.2. Tworzenie funkcji lambda
12.5.3. Wywoływanie funkcji lambda
Obsługa żądań HTTP
Obsługa zdarzeń generowanych przez usługi AWS
Definiowanie zaplanowanych funkcji lambda
Wywoływanie funkcji lambda za pomocą żądania usługi sieciowej
12.5.4. Zalety użycia funkcji lambda
12.5.5. Wady użycia funkcji lambda
12.6. Wdrażanie usługi RESTful z użyciem AWS Lambda i AWS Gateway
12.6.1. Projekt AWS Lambda wersji Restaurant Service
Klasa FindRestaurantRequestHandler
Wstrzykiwanie zależności z użyciem klasy AbstractAutowiringHttpRequestHandler
Klasa AbstractHttpHandler
12.6.2. Pakowanie usługi jako pliku ZIP
12.6.3. Wdrażanie funkcji lambda z użyciem frameworka Serverless
13. Refaktoryzacja do mikroserwisów
13.1. Refaktoryzacja do mikroserwisów
13.1.1. Dlaczego warto refaktoryzować monolit?
13.1.2. Duszenie monolitu
Szybkie i częste prezentowanie wartości dodanej
Minimalizacja zmian w monolicie
Techniczne aspekty infrastruktury wdrożeniowej: nie potrzebujemy wszystkiego od razu
13.2. Strategie refaktoryzacji monolitu do mikroserwisów
13.2.1. Realizacja nowych funkcjonalności jako usług
Integracja nowej usługi z monolitem
Kiedy zaimplementować nową funkcjonalność jako usługę
13.2.2. Oddzielanie warstwy prezentacji od backendu
13.2.3. Wyodrębnianie zdolności biznesowych do usług
Podział modelu domeny
Refaktoryzacja bazy danych
Replikowanie danych w celu uniknięcia rozległych zmian
Jakie usługi wyodrębniać i kiedy
13.3. Projektowanie, w jaki sposób usługa i monolit będą współpracować
13.3.1. Projektowanie kodu integrującego
Projektowanie API kodu integrującego
Wybór stylu interakcji i mechanizmu IPC
Projektowanie Anti-Corruption Layer
Jak monolit publikuje i subskrybuje zdarzenia domenowe
13.3.2. Utrzymywanie spójności danych w usłudze i monolicie
Wyzwanie związane ze zmianą monolitu, aby wspierał transakcje kompensujące
Sagi nie zawsze wymagają od monolitu wspierania transakcji kompensujących
Określanie kolejności wyodrębniania usług w celu uniknięcia konieczności implementacji transakcji kompensujących w monolicie
13.3.3. Obsługa uwierzytelniania i autoryzacji
LoginHandler monolitu ustawia plik cookie USERINFO
Brama API mapuje plik cookie USERINFO na nagłówek Authorization
13.4. Wdrażanie nowej funkcjonalności jako usługi: obsługa niezrealizowanych zamówień
13.4.1. Projekt Delayed Delivery Service
13.4.2. Projektowanie kodu integrującego dla Delayed Delivery Service
Pobieranie informacji kontaktowych klienta z wykorzystaniem CustomerContactInfoRepository
Publikowanie i pobieranie zdarzeń domenowych Order i Restaurant
13.5. Rozbijanie monolitu: wyodrębnianie zarządzania dostawami
13.5.1. Przegląd istniejącej funkcjonalności związanej z zarządzaniem dostawami
13.5.2. Przegląd Delivery Service
13.5.3. Projekt modelu domeny Delivery Service
Określenie encji i ich pól, które są częścią zarządzania dostawami
Decydowanie, które dane przenieść do Delivery Service
Projekt logiki domeny Delivery Service
13.5.4. Projekt kodu integrującego Delivery Service
Projekt API Delivery Service
W jaki sposób Delivery Service będzie uzyskiwał dostęp do danych monolitu FTGO
W jaki sposób monolit FTGO będzie uzyskiwał dostęp do danych Delivery Service?
13.5.5. Dostosowanie monolitu FTGO do współpracy z Delivery Service
Definiowanie interfejsu DeliveryService
Refaktoryzacja monolitu w celu wywoływania interfejsu DeliveryService
Implementacja interfejsu DeliveryService
Przełączanie funkcjonalności
