Was ist das Standardmuster für die Orchestrierung von Microservices?

Wenn ein Mikrodienst nur über seine eigene Domäne Bescheid weiß, es jedoch einen Datenfluss gibt, bei dem mehrere Dienste auf irgendeine Weise interagieren müssen, wie geht man vor?

Nehmen wir an, wir haben so etwas:

• Fakturierung
• Sendung

Nehmen wir zum Zwecke des Arguments an, dass nach dem Versand einer Bestellung die Rechnung erstellt werden sollte.

Irgendwo drückt jemand einen Knopf in einem GUI"Ich bin fertig, lass uns das machen!" In einer klassischen Monolith-Servicearchitektur würde ich sagen, dass dies entweder ESBbehandelt wird oder dass der Versanddienst Kenntnisse über den Rechnungsservice hat und dies einfach aufruft.

Aber wie gehen die Menschen in dieser schönen neuen Welt der Mikrodienste damit um?

Ich verstehe, dass dies als sehr meinungsbasiert angesehen werden kann. Aber es gibt eine konkrete Seite, da Microservices das oben Genannte nicht tun sollen. Es muss also ein "Was sollte es per Definition stattdessen tun" geben, das nicht auf Meinungen basiert.

Schießen.

Das Book Building Microservices beschreibt detailliert die Stile, die @RogerAlsing in seiner Antwort erwähnt hat.

Auf Seite 43 unter Orchestration vs Choreography heißt es in dem Buch:

Wenn wir beginnen, immer komplexere Logik zu modellieren, müssen wir uns mit dem Problem der Verwaltung von Geschäftsprozessen befassen, die sich über die Grenzen einzelner Services erstrecken. Und mit Microservices werden wir diese Grenze früher als gewöhnlich erreichen. [...] Wenn es darum geht, diesen Fluss tatsächlich zu implementieren, gibt es zwei Architekturstile, denen wir folgen könnten. Bei der Orchestrierung verlassen wir uns auf ein zentrales Gehirn, um den Prozess zu steuern und voranzutreiben, ähnlich wie der Dirigent in einem Orchester. Mit Choreografie informieren wir jeden Teil des Systems über seine Arbeit und lassen es die Details herausarbeiten, wie Tänzer, die alle ihren Weg finden und in einem Ballett auf andere um sie herum reagieren.

Das Buch erklärt dann die beiden Stile. Der Orchestrierungsstil entspricht eher der SOA-Idee von Orchestrierungs- / Aufgabendiensten , während der Choreografiestil den in Martin Fowlers Artikel erwähnten dummen Pfeifen und intelligenten Endpunkten entspricht .

Orchestrierungsstil

In diesem Stil erwähnt das obige Buch:

Lassen Sie uns darüber nachdenken, wie eine Orchestrierungslösung für diesen Ablauf aussehen würde. Hier wäre es wahrscheinlich am einfachsten, unseren Kundenservice als zentrales Gehirn zu fungieren. Bei der Erstellung wird über eine Reihe von Anforderungs- / Antwortanrufen mit der Treuepunktebank, dem E-Mail-Dienst und dem Postdienst [...] gesprochen. Der Kundendienst selbst kann dann verfolgen, wo sich ein Kunde in diesem Prozess befindet. Es kann überprüfen, ob das Konto des Kunden eingerichtet, die E-Mail gesendet oder die Post zugestellt wurde. Wir können das Flussdiagramm [...] nehmen und es direkt in Code modellieren. Wir könnten sogar Werkzeuge verwenden, die dies für uns implementieren, möglicherweise unter Verwendung einer geeigneten Regelengine. Zu diesem Zweck gibt es kommerzielle Tools in Form von Software zur Modellierung von Geschäftsprozessen. Angenommen, wir verwenden eine synchrone Anfrage / Antwort. Wir könnten sogar wissen, ob jede Phase funktioniert hat [...] Der Nachteil dieses Orchestrierungsansatzes ist, dass der Kundenservice zu einer zentralen Verwaltungsbehörde werden kann. Es kann zum Hub mitten in einem Web und zu einem zentralen Punkt werden, an dem die Logik zu leben beginnt. Ich habe gesehen, dass dieser Ansatz zu einer kleinen Anzahl intelligenter „Gott“ -Dienste führt, die anämischen CRUD-basierten Diensten mitteilen, was zu tun ist.

