Zainwestuj swój czas w projektowanie doskonałych aplikacji, ulepszanie infrastruktury i maksymalne wykorzystanie swoich zespołów. Mikroserwisy są łatwiejsze do napisania, skalowania i utrzymania niż tradycyjne aplikacje korporacyjne, ponieważ są budowane jako system niezależnych komponentów. Wystarczy, że opanujesz kilka ważnych nowych wzorców i procesów, a będziesz gotowy do opracowywania, wdrażania i uruchamiania mikroserwisów o jakości produkcyjnej. "Mikroserwisy w akcji" uczą, jak pisać i utrzymywać aplikacje oparte na mikroserwisach. Ten przewodnik stworzony z myślą o codziennym rozwoju, zagłębi Cię w rzeczywiste przypadki użycia, od projektu po wdrożenie. Dowiesz się, w jaki sposób mikroserwisy umożliwiają stworzenie efektywnego strumienia ciągłego dostarczania oraz zbadasz przykłady z użyciem Kubernetesa, Dockera i Google Container Engine. Książka przedstawia: Przegląd architektury mikroserwisowej Budowanie strumienia dostarczania Przedstawienie dobrych praktyk w projektowaniu transakcji i zapytań dotyczących wielu usług Wdrażanie z użyciem kontenerów Monitorowanie mikroserwisów Książka napisana dla średnio zaawansowanych programistów znających architekturę korporacyjną i platformy chmurowe, takie jak AWS i GCP.

Osoby które kupowały "Mikroserwisy w akcji", wybierały także:

• Zosta 149,00 zł, (44,70 zł -70%)
• Metoda dziel i zwyci 89,00 zł, (26,70 zł -70%)
• Matematyka. Kurs video. Teoria dla programisty i data science 399,00 zł, (119,70 zł -70%)
• Design Thinking. Kurs video. My 129,00 zł, (38,70 zł -70%)
• Konwolucyjne sieci neuronowe. Kurs video. Tensorflow i Keras w rozpoznawaniu obraz 149,00 zł, (44,70 zł -70%)

Spis treści

Mikroserwisy w akcji eBook -- spis treści

• Okładka
• Strona tytułowa
• Strona redakcyjna
• Spis treści
• Przedmowa
• Podziękowania
• O książce
• O autorach
• O ilustracji na okładce
• Część 1 . Stan rzeczy
  • 1 . Projektowanie i uruchamianie mikroserwisów
    • 1.1. Czym jest aplikacja mikroserwisowa?
      • 1.1.1. Skalowanie przez dekompozycję
      • 1.1.2. Kluczowe zasady
      • 1.1.3. Kto używa mikroserwisów?
      • 1.1.4. Dlaczego mikroserwisy to dobry wybór?
    • 1.2. Co w mikroserwisach jest wyzwaniem?
      • 1.2.1. Wyzwania związane z projektowaniem
      • 1.2.2. Wyzwania związane z działaniem
    • 1.3. Cykl rozwojowy mikroserwisu
      • 1.3.1. Projektowanie mikroserwisów
      • 1.3.2. Wdrażanie mikroserwisów
      • 1.3.3. Obserwowanie mikroserwisów
    • 1.4. Odpowiedzialna i operacyjnie świadoma kultura inżynieryjna
  • 2 . Mikroserwisy w SimpleBanku
    • 2.1. Czym zajmuje się SimpleBank?
    • 2.2. Czy mikroserwisy są dobrym wyborem?
      • 2.2.1. Ryzyko i inercja w oprogramowaniu finansowym
      • 2.2.2. Zmniejszanie tarć i zapewnienie wartości dodanej
    • 2.3. Budowanie nowej funkcjonalności
      • 2.3.1. Identyfikacja mikroserwisów przez modelowanie domeny
      • 2.3.2. Współpraca usług
      • 2.3.3. Choreografia usługi
    • 2.4. Udostępnianie usług na zewnątrz
    • 2.5. Wdrażanie funkcjonalności na produkcję
      • 2.5.1. Kontrolowane pod względem jakości i zautomatyzowane wdrożenia
      • 2.5.2. Odporność
      • 2.5.3. Przejrzystość
    • 2.6. Skalowanie rozwoju mikroserwisów
      • 2.6.1. Techniczna różnorodność
      • 2.6.2. Izolacja
    • 2.7. Co dalej?
