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.
D-atabase-per-service Muster
Die Trichterverbindung ist das Kernmerkmal einer Microservices-Architektur, da jeder einzelne Microservice Informationen unabhängig voneinander speichern und aus seinem eigenen Datenspeicher abrufen kann. Durch die Bereitstellung des database-per-service Musters wählen Sie die am besten geeigneten Datenspeicher (z. B. relationale oder nicht relationale Datenbanken) für Ihre Anwendung und Geschäftsanforderungen aus. Das bedeutet, dass Microservices keine Datenschicht gemeinsam nutzen, Änderungen an der individuellen Datenbank eines Microservice keine Auswirkungen auf andere Microservices haben, dass auf einzelne Datenspeicher nicht direkt von anderen Microservices zugegriffen werden kann und dass auf persistente Daten nur von APIs zugegriffen wird. Das Entkoppeln von Datenspeichern verbessert auch die Ausfallsicherheit Ihrer gesamten Anwendung und stellt sicher, dass eine einzelne Datenbank nicht ein einziger Fehlerpunkt sein kann.
In der folgenden Abbildung werden verschiedene AWS Datenbanken von den Microservices „Vertrieb“, „Kunde“ und „Compliance“ verwendet. Diese Microservices werden als -AWS LambdaFunktionen bereitgestellt und über eine Amazon API Gateway-API aufgerufen. AWS Identity and Access Management (IAM)-Richtlinien stellen sicher, dass Daten privat gehalten und nicht zwischen den Microservices geteilt werden. Jeder Microservice verwendet einen Datenbanktyp, der seine individuellen Anforderungen erfüllt. Beispielsweise verwendet „Vertrieb“ Amazon Aurora, „Kunde“ verwendet Amazon DynamoDB und „Compliance“ verwendet Amazon Relational Database Service (Amazon RDS) für SQL Server.
Sie sollten erwägen, dieses Muster zu verwenden, wenn:
-
Zwischen Ihren Microservices ist eine Trichterverbindung erforderlich.
-
Microservices haben unterschiedliche Compliance- oder Sicherheitsanforderungen für ihre Datenbanken.
-
Eine genauere Skalierungssteuerung ist erforderlich.
Die Verwendung des database-per-service Musters hat die folgenden Nachteile:
-
Es kann schwierig sein, komplexe Transaktionen und Abfragen zu implementieren, die sich über mehrere Microservices oder Datenspeicher erstrecken.
-
Sie müssen mehrere relationale und nicht relationale Datenbanken verwalten.
-
Ihre Datenspeicher müssen zwei der Anforderungen des CAP-Theors
erfüllen: Konsistenz , Verfügbarkeit oder Partitionstoleranz .
Anmerkung
Wenn Sie das database-per-service Muster verwenden, müssen Sie die API-Kompositionsmuster oder die bereitstellen, CQRS-Muster um Abfragen zu implementieren, die sich über mehrere Microservices erstrecken.