Hinweis: Ich nehme an, wenn der Autor Werkzeuge erwähnt, bezieht er sich auf etwas wie BPM (z. B. Aktivität , Apache ODE , Camunda ). Tatsächlich bietet die Workflow Patterns-Website eine beeindruckende Auswahl an Mustern für diese Art der Orchestrierung und bietet auch Bewertungsdetails verschiedener Hersteller-Tools, die bei der Implementierung auf diese Weise helfen. Ich glaube nicht, dass der Autor impliziert, dass man eines dieser Tools verwenden muss, um diesen Integrationsstil zu implementieren. Es könnten jedoch auch andere leichtgewichtige Orchestrierungs-Frameworks verwendet werden, z. B. Spring Integration , Apache Camel oder Mule ESB

Doch andere Bücher Ich habe zum Thema Microservice lesen und im Allgemeinen der Mehrheit der Artikel , die ich im Netz gefunden habe , scheinen diesen Ansatz Ungnade der Orchestrierung und stattdessen vorschlagen , die nächsten verwenden.

Choreografiestil

Im Choreografiestil sagt der Autor:

Mit einem choreografierten Ansatz könnten wir stattdessen den Kundendienst dazu bringen, ein Ereignis auf asynchrone Weise auszusenden, indem wir sagen, dass der Kunde erstellt wurde. Der E-Mail-Dienst, der Postdienst und die Treuepunktbank abonnieren dann einfach diese Ereignisse und reagieren entsprechend [...]. Dieser Ansatz ist wesentlich entkoppelter. Wenn ein anderer Dienst zur Erstellung eines Kunden benötigt wird, muss er nur die Ereignisse abonnieren und bei Bedarf seine Arbeit erledigen. Der Nachteil ist, dass die explizite Ansicht des Geschäftsprozesses, den wir in [dem Workflow] sehen, nur noch implizit in unserem System [...] wiedergegeben wird. Dies bedeutet, dass zusätzliche Arbeit erforderlich ist, um sicherzustellen, dass Sie die richtigen Dinge überwachen und verfolgen können passierte. Beispielsweise, Würden Sie wissen, ob die Treuepunktebank einen Fehler hatte und aus irgendeinem Grund nicht das richtige Konto eingerichtet hat? Ein Ansatz, den ich mag, um damit umzugehen, besteht darin, ein Überwachungssystem zu erstellen, das explizit der Ansicht des Geschäftsprozesses in [dem Workflow] entspricht, dann aber verfolgt, was jeder der Dienste als unabhängige Entitäten tut, sodass Sie ungerade Ausnahmen sehen können, die dem zugeordnet sind expliziterer Prozessablauf. Das [Flussdiagramm] [...] ist nicht die treibende Kraft, sondern nur eine Linse, durch die wir sehen können, wie sich das System verhält. Im Allgemeinen habe ich festgestellt, dass Systeme, die eher zum choreografierten Ansatz tendieren, lockerer gekoppelt und flexibler und veränderbarer sind. Sie müssen jedoch zusätzliche Arbeit leisten, um die Prozesse über Systemgrenzen hinweg zu überwachen und zu verfolgen. Ich habe festgestellt, dass die am stärksten orchestrierten Implementierungen extrem spröde sind und höhere Änderungskosten verursachen. In diesem Sinne strebe ich nachdrücklich ein choreografiertes System an, bei dem jeder Dienst klug genug ist, um seine Rolle im gesamten Tanz zu verstehen.