• Część 2 . Projekt
  • 3 . Architektura aplikacji mikroserwisowej
    • 3.1. Architektura jako całość
      • 3.1.1. Od monolitów do mikroserwisu
      • 3.1.2. Rola architekta
      • 3.1.3. Zasady architektoniczne
      • 3.1.4. Cztery warstwy aplikacji mikroserwisowej
    • 3.2. Platforma mikroserwisu
      • 3.2.1. Mapowanie platformy uruchomieniowej
    • 3.3. Usługi
      • 3.3.1. Zdolności
      • 3.3.2. Agregacja i usługi wyższego szczebla
      • 3.3.3. Ścieżki krytyczne i niekrytyczne
    • 3.4. Komunikacja
      • 3.4.1. Kiedy używać komunikatów synchronicznych
      • 3.4.2. Kiedy używać komunikatów asynchronicznych
      • 3.4.3. Wzorce komunikacji asynchronicznej
      • 3.4.4. Lokalizowanie innych usług
    • 3.5. Granica aplikacji
      • 3.5.1. Bramy API
      • 3.5.2. Backends for frontends
      • 3.5.3. Bramy consumer-driven
    • 3.6. Klienci
      • 3.6.1. Monolity frontendowe
      • 3.6.2. Mikrofrontendy
  • 4 . Projektowanie nowych funkcjonalności
    • 4.1. Nowa funkcjonalność w SimpleBanku
    • 4.2. Określanie zakresu według zdolności biznesowych
      • 4.2.1. Zdolności i modelowanie domeny
      • 4.2.2. Tworzenie strategii inwestycyjnej
      • 4.2.3. Zagnieżdżone konteksty i usługi
      • 4.2.4. Wyzwania i ograniczenia
    • 4.3. Określanie zakresu według przypadków użycia
      • 4.3.1. Składanie zleceń związanych ze strategią inwestycyjną
      • 4.3.2. Działania i magazyny
      • 4.3.3. Orkiestracja i choreografia
    • 4.4. Ograniczanie zakresu według zmienności
    • 4.5. Zdolności techniczne
      • 4.5.1. Wysyłanie powiadomień
      • 4.5.2. Kiedy używać zdolności technicznych
    • 4.6. Postępowanie z niejednoznacznością
      • 4.6.1. Zacznijmy od gruboziarnistych usług
      • 4.6.2. Przygotujmy się na przyszłą dekompozycję
      • 4.6.3. Wycofywanie i migracja
    • 4.7. Własność usług w firmach
  • 5 . Transakcje i zapytania w mikroserwisach
    • 5.1. Spójne transakcje w aplikacjach rozproszonych
      • 5.1.1. Dlaczego nie użyć transakcji rozproszonych?
    • 5.2. Komunikacja oparta na zdarzeniach
      • 5.2.1. Zdarzenia i choreografia
    • 5.3. Sagi
      • 5.3.1. Choreografowane sagi
      • 5.3.2. Orkiestrowane sagi
      • 5.3.3. Przeplatane sagi
      • 5.3.4. Wzorce spójności
      • 5.3.5. Event sourcing
    • 5.4. Zapytania w rozproszonym świecie
      • 5.4.1. Przechowywanie kopii danych
      • 5.4.2. Oddzielanie zapytań i poleceń
      • 5.4.3. Wyzwania związane z CQRS
      • 5.4.4. Analizy i raportowanie
    • 5.5. Literatura uzupełniająca
  • 6 . Projektowanie niezawodnych usług
    • 6.1. Definiowanie niezawodności
    • 6.2. Co może pójść źle?
      • 6.2.1. Źródła awarii
      • 6.2.2. Awarie kaskadowe
    • 6.3. Projektowanie niezawodnej komunikacji
      • 6.3.1. Ponowne próby
      • 6.3.2. Plany awaryjne
      • 6.3.3. Przeterminowania
      • 6.3.4. Bezpieczniki
      • 6.3.5. Komunikacja asynchroniczna
    • 6.4. Maksymalizacja niezawodności usługi
      • 6.4.1. Równoważenie obciążenia i stan usługi
      • 6.4.2. Limity użycia
      • 6.4.3. Walidacja niezawodności i odporność na błędy
    • 6.5. Bezpieczeństwo przede wszystkim
      • 6.5.1. Frameworki
      • 6.5.2. Service mesh
  • 7 . Budowanie uniwersalnego frameworka mikroserwisowego
    • 7.1. Szkielet mikroserwisu
    • 7.2. Jaki jest cel szkieletu mikroserwisu?
      • 7.2.1. Zmniejszone ryzyko
      • 7.2.2. Szybsze rozpoczynanie
    • 7.3. Projektowanie szkieletu
      • 7.3.1. Wykrywanie usług
      • 7.3.2. Obserwowalność
      • 7.3.3. Równoważenie i limitowanie
    • 7.4. Badanie funkcjonalności zaimplementowanych z użyciem szkieletu
    • 7.5. Czy heterogeniczność nie była jedną z obietnic mikroserwisów?
