Architekturstile II: Verteilte Systeme

Willkommen zu Kapitel 6: Architekturstile, Teil zwei, Verteilte Systeme. Kapitel 5 hat Stile beschrieben, bei denen das ganze System als eine Einheit deployt wird. Dieses Kapitel stellt dieselben Fragen über ein Netzwerk hinweg. Es erklärt, wann sich die Verteilung eines Systems lohnt, welche verteilten Hauptstile es gibt und auf welche Mechanismen sie alle angewiesen sind. Und es ist präzise bei Ausfällen, Zustellgarantien und Konsistenz.

Fast jedes System nennenswerter Größe ist heute in irgendeiner Form verteilt. Eine mobile App spricht mit Backend-Services, die Zahlungsanbieter, Kartendienste und Message Broker aufrufen, und die Services selbst laufen auf vielen Rechnern. Ein aufgeteiltes System kann unabhängige Skalierung, Fehlerisolation, unabhängige Releases und autonome Teams ermöglichen. Es bringt aber auch Probleme, die innerhalb eines Prozesses nicht auftreten können: verlorene oder doppelte Nachrichten, Services, die langsam statt tot sind, abweichende Daten zwischen Kopien und Ausfälle von Rechnern, von denen Sie gar nicht wussten, dass Sie von ihnen abhängen.

Das Kapitel ist als „Mittelstufe bis Fortgeschritten“ eingestuft. Es richtet sich an Entwicklungs- und Architekturfachleute, die Systeme aus vielen Services entwerfen oder prüfen. Es baut auf den Stilen aus Kapitel 5 und den Qualitäten aus Kapitel 2 auf, jetzt unter Netzwerkbedingungen. Insbesondere nutzt es Verfügbarkeit in Reihe und parallel, Kopplung und das Gesetz von Conway sowie das Architekturquantum, den modularen Monolithen und Bounded Contexts. Und es führt zu Kapitel 7, das den schwierigsten Teil der Verteilung behandelt: die Daten.

Die wichtigste Idee des Kapitels ist, dass Verteilung ein Tauschgeschäft ist, kein Upgrade. Jeder Nutzen wird mit Latenz, Konsistenz, Observability und Betriebsaufwand bezahlt. Wer gut architektiert, kann sagen, welcher Nutzen gekauft wird, zu welchem Preis und warum eine günstigere Lösung innerhalb eines Monolithen nicht genügt.

Das Kapitel geht vom Warum zum Wie. Abschnitt sechs Punkt eins legt die Gründe für eine Verteilung dar, die acht Trugschlüsse verteilter Systeme und den Teilausfall, und gibt Ihnen die Rechnung, mit der Sie den Preis bestimmen, bevor Sie sich festlegen. Abschnitt sechs Punkt zwei behandelt die servicebasierte Architektur, einen pragmatischen Mittelweg aus wenigen grobgranularen Domain Services, und die klassische serviceorientierte Architektur, einschließlich der Frage, warum sie in Ungnade fiel. Abschnitt sechs Punkt drei behandelt Microservices: an Bounded Contexts ausgerichtete Services, unabhängiges Deployment, eine Datenbank pro Service, wie groß ein Service sein sollte, und den verteilten Monolithen. Abschnitt sechs Punkt vier behandelt die ereignisgesteuerte Architektur: Ereignisse und Commands, Broker und Mediatoren, Zustellgarantien und Consumer, die dieselbe Nachricht gefahrlos zweimal empfangen können.

Hier ist die Rechnung aus Abschnitt sechs Punkt eins. Eine Bestellung durchläuft fünf Services: das API-Gateway, dann Bestellungen, Speisekarte, Preisgestaltung und Zahlung. Jeder wartet auf die Antwort des nächsten, und jeder für sich ist zu neunundneunzig Komma neun Prozent der Zeit verfügbar. Aber Verfügbarkeiten multiplizieren sich. Zusammen ergeben sie einen Anfragepfad von nur etwa neunundneunzig Komma fünf Prozent: rund drei Komma sechs Stunden Ausfallzeit im Monat. Und Latenzen addieren sich. Mit zwanzig Millisekunden Arbeit in jedem Service plus etwas für jeden Netzwerk-Hop liegt der Median bei etwa hundertzehn Millisekunden. Fünf für sich genommen respektable Services ergeben einen viel schwächeren Anfragepfad. Das ist der Preis der Verteilung, auf dem Papier ausgerechnet, bevor Sie irgendetwas bauen.