Hinweis: Bis heute bin ich mir nicht sicher, ob Choreografie nur ein anderer Name für ereignisgesteuerte Architektur (EDA) ist, aber wenn EDA nur eine Möglichkeit ist, welche anderen Möglichkeiten gibt es? (Siehe auch Was meinen Sie mit "ereignisgesteuert" und die Bedeutung der ereignisgesteuerten Architektur ). Es scheint auch, dass Dinge wie CQRS und EventSourcing viel mit diesem Architekturstil zu tun haben, oder?

Jetzt kommt der Spaß. Das Microservices-Buch geht nicht davon aus, dass Microservices mit REST implementiert werden. Tatsächlich werden im nächsten Abschnitt des Buches RPC- und SOA-basierte Lösungen und schließlich REST betrachtet. Ein wichtiger Punkt hierbei ist, dass Microservices keine REST impliziert.

Also, was ist mit HATEOAS? (Hypermedia als Engine des Anwendungsstatus)

Wenn wir nun dem RESTful-Ansatz folgen möchten, können wir HATEOAS nicht ignorieren, oder Roy Fielding wird in seinem Blog sehr gerne sagen, dass unsere Lösung nicht wirklich REST ist. Siehe seinen Blog-Beitrag zur REST-API. Muss hypertextgesteuert sein :

Ich bin frustriert über die Anzahl der Leute, die eine HTTP-basierte Schnittstelle als REST-API bezeichnen. Was muss getan werden, um den REST-Architekturstil klar zu machen, dass Hypertext eine Einschränkung darstellt? Mit anderen Worten, wenn die Engine des Anwendungsstatus (und damit die API) nicht von Hypertext gesteuert wird, kann sie nicht RESTful und keine REST-API sein. Zeitraum. Gibt es irgendwo ein kaputtes Handbuch, das repariert werden muss?

Wie Sie sehen, ist Fielding der Ansicht, dass Sie ohne HATEOAS keine wirklich RESTful-Anwendungen erstellen. Für Fielding ist HATEOAS der richtige Weg, wenn es um die Orchestrierung von Diensten geht. Ich lerne das alles nur, aber für mich definiert HATEOAS nicht klar, wer oder was die treibende Kraft hinter dem tatsächlichen Folgen der Links ist. In einer Benutzeroberfläche, die der Benutzer sein könnte, aber in Computer-zu-Computer-Interaktionen, muss dies vermutlich von einem übergeordneten Dienst durchgeführt werden.

Laut HATEOAS ist die einzige Verbindung, die der API-Verbraucher wirklich wissen muss, diejenige, die die Kommunikation mit dem Server initiiert (z. B. POST / Bestellung). Ab diesem Zeitpunkt führt REST den Fluss durch, da in der Antwort dieses Endpunkts die zurückgegebene Ressource die Links zu den nächstmöglichen Zuständen enthält. Der API-Konsument entscheidet dann, welchem ​​Link er folgen soll, und versetzt die Anwendung in den nächsten Status.

Ungeachtet dessen, wie cool das klingt, muss der Client immer noch wissen, ob der Link POSTED, PUTed, GETed, PATCHed usw. sein muss. Und der Client muss immer noch entscheiden, welche Nutzdaten übergeben werden sollen. Der Client muss weiterhin wissen, was zu tun ist, wenn dies fehlschlägt (erneut versuchen, kompensieren, abbrechen usw.).

Ich bin ziemlich neu in all dem, aber für mich ist dieser Client oder API-Konsument aus Sicht von HATEOAs ein Service hoher Ordnung. Wenn wir es aus der Perspektive eines Menschen betrachten, können Sie sich einen Endbenutzer auf einer Webseite vorstellen, der entscheidet, welchen Links er folgen soll. Dennoch musste der Programmierer der Webseite entscheiden, mit welcher Methode die Links aufgerufen werden sollen. und welche Nutzlast zu übergeben. Meiner Meinung nach übernimmt der Computer bei einer Computer-zu-Computer-Interaktion die Rolle des Endbenutzers. Dies ist wiederum ein Orchestrierungsdienst.