• Część 3 . Wdrażanie
  • 8 . Wdrażanie mikroserwisów
    • 8.1. Dlaczego wdrożenie jest ważne?
      • 8.1.1. Stabilność i dostępność
    • 8.2. Środowisko produkcyjne mikroserwisów
      • 8.2.1. Cechy środowiska produkcyjnego mikroserwisów
      • 8.2.2. Automatyzacja i szybkość
    • 8.3. Wdrażanie usługi, szybka ścieżka
      • 8.3.1. Uruchomienie usługi
      • 8.3.2. Budowanie maszyny wirtualnej
      • 8.3.3. Uruchamianie wielu instancji usługi
      • 8.3.4. Dodawanie równoważenia obciążenia
      • 8.3.5. Czego się nauczyliśmy?
    • 8.4. Budowanie artefaktów usługi
      • 8.4.1. Co jest w artefakcie?
      • 8.4.2. Niezmienialność
      • 8.4.3. Typy artefaktów usługi
      • 8.4.4. Konfiguracja
    • 8.5. Modele hostowania usług
      • 8.5.1. Jedna usługa per host
      • 8.5.2. Wiele statycznych usług per host
      • 8.5.3. Wiele zarządzanych usług per host
    • 8.6. Wdrażanie usług bez przestojów
      • 8.6.1. Wdrożenia kanarkowe i rolling deploy w GCE
  • 9 . Wdrażanie z użyciem kontenerów i programów zarządczych
    • 9.1. Konteneryzowanie usługi
      • 9.1.1. Praca z obrazami
      • 9.1.2. Budowanie naszego obrazu
      • 9.1.3. Uruchamianie kontenerów
      • 9.1.4. Przechowywanie obrazu
    • 9.2. Wdrażanie do klastra
      • 9.2.1. Projektowanie i uruchamianie kapsuł
      • 9.2.2. Równoważenie obciążenia
      • 9.2.3. Krótkie spojrzenie pod maskę
      • 9.2.4. Kontrole działania
      • 9.2.5. Wdrażanie nowej wersji
      • 9.2.6. Wycofywanie
      • 9.2.7. Łączenie wielu usług
  • 10 . Budowanie strumienia dostarczania dla mikroserwisów
    • 10.1. Nudne wdrażanie
      • 10.1.1. Strumień wdrażania
    • 10.2. Budowanie strumienia w Jenkinsie
      • 10.2.1. Konfigurowanie strumienia budowania
      • 10.2.2. Budowanie obrazu
      • 10.2.3. Uruchamianie testów
      • 10.2.4. Publikowanie artefaktów
      • 10.2.5. Wdrażanie do środowiska staging
      • 10.2.6. Środowiska staging
    • 10.2.7. Wdrażanie do produkcji
    • 10.3. Budowanie strumienia z krokami wielokrotnego zastosowania
      • 10.3.1. Proceduralne versus deklaratywne budowanie strumieni
    • 10.4. Techniki wdrażania o niskim oddziaływaniu i wydawanie funkcjonalności
      • 10.4.1. Dark launch
      • 10.4.2. Flagi funkcjonalności
