Zerlegung nach Transaktionen - 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.

Zerlegung nach Transaktionen

In einem verteilten System muss eine Anwendung in der Regel mehrere Microservices aufrufen, um eine Geschäftstransaktion abzuschließen. Um Latenzprobleme oder zweiphasige Commit-Probleme zu vermeiden, können Sie Ihre Microservices auf der Grundlage von Transaktionen gruppieren. Dieses Muster ist angemessen, wenn Sie Reaktionszeiten für wichtig halten und Ihre verschiedenen Module nach dem Verpacken keinen Monolith bilden. Die folgende Tabelle erklärt die Vor- und Nachteile der Verwendung dieses Musters.

Vorteile Nachteile

  • Schnellere Reaktionszeiten.

  • Sie müssen sich keine Sorgen um die Datenkonsistenz machen.

  • Verbesserte Verfügbarkeit.

  • Mehrere Module können zusammen gepackt werden, wodurch ein Monolith entstehen kann.

  • In einem einzigen Microservice werden mehrere Funktionen anstelle von separaten Microservices implementiert, was die Kosten und die Komplexität erhöht.

  • Transaktionsorientierte Microservices können wachsen, wenn die Anzahl der Geschäftsbereiche und der Abhängigkeiten zwischen ihnen hoch ist.

  • Inkonsistente Versionen können gleichzeitig für dieselbe Geschäftsdomäne bereitgestellt werden.

In der folgenden Abbildung ist der Versicherungsmonolith auf der Grundlage von Transaktionen in mehrere Microservices unterteilt.

Zersetzung von Monolithen durch Transaktionen

In einem Versicherungssystem wird eine Schadenanfrage in der Regel einem Kunden angezeigt, nachdem sie eingereicht wurde. Das bedeutet, dass ein Schadenservice ohne einen Microservice für Kunden nicht existieren kann. Vertrieb und Kunden sind in einem Microservice-Paket zusammengefasst, und eine Geschäftstransaktion erfordert die Abstimmung mit beiden.