Ich nehme an, wir können HATEOAS entweder für Orchestrierung oder Choreografie verwenden.

Das API-Gateway-Muster

Ein weiteres interessantes Muster wird von Chris Richardson vorgeschlagen, der auch ein sogenanntes API-Gateway-Muster vorschlug .

In einer monolithischen Architektur stellen Clients der Anwendung, wie z. B. Webbrowser und native Anwendungen, HTTP-Anforderungen über einen Load Balancer an eine von N identischen Instanzen der Anwendung. In einer Microservice-Architektur wurde der Monolith jedoch durch eine Sammlung von Services ersetzt. Eine wichtige Frage, die wir beantworten müssen, ist daher, womit interagieren die Kunden?

Ein Anwendungsclient, z. B. eine native mobile Anwendung, kann RESTful HTTP-Anforderungen an die einzelnen Dienste stellen. [...] Auf den ersten Blick mag dies attraktiv erscheinen. Es ist jedoch wahrscheinlich, dass die Granularität zwischen den APIs der einzelnen Dienste und den von den Clients benötigten Daten erheblich nicht übereinstimmt. Zum Anzeigen einer Webseite können beispielsweise möglicherweise Anrufe bei einer großen Anzahl von Diensten erforderlich sein. Amazon.com beschreibt beispielsweise, wie für einige Seiten Anrufe bei mehr als 100 Diensten erforderlich sind. Das Stellen so vieler Anfragen, selbst über eine Hochgeschwindigkeits-Internetverbindung, geschweige denn über ein Mobilfunknetz mit geringerer Bandbreite und höherer Latenz, wäre sehr ineffizient und würde zu einer schlechten Benutzererfahrung führen.

Ein viel besserer Ansatz besteht darin, dass Clients eine kleine Anzahl von Anforderungen pro Seite, möglicherweise nur eine, über das Internet an einen Front-End-Server senden, der als API-Gateway bezeichnet wird.

Das API-Gateway befindet sich zwischen den Clients der Anwendung und den Microservices. Es bietet APIs, die auf den Client zugeschnitten sind. Das API-Gateway bietet mobilen Clients eine grobkörnige API und Desktop-Clients, die ein Hochleistungsnetzwerk verwenden, eine feinkörnigere API. In diesem Beispiel stellen die Desktop-Clients mehrere Anforderungen, um Informationen zu einem Produkt abzurufen, während ein mobiler Client eine einzelne Anforderung stellt.

Das API-Gateway verarbeitet eingehende Anforderungen, indem Anforderungen an eine bestimmte Anzahl von Mikrodiensten über das Hochleistungs-LAN gestellt werden. Netflix beschreibt beispielsweise, wie jede Anfrage durchschnittlich sechs Backend-Dienste auffächert. In diesem Beispiel werden fein abgestimmte Anforderungen von einem Desktop-Client einfach an den entsprechenden Dienst weitergeleitet, während jede grobkörnige Anforderung von einem mobilen Client durch Aggregation der Ergebnisse des Aufrufs mehrerer Dienste verarbeitet wird.

Das API-Gateway optimiert nicht nur die Kommunikation zwischen Clients und der Anwendung, sondern kapselt auch die Details der Microservices. Dadurch können sich die Microservices weiterentwickeln, ohne die Kunden zu beeinträchtigen. Beispielsweise könnten zwei Mikrodienste zusammengeführt werden. Ein anderer Mikrodienst kann in zwei oder mehr Dienste aufgeteilt werden. Nur das API-Gateway muss aktualisiert werden, um diese Änderungen widerzuspiegeln. Die Kunden sind nicht betroffen.

Nachdem wir uns nun angesehen haben, wie das API-Gateway zwischen der Anwendung und ihren Clients vermittelt, wollen wir uns nun ansehen, wie die Kommunikation zwischen Microservices implementiert wird.

