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.
.