Serviceorientierte Architektur vs. Microservices-Architektur: Vergleich von SOA mit MSA

In der Informatik bezeichnet ein Dienst eine einzelne oder kollektive Softwareeinheiten, die sich wiederholende, redundante Aufgaben ausführen. Im Zeitalter des Cloud-Computings bestehen Anwendungen aus einer Sammlung von Diensten, die gemeinsam verschiedene Funktionen erfüllen, um die Gesamtfunktionalität der Anwendung zu unterstützen. In diesem Artikel untersuchen wir die Microservices-Architektur (MSA) und die Service-Oriented Architecture (SOA) als zwei gängige dienstbasierte Architekturen – wie beide auf Services als Hauptkomponente basieren und sich in Bezug auf Service-Eigenschaften unterscheiden. Schauen wir uns das an.

Was ist eine serviceorientierte Architektur (SOA)?

Eine dienstorientierte Architektur folgt einem Design mehrerer eigenständiger, diskreter und wiederholbarer Dienste, die gemeinsam ein Service-Mesh der Funktionalitäten einer Anwendung ganzheitlich bilden. Dies ermöglicht es einem Rahmenwerk von Anwendungskomponenten, mit anderen Komponenten zu interagieren und Dienstleistungen anzubieten, indem es eine Serviceschnittstelle (Kommunikationsprotokoll) nutzt.

SOA-Designprinzipien

Die Prinzipien einer Service Oriented Architecture können je nach Anwendungsfall unterschiedlich sein. Hier sind einige gängige Prinzipien, die Services zu einer SOA trennen:

• Abstraktion
• Wiederverwendbarkeit
• Granularität
• Standardisierter Vertrag
• Autonomie
• Staatenlosigkeit
• Entdeckung

Merkmale von SOA

Ein grundlegender Anwendungsfall einer SOA besteht darin, eine Anwendung durch die gemeinsame Nutzung mehrerer unterschiedlicher Dienste zu erstellen, wobei jeder Dienst aus einer einzigartigen Geschäfts- oder Anwendungslogik besteht. Darüber hinaus sind einige gemeinsame Funktionen von SOA:

• "So viel wie möglich teilen"-Architektur
• Bedeutung für die Wiederverwendung von Geschäftsfunktionen
• Gemeinsame Governance und Standards
• Enterprise Service Bus (ESB) für die Kommunikation
• Mehrfache Nachrichtenprotokolle
• Gemeinsame Plattform für alle darauf bereitgestellten Dienste
• Multithreaded mit mehr Overheads zur Bearbeitung von I/O
• Maximale Wiederverwendbarkeit von Anwendungsdiensten
• Eher die Verwendung traditioneller relationaler Datenbanken
• Nicht bevorzugt in einem DevOps-Modell

Was ist eine Microservice-Architektur (MSA)?

Eine Microservice-Architektur, oft als Microservices bekannt, folgt einem SOA-Muster, indem sie eine einzelne Anwendung in mehrere lose gekoppelte, unabhängige Services aufteilt, die aber miteinander arbeiten. Microservices werden oft als perfekter Anwendungsfall der Containerisierung betrachtet, da es für Organisationen ziemlich üblich ist, jeden dieser Microservices auf separaten Containern bereitzustellen. Dies ermöglicht ein effizientes Framework aus mehreren Diensten, die flexibel, portabel und plattformunabhängig sind – sodass jeder Service unterschiedliche Betriebssysteme und Datenbanken haben kann, während er in seinem eigenen Prozess läuft.

Eigenschaften von MSA

• "So wenig wie möglich teilen"-Architektur
• Bedeutung für das Konzept des begrenzten Kontexts
• Entspannte Regierungsführung mit mehr Fokus auf die Menschen
• Effiziente Zusammenarbeit und Freiheit bei der Wahl von Plattform und Technologien
• Einfaches, weniger aufwendiges Messaging-System
• Leichtgewichtige Protokolle wie HTTP/REST und AMQP
• Single-threaded in der Regel mit Verwendung von Event Loop-Funktionen für nicht sperrende I/O-Bearbeitung
• Container funktionieren in MSA sehr gut und gelten als perfekt für ein DevOps-Modell
• Fokussierter auf Entkopplung
• Verwendet moderne, nicht-relationale Datenbanken

Microservices vs. SOA: Hauptunterschiede

Schauen wir uns die wichtigsten Unterschiede zwischen SOA und MSA an.

Koordination

SOA erfordert die Koordination mit mehreren Gruppen, um Geschäftsanfragen zu erstellen. Im Gegenteil, es gibt kaum oder gar keine Koordination zwischen den Diensten in einem MSA. Falls Koordination zwischen den Dienstinhabern erforderlich ist, erfolgt dies über kleine Anwendungsentwicklungsteams, und Dienste können schnell entwickelt, getestet und bereitgestellt werden.

Servicegranularität