Dies klingt dem oben erwähnten Orchestrierungsstil ziemlich ähnlich, nur mit einer etwas anderen Absicht. In diesem Fall scheint es nur um Leistung und Vereinfachung der Interaktionen zu gehen.

Der Versuch, die verschiedenen Ansätze hier zusammenzufassen.

Domänenereignisse

Der vorherrschende Ansatz hierfür scheint die Verwendung von Domänenereignissen zu sein, bei denen jeder Dienst Ereignisse in Bezug auf das Geschehene veröffentlicht und andere Dienste diese Ereignisse abonnieren können. Dies scheint Hand in Hand zu gehen mit dem Konzept von intelligenten Endpunkten, dummen Rohren , das von Martin Fowler hier beschrieben wird: http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes

Proxy

Ein weiterer Ansatz, der häufig vorkommt, besteht darin, den Geschäftsfluss in einen eigenen Service zu integrieren. Wo der Proxy die Interaktion zwischen den Mikrodiensten koordiniert, wie im folgenden Bild gezeigt:

.

Andere Muster der Komposition

Diese Seite enthält verschiedene Kompositionsmuster.

Wie unterscheidet sich die Orchestrierung von Mikrodiensten von der Orchestrierung alter SOA-Dienste, die nicht „Mikro“ sind? Gar nicht viel.

Microservices kommunizieren normalerweise über http (REST) ​​oder Messaging / Ereignisse. Orchestrierung wird häufig mit Orchestrierungsplattformen verknüpft, mit denen Sie eine Skriptinteraktion zwischen Diensten erstellen können, um Workflows zu automatisieren. In den alten SOA-Tagen verwendeten diese Plattformen WS-BPEL. Die heutigen Tools verwenden kein BPEL. Beispiele für moderne Orchestrierungsprodukte: Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker.

Beachten Sie, dass Orchestrierung ein zusammengesetztes Muster ist, das verschiedene Funktionen zum Erstellen komplexer Zusammenstellungen von Diensten bietet. Mikrodienste werden häufiger als Dienste angesehen, die nicht an komplexen Zusammensetzungen teilnehmen sollten, sondern autonomer sind.

Ich kann sehen, dass ein Mikrodienst in einem orchestrierten Workflow aufgerufen wird, um eine einfache Verarbeitung durchzuführen, aber ich sehe keinen Mikrodienst als Orchestrator-Dienst, der häufig Mechanismen wie das Kompensieren von Transaktionen und das Status-Repository (Dehydration) verwendet.

Sie haben also zwei Dienste:

1. Rechnungsmikroservice
2. Versand Micro Service

Im wirklichen Leben hätten Sie etwas, wo Sie den Bestellstatus halten. Nennen wir es Bestellservice. Als nächstes haben Sie Anwendungsfälle für die Auftragsabwicklung, die wissen, was zu tun ist, wenn der Auftrag von einem Zustand in einen anderen übergeht. Alle diese Dienste enthalten einen bestimmten Datensatz, und jetzt benötigen Sie etwas anderes, das die gesamte Koordination übernimmt. Das könnte sein:

• Eine einfache Benutzeroberfläche, die alle Ihre Dienste kennt und die Anwendungsfälle implementiert ("Ich bin fertig" ruft den Versanddienst auf).
• Eine Geschäftsprozess-Engine, die auf ein Ereignis "Ich bin fertig" wartet. Dieser Motor implementiert die Anwendungsfälle und den Ablauf.
• Ein Orchestrierungs-Mikrodienst, beispielsweise der Auftragsabwicklungsdienst selbst, der den Ablauf / die Anwendungsfälle Ihrer Domain kennt
• An alles andere habe ich noch nicht gedacht