• Część 4 . Obserwowalność i własność
  • 11 . Budowanie systemu monitorowania
    • 11.1. Kompleksowy stos monitorowania
      • 11.1.1. Dobry monitoring jest warstwowy
      • 11.1.2. Złote sygnały
      • 11.1.3. Typy metryk
      • 11.1.4. Rekomendowane praktyki
    • 11.2. Monitorowanie SimpleBanku za pomocą Prome
      • 11.2.1. Konfigurowanie infrastruktury zbierania metryk
      • 11.2.2. Zbieranie metryk dotyczących infrastruktury RabbitMQ
      • 11.2.3. Instrumentacja składania zleceń w SimpleBanku
      • 11.2.4. Konfigurowanie alarmów
    • 11.3. Ustawianie sensownych i praktycznych alarmów
      • 11.3.1. Kto potrzebuje wiedzieć, że coś nie działa?
      • 11.3.2. Objawy, nie przyczyny
    • 11.4. Obserwowanie całej aplikacji
  • 12 . Używanie dzienników i śladów do zrozumienia zachowania
    • 12.1. Zrozumienie zachowania między wieloma usługami
    • 12.2. Generowanie spójnych, uporządkowanych dzienników czytelnych dla człowieka
      • 12.2.1. Przydatne informacje do uwzględnienia we wpisach dziennika
      • 12.2.2. Struktura i czytelność
    • 12.3. Konfigurowanie infrastruktury logowania w SimpleBanku
      • 12.3.1. Rozwiązanie oparte na ELK i Fluentd
      • 12.3.2. Konfigurowanie systemu do rejestrowania
      • 12.3.3. Konfigurowanie tego, co będzie zbierane w dziennikach
      • 12.3.4. Znajdowanie igły w stogu siana
      • 12.3.5. Rejestrowanie właściwych informacji
    • 12.4. Śledzenie interakcji między usługami
      • 12.4.1. Korelowanie żądań: ślady i spany
      • 12.4.2. Konfigurowanie śledzenia w usługach
    • 12.5. Wizualizowanie śladów
  • 13 . Budowanie zespołów mikroserwisowych
    • 13.1. Budowanie efektywnych zespołów
      • 13.1.1. Prawo Conwaya
      • 13.1.2. Zasady efektywnych zespołów
    • 13.2. Modele zespołów
      • 13.2.1. Grupowanie funkcyjne
      • 13.2.2. Grupowanie przekrojowe
      • 13.2.3. Ustalanie granic zespołu
      • 13.2.4. Infrastruktura, platforma i produkt
      • 13.2.5. Kto jest pod telefonem?
      • 13.2.6. Dzielenie się wiedzą
    • 13.3. Zalecane praktyki dla zespołów mikroserwisowych
      • 13.3.1. Czynniki zmian w mikroserwisach
      • 13.3.2. Rola architektury
      • 13.3.3. Jednorodność a elastyczność techniczna
      • 13.3.4. Model otwartego oprogramowania
      • 13.3.5. Przeglądy projektu
      • 13.3.6. Żywa dokumentacja
      • 13.3.7. Odpowiadanie na pytania dotyczące aplikacji
    • 13.4. Dodatkowe materiały
  • Dodatek - Instalacja Jenkinsa w Minikubeie
• Przypisy