Microservices gegenüber der üblichen SOA-Implementierung

Als ich zum ersten Mal über MSA-Architekturen (MSA) las, fiel es mir schwer, herauszufinden, was sich so sehr von einer serviceorientierten Architektur (SOA) unterscheidet. Der Hauptgrund dafür ist, dass das SOA-Paradigma viel Spielraum für Interpretationen lässt und verschiedene Leute unterschiedliche Interpretationen haben. Als Martin Fowler vor fast einem Jahr über MSA schrieb, erwähnte er auch, dass manche Leute es als "SOA done right" ansehen, er selbst betrachtet MSA als eine Untermenge von SOA. Was sind also die Unterschiede, wenn überhaupt? Auf den ersten Blick scheint es mehr als nur ein paar Gemeinsamkeiten zu geben. Beide sprechen von Diensten als Eckpfeiler der Architektur, Dienste müssen lose gekoppelt und technologieunabhängig sein und es gibt wahrscheinlich noch ein paar mehr. Was den Architekturstil Microservices von anderen unterscheidet, ist die Tatsache, dass klarer ist, wo der Schwerpunkt bei der Entwicklung Ihrer Dienste liegen muss. Der Name legt nahe, dass die Dienste sehr klein und wahrscheinlich sehr feinkörnig sein müssen, aber in Wirklichkeit gibt es keine Größenbeschränkungen. Ironischerweise sind es gerade die Größe (und der Fokus) der Dienste, die SOA-Implementierungen häufig lähmen. Die wichtigsten Merkmale von MSA sind: Autonomie, hohe Kohäsion und geringe Kopplung. Von diesen Merkmalen ist die Autonomie das entscheidende. Autonomie bedeutet hier nicht nur, dass er unabhängig laufen oder funktionieren kann (darum geht es bei geringer Kopplung), sondern auch, dass ein Dienst in der Lage sein sollte, eigenständig einen geschäftlichen Nutzen zu erbringen. Dieses Prinzip verbindet den Fokus auf geringe Kopplung und hohe Kohäsion. Eine geringe Kopplung ermöglicht es dem Dienst, unabhängig zu operieren, und eine hohe Kohäsion erhöht seine Fähigkeit, selbständig einen Mehrwert zu schaffen. Was Sie bei SOA-Implementierungen häufig sehen, ist der Fokus auf Wiederverwendung. Das bedeutet, dass eine bestimmte Funktion nur an einer Stelle vorhanden sein sollte oder dass ein einziger Dienst eine bestimmte Funktion ausführen sollte. Der Haken an der Sache ist, wie diese "Funktionen" festgelegt werden. Hier kommt die Kohäsion ins Spiel. Kohäsion ist der Grad, in dem die Funktionen in Diensten zusammengehören. Die höchste Kohäsion ist die funktionale Kohäsion, bei der die Dienste zu einer genau definierten Aufgabe oder Geschäftsfähigkeit beitragen. MSA strebt eine funktionale (hohe) Kohäsion an. Die Kohäsion, die in den gängigen SOA-Implementierungen zu finden ist, ist die logische Kohäsion (eine Stufe höher als die schlechteste Art, die zufällige Kohäsion). Bei der logischen Kohäsion werden die Dienste um ähnliche Aufgaben herum gruppiert, wie der oben erwähnte eine Dienst für eine Funktion. Dieser Ansatz führt zu feinkörnigeren Diensten, die sich auf atomare Aufgaben konzentrieren. Nehmen Sie zum Beispiel einen "Datendienst", der die gesamte Kommunikation mit einer Datenbank abwickelt. Er nimmt Nachrichten in einem gemeinsamen Format entgegen und verwendet dann diese Informationen, um die gewünschte Aktion in der Datenbank auszuführen. Der Vorteil ist, dass Anwendungen, die diesen Dienst nutzen, sich nicht um die Technik hinter dem Dienst kümmern müssen, sondern nur Nachrichten in einem gemeinsamen Format bereitstellen müssen. Wenn die Datenbank von mehreren Diensten gemeinsam genutzt wird, verwenden sie alle diesen Dienst für die Kommunikation mit der Datenbank. Stellen Sie sich nun vor, was passieren würde, wenn dieser Dienst ausfällt (absichtlich oder unabsichtlich). Oder welche Auswirkungen es hat, wenn dieser Dienst geändert werden muss. Und das alles unter der Annahme, dass dieser Dienst gut konzipiert und aufgebaut ist, so dass er all die verschiedenen Anfragen bewältigen kann, die an ihn gerichtet werden. Bei MSA sollte das Ziel eine hohe Kohäsion sein, d.h. die Gruppierung von Dingen um eine Geschäftsfähigkeit herum (so dass sie einen geschäftlichen Mehrwert schaffen kann). Außerdem werden alle Aspekte dieser Fähigkeit von Anfang bis Ende bereitgestellt, von der Datenspeicherung bis zu den Funktionen der Benutzeroberfläche. Statt eines "Datenservice" erstellen Sie also einen "Kundenservice" oder einen "Versandservice". Ein weiterer Aspekt, der hier von Bedeutung ist, ist, dass Sie bei MSA eine geringe Kopplung (oder besser keine Kopplung) anstreben sollten. Geringe Kopplung läuft auf die Abhängigkeit zwischen den Diensten hinaus. Wenn keine Kopplung besteht, können die Dienste völlig unabhängig voneinander funktionieren. Wenn zwei Dienste nicht gekoppelt sind, hat die Ausfallzeit eines der beiden Dienste keinerlei Auswirkungen auf den anderen. Je höher die Kopplung, desto größer die Auswirkungen. Bei SOA-Implementierungen, die auf logischer Kohäsion basieren, ist die Kopplung tendenziell hoch. Denn Dienste sind auf andere Dienste angewiesen, um zu funktionieren. Eine hohe Kopplung erhöht die Auswirkungen von Änderungen. Bei MSA ist das Ziel keine Kopplung. Eine geringere Kopplung bedeutet jedoch nicht, dass die Dienste nicht interagieren können oder sollten. Dienste können immer noch mit anderen Diensten interagieren, aber sie sind nicht von ihnen abhängig. Ein weiterer Unterschied ist, dass es sich hier eher um technische Abhängigkeiten handelt, nicht um funktionale Abhängigkeiten. Nehmen Sie zum Beispiel einen Bestelldienst und einen Versanddienst. Beide können unabhängig voneinander arbeiten. Der Versanddienst wird alle bei ihm eingegangenen Bestellungen bearbeiten, unabhängig von der Verfügbarkeit eines Bestelldienstes. Wenn der Bestelldienst nicht verfügbar ist, bedeutet dies lediglich, dass keine neuen Bestellungen für den Versanddienst erstellt werden. Wenn der Versanddienst also seine letzte bekannte Bestellung bearbeitet hat, wird er angehalten. Umgekehrt kann der Bestelldienst, wenn der Versanddienst ausgefallen ist, immer noch Bestellungen bearbeiten. Sie werden nur nicht vom Versanddienst bearbeitet. Wenn der Versanddienst wieder funktioniert, bearbeitet er den vom Bestelldienst angelegten Rückstand. Inwieweit sich der Architekturstil von Microservices von SOA unterscheidet, hängt davon ab, mit wem Sie sprechen. Zumindest bietet MSA einen klareren und besser definierten Ansatz für den Aufbau einer Architektur, die auf Diensten basiert. Das Hauptunterscheidungsmerkmal ist die Konzentration auf die autonome Wertschöpfung. Es gäbe noch viel mehr zu diesem Thema zu sagen, aber ich hoffe, dass dies einen Einblick gibt, wie sich MSA von dem unterscheidet, was Sie typischerweise bei SOA-Implementierungen sehen.