Skip to content

Commit 127cb59

Browse files
golorodengoloroden
committed
chore: Add documentation on service-to-service communication.
1 parent 7224d8c commit 127cb59

File tree

1 file changed

+157
-0
lines changed
  • documentation/06-integration/03-service-zu-service

1 file changed

+157
-0
lines changed

‎documentation/06-integration/03-service-zu-service/README.md‎

Lines changed: 157 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,157 @@
1+
# Service-zu-Service-Kommunikation
2+
3+
- Verteilte Systeme basieren auf Netzwerken
4+
- Dadurch werden sie inhärent komplex
5+
- Netzwerke sind unzuverlässig
6+
- Fehler und Latenz sind normal
7+
8+
- Spektrum an Kommunikation
9+
- Direkte Aufrufe bis zu entkoppelten Nachrichten
10+
- Es gibt keinen "richtigen" oder "falschen" Ansatz
11+
- Eher: Es gibt "passende" und "unpassende" Ansätze
12+
- Jeder Ansatz zieht Trade-Offs nach sich
13+
14+
- Synchrone Kommunikation
15+
- Request-Response
16+
- Direkter Aufruf, direktes Ergebnis
17+
- Enge Kopplung bezüglich Zeit und Verfügbarkeit
18+
- Vorteile
19+
- Einfach
20+
- Ergebnis liegt "sofort" vor
21+
- Einfache Fehlerbehandlung
22+
- Nachteile
23+
- Zeitliche Kopplung und Verfügbarkeit
24+
- Latenzen summieren sich
25+
26+
- Asynchrone Kommunikation
27+
- "Fire and forget" / "Eventual Response"
28+
- Kein direkter Aufruf, kein direktes Ergebnis
29+
- Lose Kopplung bezüglich Zeit und Verfügbarkeit
30+
- Message-Queues als Vermittler
31+
- Vorteile
32+
- Zeitliche Entkopplung und Möglichkeit der Nicht-Verfügbarkeit
33+
- Bessere Resilienz
34+
- Nachteile
35+
- Höhere Komplexität
36+
- Ergebnis liegt nicht "sofort" vor
37+
- Aufwändigere Fehlerbehandlung
38+
39+
- CAP-Theorem
40+
- Consistency vs Availability im Falle einer Partition
41+
- Synchron ist CP, asynchron ist AP
42+
- Die Frage nach CP vs AP ist *keine* technische Frage!
43+
- Sondern eine Business-Frage (Risiko und Wahrscheinlichkeit)
44+
45+
- Latenz berücksichtigen
46+
- Latenz ist unvermeidbar
47+
- Netzwerk-Technologie, geografische Distanz, Netzwerk-Hops, Verarbeitungszeit
48+
49+
- Timeouts (bei synchroner Kommunikation), um Latenz zu kontrollieren
50+
- Darf nicht zu kurz sein, ansonsten erhält man (vermeintliche) Fehler
51+
- Darf nicht zu lang sein, ansonsten verschwendet man Ressourcen und Zeit
52+
- Vorsicht
53+
- A -> B (mit Timeout von 30s)
54+
- A -> B -> C (jeweils mit Timeout von 30s)
55+
- A-B braucht einen längeren (!) Timeout als B-C
56+
57+
- Fehler sind die Regel, nicht die Ausnahme
58+
- Denn in einem verteilten System können jederzeit Komponenten / Services ausfallen
59+
- Partielle Ausfälle vs Totalausfall
60+
61+
- Protokolle für synchrone Service-zu-Service-Kommunikation
62+
- HTTP als Standard-Protokoll für synchrone Kommunikation
63+
- HTTP/2 und HTTP/3 als Alternativen
64+
- gRPC als High-Performance-Alternative
65+
66+
```
67+
Entkoppeln von API und Fachlichkeit
68+
|
69+
v
70+
Client -> API (HTTP) --> Fachlogik
71+
-> API (gRPC) -->
72+
```
73+
74+
- Protokolle für asynchrone S2S-Kommunikation
75+
- Message-Queues, zB AMQP, MQTT, …
76+
- At-least-once vs at-most-once
77+
- Push vs Pull
78+
79+
- Push vs Pull
80+
- Service A braucht Informationen von Service B
81+
- Option 1: Service A *fragt* Service B
82+
- Pull, synchron
83+
- Fördert Autorität
84+
- Favorisiert CP
85+
- Option 2: Service B *schickt proaktiv* Daten zu Service A
86+
- Push, asynchron
87+
- Fördert Autonomie
88+
- Favorisiert AP
89+
90+
```
91+
Service X
92+
POST /register-webhook { url: 'http://...', ... }
93+
94+
1. Kommunikation: Registrieren -> synchron
95+
2. Kommunikation: Callback (per HTTP) -> synchron
96+
97+
oder
98+
99+
1. Kommunikation: Registrieren -> Callback -> asynchron
100+
2. Kommunikation: Callback (per HTTP) -> synchron
101+
```
102+
103+
- Was macht man, wenn ein Aufruf schiefgeht?
104+
- Retry-Pattern
105+
- Fehler durch Wiederholen versuchen zu beheben
106+
- Idempotenz als (weiche) Voraussetzung
107+
- Kurze Retry-Zeiten, aber zufällig gestreut, um Spitzen zu vermeiden
108+
- Retry-Zeiten mit exponenziellem Backoff, also zB 100ms, dann 200ms, dann 400ms, dann 800ms, …
109+
- Aber gecappt (Obergrenze)!
110+
111+
- Circuit-Breaker
112+
- Automatische Abschaltung bei wiederholten Fehlern
113+
- Drei Zustände
114+
- Closed (Normal)
115+
- Open (Blockiert)
116+
- Half-Open (Testet, ob Verbindung wieder möglich ist)
117+
118+
- Bulkhead-Pattern
119+
- Isolation von Ressource-Nutzung
120+
- Durch Namespaces, durch Limits, durch Pools, …
121+
- Anschauliches Beispiel
122+
- Prozess-Isolation von Tabs im Browser
123+
124+
- Idempotenz
125+
- Mehrfache Ausführung führt zum gleichen Ergebnis
126+
- Unter Umständen kritisch für Retry-Logik
127+
- Eigentlich will man Exactly-Once
128+
- Da Exactly-Once nicht möglich ist
129+
- Weicht man in der Regel auf At-Least-Once aus
130+
- Das heißt, Nachrichten kommen eventuell doppelt
131+
- Das Ziel ist, Nachrichten zu deduplizieren
132+
- Eine Möglichkeit ist, mit idempotenten Aktionen zu arbeiten
133+
- Eine andere Möglichkeit ist, mit Message-IDs zu arbeiten
134+
135+
- USE und RED
136+
- USE
137+
- Utilization
138+
- Misst die Auslastung von CPU, Memory, Disk, …
139+
- ZB "CPU-Last liegt bei 80%"
140+
- Saturation
141+
- Die Überlastung, wie viel Arbeit gerade nicht erledigt werden kann
142+
- ZB "50 Threads warten auf CPU-Zeit"
143+
- Errors
144+
- RED
145+
- Rate
146+
- Der Durchsatz des Services (wird der Service genutzt)
147+
- ZB "1000 Requests/s"
148+
- Errors
149+
- Duration
150+
- Ist mein Service schnell genug?
151+
- ZB "700ms pro Request"
152+
- Vergleich
153+
- USE misst interne Faktoren des Services ("Warum?")
154+
- RED misst externe Faktoren des Services ("Was?")
155+
156+
- Chaos Engineering
157+
- Netflix Chaos Monkey

0 commit comments

Comments
 (0)