S-hared-database-per-service Muster - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

S-hared-database-per-service Muster

Im shared-database-per-service Muster wird dieselbe Datenbank von mehreren Microservices gemeinsam genutzt. Sie müssen die Anwendungsarchitektur sorgfältig bewerten, bevor Sie dieses Muster anwenden, und sicherstellen, dass Sie Hot-Tabellen (einzelne Tabellen, die zwischen mehreren Microservices gemeinsam genutzt werden) vermeiden. Alle Ihre Datenbankänderungen müssen auch abwärtskompatibel sein. Entwickler können beispielsweise Spalten oder Tabellen nur löschen, wenn nicht von der aktuellen und der vorherigen Version aller Microservices auf Objekte verwiesen wird.

In der folgenden Abbildung wird eine Versicherungsdatenbank von allen Microservices gemeinsam genutzt und eine IAM-Richtlinie bietet Zugriff auf die Datenbank. Dies sorgt für eine arbeitsfreie Entwicklungszeit, z. B. muss eine Änderung des Microservice „Vertrieb“ Schemaänderungen mit dem Microservice „Kunde“ koordinieren. Dieses Muster reduziert nicht die Abhängigkeiten zwischen den Entwicklungsteams und führt die Laufzeiteinbindung ein, da alle Microservices dieselbe Datenbank nutzen. Beispielsweise können lang andauernde „Sales“-Transaktionen die „Customer“-Tabelle sperren und so die „Customer“-Transaktionen blockieren.

S-hared-database-per-service Muster

Sie sollten erwägen, dieses Muster zu verwenden, wenn:

  • Sie möchten nicht zu viel Faktorwechsel Ihrer vorhandenen Codebasis vornehmen.

  • Sie erzwingen die Datenkonsistenz, indem Sie Transaktionen verwenden, die Atomizität, Konsistenz, Isolation und Haltbarkeit (ACID) bereitstellen.

  • Sie möchten nur eine Datenbank warten und betreiben.

  • Die Implementierung des database-per-service Musters ist aufgrund von Abhängigkeiten zwischen Ihren vorhandenen Microservices schwierig.

  • Sie möchten Ihre vorhandene Datenebene nicht vollständig neu entwerfen.