Datenhoheit und Datenbank pro Service

Warum Datenhoheit die erste Datenfrage ist

Kapitel 6 hat Systeme in Services aufgeteilt, die unabhängig deployt, skaliert und geändert werden. Code lässt sich relativ leicht aufteilen, Daten nicht. Eine Bestellung verweist auf einen Kunden, einen Speisekartenartikel, ein Restaurant und einen Kurier, und jedes Team will einen Teil davon lesen und oft auch ändern. Die wichtigste Frage einer verteilten Datenarchitektur ist deshalb nicht, welche Datenbank man kauft, sondern wem welche Daten gehören: Welche Komponente darf sie ändern, welche setzt ihre Regeln durch, und wie bekommen alle anderen sie zu sehen?

Datenhoheit ist wichtig, weil Daten Code überdauern. Services werden alle paar Jahre neu geschrieben; Kundenkonten, Hauptbücher und Patientenakten werden jahrzehntelang aufbewahrt. Eine falsch geregelte Datenhoheit erzeugt die teure Art von Architekturschulden: zwei Services, die sich nicht getrennt releasen lassen, weil sie sich Tabellen teilen, ein Statusfeld, das drei Teams abwechselnd überschreiben, oder ein Monatsbericht, den niemand reproduzieren kann, weil die Zahlen aus fünf Kopien derselben Daten stammen, die voneinander abweichen.

Dieser Abschnitt nutzt zwei durchgehende Beispiele, die im ganzen Kapitel wiederkehren: eine Essenslieferplattform (Kunden, Restaurants, Kuriere, Bestellungen) und eine Onlinebank (Kunden, Konten, Zahlungen, ein Hauptbuch).

System of Record und Datenhoheit

Ein System of Record ist die maßgebliche Quelle für ein bestimmtes Datum: der Ort, dessen Wert gilt, wenn Kopien voneinander abweichen. In der Bank ist das zentrale Hauptbuch das System of Record für Kontostände; der Kontostand in der Mobile-App, der im Cache der Betrugserkennung und der in der Ladung des Data Warehouse von letzter Nacht sind alles Kopien. In der Essenslieferplattform ist der Speisekarten-Service des Restaurants das System of Record für Preise, obwohl der Suchindex, der Offline-Cache der Mobile-App und die Bestellpositionen alle Kopien davon halten.

Datenhoheit macht daraus eine Verantwortung. Die besitzende Komponente (und das Team dahinter) ist die einzige, die die Daten schreibt, ihre Invarianten (Regeln, die immer gelten müssen, etwa ein Hauptbucheintrag wird nie bearbeitet, nur storniert) durchsetzt, ihr Schema festlegt und sie über eine von ihr kontrollierte Schnittstelle für andere veröffentlicht. Datenhoheit ist eine Designentscheidung, keine Eigenschaft der Datenbank: Zwei Services können auf demselben Datenbankserver liegen und trotzdem eine klare Datenhoheit haben, und zwei Services mit getrennten Datenbanken können immer noch um dieselben Tatsachen streiten, wenn die Grenze zwischen ihnen schlecht gezogen ist.

Eine nützliche Regel aus Software Architecture: The Hard Parts (Neal Ford, Mark Richards, Pramod Sadalage und Zhamak Dehghani, 2021) lautet: Der Service, der in eine Tabelle schreibt, besitzt sie. Lesen lässt sich günstig teilen, Schreiben nicht, denn wer schreibt, muss die Regeln durchsetzen.

Die gemeinsame Datenbank und warum sie Services koppelt

Der einfachste Weg, mehrere Anwendungen mit denselben Daten arbeiten zu lassen, ist, ihnen allen Zugriff auf eine Datenbank zu geben. Martin Fowler nannte das eine Integrationsdatenbank (2004): eine Datenbank, die der Integrationspunkt zwischen Anwendungen ist, im Gegensatz zu einer Anwendungsdatenbank, die nur einer Anwendung dient. Sie wirkt verlockend: keine APIs zu bauen, Joins funktionieren über alles, und eine Transaktion kann Bestellungen und Zahlungen gemeinsam aktualisieren. Fowlers Urteil, das die meisten Architekten teilen, lautet, dass Integrationsdatenbanken vermieden werden sollten, weil die Kopplung, die sie erzeugen, tief und größtenteils unsichtbar ist.

