Grundsatz Nr. 4 der Microservices-Architektur: Asynchrone Kommunikation vor synchroner Kommunikation

Dieser Beitrag ist Teil einer sechsteiligen Serie über Microservices-Prinzipien. Die anderen Teile sind: Geschäftsfähigkeit, Autonomie, Kleiner begrenzter Kontext, Beste Technologie und Ein Team.   Microservices sind ein heißes Thema. Deshalb sagen viele Leute eine Menge Dinge. Um Unternehmen dabei zu helfen, das Beste aus diesem neuen Architekturstil herauszuholen, hat Xebia eine Reihe von Prinzipien definiert, die unserer Meinung nach bei der Implementierung einer Microservice-Architektur angewandt werden sollten. In diesem Blog wird erklärt, warum wir asynchrone Kommunikation der synchronen Kommunikation vorziehen

In einem früheren Beitrag dieser Serie haben wir erklärt, dass wir die Autonomie von Microservices der Koordination zwischen Microservices vorziehen. Das bedeutet nicht, dass wir eine Microservices-Landschaft haben, in der alle Microservices ohne Abhängigkeit von einem anderen Microservice laufen. Es wird immer Abhängigkeiten geben, aber wir versuchen, die Anzahl der Abhängigkeiten zu minimieren. Wenn Sie die Anzahl der Abhängigkeiten minimiert haben, wie sollten diese dann implementiert werden, damit die Autonomie so weit wie möglich erhalten bleibt? Synchrone Abhängigkeiten zwischen Diensten bedeuten, dass der aufrufende Dienst blockiert ist und auf eine Antwort des aufgerufenen Dienstes wartet, bevor er seinen Betrieb fortsetzt. Das ist eine enge Kopplung, die sich nicht gut skalieren lässt, und der aufrufende Dienst kann durch Fehler im aufgerufenen Dienst beeinträchtigt werden. In einer hochverfügbaren, robusten Microservices-Landschaft ist dies nicht wünschenswert. Es können zwar Maßnahmen ergriffen werden (denken Sie an Dinge wie Stromkreisunterbrecher), aber das erfordert zusätzlichen Aufwand. Die bevorzugte Alternative ist die Verwendung asynchroner Kommunikation. Bei diesem Muster veröffentlicht der aufrufende Dienst einfach seine Anfrage (oder Daten) und fährt mit anderen Arbeiten fort (die nichts mit dieser Anfrage zu tun haben). Der Dienst hat einen separaten Thread, der auf eingehende Antworten (oder Daten) wartet und diese verarbeitet, wenn sie eintreffen. Er blockiert nicht und wartet nicht auf eine Antwort, nachdem er eine Anfrage gesendet hat, was die Skalierbarkeit verbessert. Probleme in einem anderen Dienst werden diesen Dienst nicht unterbrechen. Wenn andere Dienste vorübergehend gestört sind, kann der aufrufende Dienst einen Prozess möglicherweise nicht vollständig abschließen, aber der aufrufende Dienst selbst ist nicht gestört. Durch die Verwendung des asynchronen Musters sind die Dienste also im Vergleich zum synchronen Muster stärker entkoppelt, wodurch die Autonomie des Dienstes erhalten bleibt.   [bearbeitet: 3 aug 2015 - Präambel hinzugefügt und Zeile"In den nächsten Tagen werden wir jedes dieser Prinzipien in einer Reihe von Blogbeiträgen ausführlicher behandeln." entfernt]