Der Hauptpunkt dabei ist, dass die Steuerung extern ist. Dies liegt daran, dass alle Ihre Anwendungskomponenten einzelne Bausteine ​​sind, die lose miteinander verbunden sind. Wenn sich Ihre Anwendungsfälle ändern, müssen Sie eine Komponente an einem Ort ändern, nämlich die Orchestrierungskomponente. Wenn Sie einen anderen Auftragsfluss hinzufügen, können Sie problemlos einen weiteren Orchestrator hinzufügen, der den ersten nicht beeinträchtigt. Beim Denken in Bezug auf Mikrodienste geht es nicht nur um Skalierbarkeit und ausgefallene REST-APIs, sondern auch um eine klare Struktur, geringere Abhängigkeiten zwischen Komponenten und die Wiederverwendung gemeinsamer Daten und Funktionen, die in Ihrem Unternehmen gemeinsam genutzt werden.

HTH, Mark

Wenn der Staat verwaltet werden muss, ist das Event Sourcing mit CQRS die ideale Art der Kommunikation. Andernfalls kann ein asynchrones Nachrichtensystem (AMQP) für die Kommunikation zwischen Mikroservices verwendet werden.

Aus Ihrer Frage geht hervor, dass die ES mit CQRS die richtige Mischung sein sollte. Wenn Sie Java verwenden, werfen Sie einen Blick auf das Axon-Framework. Oder erstellen Sie eine benutzerdefinierte Lösung mit Kafka oder RabbitMQ.

Ich habe einige Beiträge zu diesem Thema geschrieben:

Vielleicht können diese Beiträge auch helfen:

API-Gateway-Muster - Kurskörnige API im Vergleich zu feinkörnigen APIs

https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/

Grobkörnige vs feinkörnige Service-API

Per Definition hat ein grobkörniger Dienstbetrieb einen breiteren Anwendungsbereich als ein feinkörniger Dienst, obwohl die Begriffe relativ sind. Grobkörnig erhöht die Designkomplexität, kann jedoch die Anzahl der zum Ausführen einer Aufgabe erforderlichen Aufrufe verringern. Bei einer Mikrodienstarchitektur kann sich eine grobkörnige Architektur auf der API-Gateway-Ebene befinden und mehrere Mikrodienste orchestrieren, um einen bestimmten Geschäftsbetrieb abzuschließen. Grobkörnige APIs müssen sorgfältig so konzipiert werden, dass sie mehrere Mikrodienste umfassen, bei denen die Verwaltung unterschiedlicher Fachgebiete das Risiko birgt, Bedenken in einer einzelnen API zu vermischen und gegen die oben beschriebenen Regeln zu verstoßen. Grobkörnige APIs können eine neue Granularitätsstufe für Geschäftsfunktionen vorschlagen, die sonst nicht vorhanden sind. Beispielsweise kann die Einstellung eines Mitarbeiters zwei Microservices-Anrufe an das HR-System zum Erstellen einer Mitarbeiter-ID und einen weiteren Anruf an das LDAP-System zum Erstellen eines Benutzerkontos umfassen. Alternativ kann der Client zwei feinkörnige API-Aufrufe ausgeführt haben, um dieselbe Aufgabe zu erfüllen. Während grobkörnig das Erstellen eines Benutzerkontos für den Geschäftsanwendungsfall darstellt, repräsentiert feinkörnige API die Funktionen, die mit einer solchen Aufgabe verbunden sind. Eine feinkörnigere API kann verschiedene Technologien und Kommunikationsprotokolle beinhalten, während eine grobkörnige API sie in einen einheitlichen Fluss abstrahiert. Berücksichtigen Sie beim Entwerfen eines Systems beides, da es wiederum keinen goldenen Ansatz gibt, der alles löst, und es gibt für jeden einen Kompromiss. Grobkörnig eignen sich besonders als Dienste, die in anderen Geschäftskontexten wie anderen Anwendungen verwendet werden sollen.

Die Antwort auf die ursprüngliche Frage lautet SAGA-Muster.