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.

Osoby które kupowały "Mikroserwisy. Wzorce z przykładami w języku Java", wybierały także:

• Wprowadzenie do Javy. Programowanie i struktury danych. Wydanie XII 193,23 zł, (59,90 zł -69%)
• Spring i Spring Boot. Kurs video. Testowanie aplikacji i bezpiecze 129,00 zł, (51,60 zł -60%)
• Metoda dziel i zwyci 89,00 zł, (35,60 zł -60%)
• JavaFX. Kurs video. Wzorce oraz typy generyczne 79,00 zł, (31,60 zł -60%)
• Platforma Xamarin. Kurs video. Poziom drugi. Zaawansowane techniki tworzenia aplikacji cross-platform 99,00 zł, (39,60 zł -60%)

Spis treści

Mikroserwisy. Wzorce z przykładami w języku Java eBook -- spis treści

• Okładka
• Strona tytułowa
• Strona redakcyjna
• Spis treści
• przedmowa
• podziękowania
• o książce
• o autorze
• o ilustracji na okładce
• 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
      • Rozwój jest powolny
      • Ścieżka od zatwierdzenia do wdrożenia jest długa i mozolna
      • Skalowanie jest trudne
      • 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
      • Lepsza izolacja błędów
      • Ł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
• Przypisy