reklama - zainteresowany?

Mikroserwisy w akcji - Helion

Mikroserwisy w akcji
ebook
Autor: Morgan Bruce, Paulo A. Pereira
Tłumaczenie: Anna Rogulska, Mariusz Rogulski
ISBN: 9788301207816
stron: 400, Format: ebook
Data wydania: 2020-03-31
Księgarnia: Helion

Cena książki: 63,20 zł (poprzednio: 78,02 zł)
Oszczędzasz: 19% (-14,82 zł)

Dodaj do koszyka Mikroserwisy w akcji

Tagi: Inne - Programowanie

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.

Dodaj do koszyka Mikroserwisy w akcji

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

Dodaj do koszyka Mikroserwisy w akcji

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2024 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.