Betrachten Sie die Formen von Kopplung, die sie mit sich bringt. Schemakopplung: Jede Tabelle und jede Spalte ist faktisch eine öffentliche API. Wer orders.state in orders.status umbenennt, bricht jeden Service, der sie liest, und niemand kann sicher sagen, welche das sind, weil SQL-Abfragen über viele Codebasen, Berichte und Tabellenkalkulationen verstreut sind. Deployment-Kopplung: Eine Schemaänderung muss mit jedem Team abgestimmt werden, das die Tabelle berührt, sodass Services, die unabhängig releast werden sollten, gemeinsam releast werden. Semantische Kopplung: Das Schema muss jedem Client dienen, also wird es allgemeiner und verwirrender (Fowler merkt an, dass es am Ende Konzepte zu vereinheitlichen versucht, die in getrennte Bounded Contexts gehören), und die Geschäftsregeln für eine Tabelle landen dupliziert, und zwar uneinheitlich, in jedem Service, der sie schreibt. Laufzeitkopplung: Die langsame Berichtsabfrage oder der sperrintensive Batch-Job eines Service beeinträchtigt jeden anderen Service, und die Datenbank wird zu einem gemeinsamen Single Point of Failure und zu einer Obergrenze für Verbindungen.

Nichts davon ist fatal für eine einzelne Anwendung oder einen modularen Monolithen, dessen Module die Tabellen der anderen respektieren, oder für die grobgranulare servicebasierte Architektur, in der sich eine Handvoll Domänenservices oft bewusst eine Datenbank teilt. Zum Problem wird es, wenn Teams unabhängige Deploybarkeit erwarten, aber die gemeinsamen Tabellen behalten; das ist ein klassischer Weg zu einem verteilten Monolithen.

Datenbank pro Service

Die Alternative, die mit Microservices verbunden ist, ist das Muster Datenbank pro Service: Die persistenten Daten jedes Service sind privat, und andere Services erreichen sie nur über die API des Service oder die Events, die er veröffentlicht. Chris Richardsons Musterkatalog (microservices.io) merkt an, dass das nicht einen eigenen Server pro Service bedeuten muss. Es gibt drei Stufen der Trennung, und die wichtige Grenze ist die erste.

Die Vorteile spiegeln die Kosten der gemeinsamen Datenbank: Eigentümer ändern ihre Schemas frei, skalieren und optimieren ihre Speicher unabhängig, wählen die richtige Art von Datenbank und begrenzen Ausfälle. Die Kosten sind real und sollten in jedem Entscheidungsdokument genannt werden. Joins über Services hinweg entfallen und müssen durch API-Komposition oder replizierte Daten ersetzt werden. Eine einzelne ACID-Transaktion kann nicht mehr Bestellungen und Zahlungen zugleich umfassen; serviceübergreifende Änderungen werden zu Sagas mit kompensierenden Schritten. Referenzielle Integrität über Services hinweg (jede Bestellung verweist auf einen echten Kunden) wird nicht mehr durch Fremdschlüssel durchgesetzt. Reporting braucht eine eigene Pipeline. Und es gibt mehr Datenbanken, die gesichert, gepatcht und überwacht werden müssen.

The Hard Parts fasst die Entscheidung als Gleichgewicht von Kräften. Disintegratoren drängen zum Aufteilen der Daten: Änderungskontrolle (wie viele Services brechen, wenn sich eine Tabelle ändert), Verbindungslimits, Skalierbarkeit, Fehlertoleranz, der Wunsch nach unabhängig deploybaren Einheiten und der Bedarf an unterschiedlichen Datenbanktypen. Integratoren ziehen Daten zusammen: Beziehungen, die referenzielle Integrität brauchen, und Operationen, die wirklich eine einzige atomare Transaktion brauchen. Wenn zwei Tabellen immer gemeinsam in einer Transaktion geändert werden und kein unabhängiges Eigenleben haben, spricht das stark dafür, dass sie demselben Eigentümer gehören.