Das Präfix "micro" in Microservices bezieht sich auf die Granularität ihrer internen Komponenten. Servicekomponenten innerhalb von MSA sind im Allgemeinen Einzweckdienste, die eine Sache wirklich gut erfüllen. Services in SOA enthalten in der Regel viel mehr Geschäftsfunktionalität und werden oft als vollständige Subsysteme implementiert.

Komponententeilung

SOA verbessert das Teilen von Komponenten, während MSA versucht, das Teilen durch "begrenzten Kontext" zu minimieren. Ein beschränkter Kontext bezeichnet die Kopplung einer Komponente und ihrer Daten als eine einzige Einheit mit minimalen Abhängigkeiten. Da SOA auf mehrere Dienste angewiesen ist, um eine Geschäftsanforderung zu erfüllen, sind Systeme, die auf SOA basieren, wahrscheinlich langsamer als MSA.

Middleware vs. API-Schicht

Die Messaging-Middleware in SOA bietet eine Vielzahl zusätzlicher Funktionen, die in MSA nicht vorhanden sind, darunter:

• Mediation und Routing
• Nachrichtenverbesserung
• Nachrichten- und Protokolltransformation

MSA verfügt über eine API-Schicht zwischen Diensten und Service-Konsumenten.

Ferndienste

SOA-Architekturen basieren auf Messaging (AMQP, MSMQ) und SOAP als primären Remote-Access-Protokollen. Die meisten MSAs basieren auf zwei Protokollen – REST und Simple Messaging (JMS, MSMQ) – und das in MSA gefundene Protokoll ist in der Regel homogen. Heterogene Interoperabilität SOA fördert die Verbreitung mehrerer heterogener Protokolle durch seine Messaging-Middleware-Komponente. MSA versucht, das Architekturmuster zu vereinfachen, indem die Anzahl der Integrationsoptionen reduziert wird.

• Wenn Sie mehrere Systeme mit unterschiedlichen Protokollen in einer heterogenen Umgebung integrieren möchten, müssen Sie SOA in Betracht ziehen.
• Wenn alle deine Dienste über dasselbe Remote-Access-Protokoll zugänglich gemacht und zugänglich sein könnten, ist MSA die bessere Option.

Vertragsentkopplung

Vertragsentkopplung ist der heilige Gral der Abstraktion. Sie bietet das größte Maß an Entkopplung zwischen Diensten und Konsumenten. Sie ist eine der grundlegenden Funktionen innerhalb von SOA – aber MSA unterstützt keine Vertragsentkopplung.

Welche Architektur sollte man wählen?

Hier sind einige wichtige Überlegungen bei der Wahl eines der Muster:

• SOA eignet sich besser für große und komplexe Geschäftsanwendungen , die Integration mit vielen heterogenen Anwendungen erfordern. Workflow-basierte Anwendungen mit einem klar definierten Verarbeitungsfluss sind jedoch etwas schwierig mit SOA-Mustern umzusetzen. Kleine Anwendungen eignen sich auch nicht gut für SOA, da sie keine Messaging-Middleware-Komponente benötigen.
• Das MSA-Muster eignet sich gut für kleinere und gut partitionierte webbasierte Systeme. Das Fehlen einer Messaging-Middleware ist einer der Hauptgründe, warum MSA für komplexe Umgebungen ungeeignet ist.
• Steuerung vs. Orchestrierung. Bei der Entwicklung einer Anwendung von Grund auf gilt die Nutzung von MSA als pragmatische Wahl, da es als Entwickler mehr Kontrolle bietet. Andererseits gilt SOA, wenn das Ziel ist, Geschäftsprozesse zu orchestrieren, als inaktiv, da es das richtige Framework bietet.
• Frühphasen- vs. reifere Organisationen. Unternehmen in einem frühen Stadium könnten MSA als ideale Wahl ansehen. Mit dem Wachstum des Unternehmens benötigen Organisationen möglicherweise Fähigkeiten wie komplexe Anfragetransformationen und heterogene Systemintegration. In solchen Situationen greifen Organisationen oft auf das SOA-Muster zurück, um MSA zu ersetzen.

Sowohl SOA als auch MSA folgen einem identischen Dienstmuster auf verschiedenen Ebenen eines Unternehmens. Die Existenz von MSA hängt vom Erfolg des SOA-Musters ab und wird daher oft als Teilmenge von SOA bezeichnet. Während sowohl Microservices als auch eine Service-Oriented Architecture ausschließlich darauf abzielen, eine Anwendung in mehrere Services aufzuteilen, disaggregiert eine MSA die Dienste auf Anwendungsebene, während eine SOA dies bei einer unternehmensweiten Service-Wiederverwendbarkeit tut.

Verwandte Literatur

• BMC DevOps Blog
• Microservices vs. Nanoservices: Abwägungsrahmenoptionen
• Microservices vs. Serverless: Was ist der Unterschied?
• Herausforderungen von Microservices und wann man sie vermeiden sollte
• Kubernetes vs. Docker Swarm: Vergleich von Container-Orchestrierungstools
• Der Zustand der Container heute: Eine Berichtszusammenfassung

Original-Referenzbilder:

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.