Dieses Diagramm zeigt den Teilausfall, das grundlegende Problem. Ein Bestellservice bittet einen Zahlungsservice, vierundzwanzig Pfund fünfzig zu autorisieren, und wartet auf die Antwort. Drei verschiedene Dinge können schiefgehen. Die Anfrage geht verloren, und es wurde nichts abgebucht. Der Zahlungsservice stürzt ab oder hängt, und niemand weiß Bescheid. Oder die Antwort geht verloren, und die Karte wurde belastet. Für den Aufrufer sehen alle drei gleich aus: keine Antwort vor dem Timeout. Deshalb muss jede Operation, die wiederholt werden kann, idempotent sein, das heißt, sie zweimal auszuführen hat dieselbe Wirkung wie einmal.

Die zweite Hälfte wendet sich den Mechanismen zu, auf die jeder verteilte Stil angewiesen ist. Abschnitt sechs Punkt fünf vergleicht synchrone und asynchrone Kommunikation und die Kopplung, die jede erzeugt, und behandelt API-Design, Versionierung und Contract Testing. Abschnitt sechs Punkt sechs handelt davon, was Leser kopierter Daten erwarten können: Konsistenzmodelle, was das CAP-Theorem wirklich besagt, und PACELC. Abschnitt sechs Punkt sieben erklärt, warum Two-Phase Commit zwischen Services vermieden wird und wie Sagas, kompensierende Transaktionen und das Outbox-Muster Geschäftsprozesse auch ohne ihn korrekt halten. Abschnitt sechs Punkt acht schließt mit zwei Stilen für besondere Lastprofile: Serverless-Funktionen, die auf null skalieren, und Space-Based Architecture, die Daten im Arbeitsspeicher hält, um extreme Lastspitzen wie einen Vorverkaufsstart zu überstehen.

Drei Gewohnheiten ziehen sich durch jeden Abschnitt. Erstens: Zählen Sie synchrone Abhängigkeiten, nicht Services. Die Zahl der Dinge, die alle im selben Moment funktionieren müssen, damit eine Anfrage gelingt, bestimmt ihre Verfügbarkeit und Latenz. Zweitens: Gehen Sie davon aus, dass Nachrichten verloren gehen, sich verzögern, doppelt ankommen und die Reihenfolge wechseln, und legen Sie Empfänger so aus, dass eine wiederholte Nachricht keinen Schaden anrichtet. Drittens: Legen Sie fest, wem jedes Datenstück gehört, denn die Datenhoheit entscheidet, wo Transaktionen möglich sind und wo Konsistenz über Services hinweg gesteuert werden muss. Kapitel 7 baut diese Gewohnheit zu einer vollständigen Behandlung der Datenarchitektur aus.

Wenn das Thema neu für Sie ist, lesen Sie zuerst die einleitende Zusammenfassung jedes Abschnitts und die Kästen mit der Überschrift „Wenn das neu für Sie ist“. Erfahrene Fachleute finden Präzision dort, wo es darauf ankommt. Das Kapitel braucht etwa dreieinhalb Stunden Lesezeit. Zwei Beispiele kehren immer wieder. Die Essenslieferplattform zeigt gewöhnliches verteiltes Design. Ein Ticketsystem für eine Stadiontournee zeigt, was sich ändert, wenn Zehntausende Menschen in derselben Sekunde dieselben wenigen Plätze wollen. Jeder Abschnitt endet mit einigen Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie nachsehen. Wenn Sie so weit sind, legen Sie den optionalen Kapiteltest ab: zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten, in etwa fünfundvierzig Minuten. Die Bestehensgrenze liegt bei achtzig Prozent.

Das ist die Übersicht über Kapitel 6. Beginnen Sie mit Abschnitt sechs Punkt eins, wo wir die Gründe für eine Verteilung gegen die Trugschlüsse abwägen, die sie schwieriger machen, als sie aussieht. Bis gleich.