Wenn mehrere Services dieselben Daten schreiben

Fragen der Datenhoheit werden schwierig, wenn mehr als ein Service dieselbe Entität berechtigterweise ändert. The Hard Parts unterscheidet drei Situationen. Bei alleiniger Datenhoheit schreibt nur ein Service die Tabelle, und er besitzt sie einfach. Bei allgemeiner Datenhoheit schreiben die meisten Services dieselbe Tabelle (etwa ein Audit-Log oder eine Reihe von Konfigurationseinstellungen); die übliche Antwort ist, einen eigenen Service zu schaffen, der die Daten besitzt, und allen anderen eine API zu geben, oft eine asynchrone, damit die Schreiber nicht ausgebremst werden. Bei gemeinsamer Datenhoheit schreibt eine kleine Zahl von Services, typischerweise zwei, dieselbe Tabelle, meist innerhalb derselben Domäne. Das Buch bietet vier Techniken für gemeinsame Datenhoheit an.

Keine Technik ist kostenlos, und die richtige hängt davon ab, wie oft sich die Daten ändern, wie streng ihre Regeln sind und wie unabhängig die Teams sein müssen. In der Praxis ist Delegation die häufigste Antwort für Geschäftsentitäten mit einem Lebenszyklus (Bestellungen, Zahlungen, Buchungen), das Aufteilen der Tabelle funktioniert gut, wenn die gemeinsam geschriebenen Spalten eigentlich verschiedene Tatsachen sind, die nur zufällig zusammen gespeichert wurden, und das Zusammenlegen ist die ehrliche Antwort, wenn die beiden Services von vornherein zu fein geschnitten wurden.

Daten lesen, die Ihnen nicht gehören

Sobald die Datenhoheit geklärt ist, muss jeder andere Service die Daten immer noch lesen. Die Küchenanzeige braucht die Lieferhinweise des Kunden; die Betrugserkennung braucht die jüngsten Zahlungen des Kontos. Es gibt vier grundlegende Optionen, und jede wägt Aktualität gegen Kopplung ab. Beachten Sie, dass ereignisgesteuerte Designs, die in Kapitel 6 behandelt wurden, die dritte und vierte liefern.

Fowler nennt die vierte Option Event-Carried State Transfer: Events wie MenuItemPriceChanged enthalten die neuen Werte, sodass Konsumenten nicht zurückrufen müssen. Ein verwandter Mechanismus, Change Data Capture (CDC), liest das Log der Datenbank des Eigentümers und macht aus jeder committeten Änderung ein Event; das vermeidet das Dual-Write-Problem (in die Datenbank schreiben und getrennt davon ein Event veröffentlichen, sodass das eine gelingen und das andere scheitern kann). Die Transactional Outbox, die dasselbe Problem innerhalb der Anwendung löst, wird bei den Sagas behandelt.

Reporting über Services hinweg

Datenbank pro Service erschwert eine alte Aufgabe: den übergreifenden Bericht. Umsatz pro Restaurant pro Woche, abzüglich Erstattungen, aufgeschlüsselt nach Kuriertyp braucht Bestellungen, Zahlungen, Restaurants und Lieferungen. Ihn durch seitenweises Aufrufen von vier APIs zu erstellen ist langsam und belastet operative Services mit Reporting-Last. Ihre Datenbanken direkt abzufragen führt die Kopplung der gemeinsamen Datenbank durch die Hintertür wieder ein.

Die übliche Antwort ist, Reporting vom operativen Betrieb zu trennen. Fowler beschrieb eine Reporting-Datenbank: einen eigenen Speicher, für Abfragen gestaltet und aus den operativen Systemen gespeist, den Reporting-Nutzer frei lesen dürfen. Heute ist das meist ein Data Warehouse oder Lakehouse, gespeist durch CDC oder Events, behandelt in Analytics und Streaming. Für kleine, nahezu echtzeitnahe Ansichten innerhalb des Produkts (das Dashboard eines Restaurants mit den heutigen Bestellungen) kann ein Service aus Events sein eigenes Read Model aufbauen, die Idee hinter CQRS. In beiden Fällen hängen die Pipelines, die das Reporting speisen, von den Datenstrukturen der Eigentümer ab, und deshalb brauchen sie Verträge.

Datenverträge

Ein Datenvertrag ist eine explizite, versionierte Vereinbarung zwischen dem Eigentümer eines Datenbestands und seinen Konsumenten. Er legt das Schema fest (Felder, Typen, welche null sein dürfen), die Bedeutung jedes Felds (ist amount in Pence oder Pfund, mit oder ohne Mehrwertsteuer?), Qualitätserwartungen (keine doppelten Bestellkennungen, höchstens 0,1 % der Zeilen ohne Restaurant), Service-Levels (wie aktuell die Daten sind, wie lange sie aufbewahrt werden), wer sie verantwortet und wie Änderungen angekündigt werden. Er überträgt die Idee eines API-Vertrags auf Daten, die über Events, CDC-Streams und Warehouse-Tabellen zwischen Teams fließen.

Verträge sind am nützlichsten, wenn sie maschinenlesbar sind und automatisch geprüft werden: eine Pipeline, die eine Schemaänderung ablehnt, die registrierte Konsumenten brechen würde, oder ein Test, der fehlschlägt, wenn eine Qualitätsregel verletzt wird. Der Open Data Contract Standard (ODCS), gepflegt vom Bitol-Projekt unter der Linux Foundation AI & Data, definiert ein YAML-Format für Schema, Qualitätsregeln, Service-Levels, Rollen und Support-Kanäle. Datenverträge sind nicht kostenlos: Jemand muss sie schreiben und pflegen, und zu strenge Verträge bremsen Änderungen. The Hard Parts stellt strenge Verträge (präzise, überprüfbar, eng koppelnd) lockeren gegenüber (leichter weiterzuentwickeln, aber mit mehr Testbedarf) und schlägt Consumer-Driven Contracts, bei denen Konsumenten angeben, was sie tatsächlich nutzen, als Mittelweg vor. Wie man ein Schema ändert, ohne Konsumenten zu brechen, ist Thema der Schemaevolution.

Häufige Fehler

Services aufteilen, aber die gemeinsamen Tabellen behalten. Teams bekommen die Betriebskosten der Verteilung ohne die Unabhängigkeit, die sie erkaufen sollte. Wenn sich Services nicht ohne eine abgestimmte Schemaänderung deployen lassen, sind sie nicht unabhängig. Entity-Services. Ein CustomerService, der nichts als Anlegen, Lesen, Aktualisieren und Löschen über einer Tabelle bietet und von jedem anderen Service aufgerufen wird, ist eine gemeinsame Datenbank mit zusätzlicher Latenz; Datenhoheit sollte Geschäftsfähigkeiten und ihren Regeln folgen, nicht Substantiven. Kopien, die unbemerkt zu Mastern werden. Siehe die Warnung oben. Reporting bis zum Schluss ignorieren. Der erste Finanzbericht nach der Aufteilung zeigt oft, dass niemand geplant hat, wie die Daten wieder zusammengeführt werden. Datenhoheit als rein technisch behandeln. Datenhoheit ist auch organisatorisch: Jemand muss für die Qualität der Daten geradestehen, und nach dem Gesetz von Conway halten Datengrenzen, die quer zu Teamgrenzen verlaufen, meist nicht lange.

Ein guter Test für jedes Datendesign besteht darin, für jede wichtige Tatsache drei Fragen zu stellen: Wer ist der einzige Schreiber, wo werden ihre Regeln durchgesetzt, und wie veraltet darf jede Kopie sein? Lautet eine Antwort kommt darauf an oder mehrere Services, ist das Design nicht fertig.