Verwirrt über ESBs als Lösung für Punkt-zu-Punkt-Integration

Question

Immer noch sehr neu, um Anwendungsarchitektur zu studieren und einige Ideen in einem Buch über Microservices zu stählen. In meinen Lesungen stieß ich auf die ältere Idee der ESBs (Enterprise Service Bus) und ihre Rolle bei der Koordinierung von Nachrichten zwischen neuen Diensten und Legacy-Anwendungen. ESBs werden als Lösung für Probleme, die durch Punkt-zu-Punkt-Integration entstehen, angepriesen. Microservices scheinen der Ansatz zu sein, den neuere Unternehmen als De-facto-Standard für die Erstellung einer agilen, skalierbaren und ausfallsicheren App verwenden. Aber sind Microservices keine Punkt-zu-Punkt-Integration? Jeder Knoten in einer von Microservices erstellten Anwendung kommuniziert direkt mit anderen Knoten, richtig? Ich fühle, dass ich einige Punkte verbinde, die nicht verbunden werden sollten. Jede Hilfe sehr geschätzt, danke im Voraus.

Answer 1

Microservices müssen nicht unbedingt verlassen auf Punkt-zu-Punkt-Integration.

Die mit direkter Kommunikation verbundenen Probleme werden häufig in einer Microservice-Architektur mithilfe eines Nachrichtenbrokers verwaltet. Wenn die Kommunikation asynchron erfolgen kann - "Feuer und Vergessen" - wird die Anwendung, die eine Nachricht sendet, nicht funktionsunfähig, wenn der Empfänger ausfällt. Und die Nachrichten werden immer noch da sein, wenn der empfangende Dienst wieder kommt.

Wenn Microservices über REST integriert werden, muss der Aufrufer wissen, wie er reagieren soll, wenn der andere Dienst nicht antwortet. Da dies haarig wird, wenn Sie Daten systemübergreifend speichern (z. B. eine verteilte Transaktion), verwende ich REST nur für Datenabruf-APIs. Und machen Sie alle Einsparungen als Folge von Nachrichten.

Es ist wichtig zu beachten, dass es viel mehr zu ESBs als nur Messaging gibt. See more on that in the answer here.

Answer 2

ESBs sind Lösungen, die in vielen Unternehmen implementiert wurden, um die Interoperabilität und Rückverfolgbarkeit von Anwendungen sicherzustellen. Da es sich jedoch um schwere Lösungen handelt, die keine horizontale Skalierung zulassen, verwenden die ESBs normalerweise eine Konfiguration mit zwei aktiven oder passiven Knoten.

Auf der anderen Seite werden Dienste in ESB normalerweise nicht einzeln, sondern in Bereitstellungspaketen zusammen mit anderen Diensten bereitgestellt, wodurch die Verwaltung und Prüfung der Zustellung komplizierter wird.

Microservices sind so konzipiert, dass sie individuell entwickelt und implementiert werden können, so dass innerhalb einer Cloud-Infrastruktur die Anzahl der Instanzen dynamisch horizontal skaliert werden kann.

Die Interoperabilität zwischen Anwendungen ist derzeit in den Hintergrund gerückt, da die heutige Kommunikation über Webdienste praktisch alltäglich ist, obwohl einige Middleware, die Konnektivität löst, in einigen sehr alten Infrastrukturen noch benötigt wird.

Answer 3

Beide Ansätze sind nicht notwendig exklusiv. Microservices können unter Verwendung einer Messaging-Middleware (Kafka, AMQP, Akka-Aktoren, JMS ...) anstelle von direkten http-Kanälen kommunizieren. Dies hängt von Ihren Constraint- (hauptsächlich Konsistenz-) und Implementierungsrichtlinien ab.

Jede Wahl, seine Stärken und Schwächen hat, rate ich persönlich nicht, sich zu einem Ansatz zu beschränken, sondern beide zu verwenden und wählen entsprechend jeder Situation

Siehe Microservices: REST vs Messaging und https://capgemini.github.io/architecture/is-rest-best-microservices/

Answer 4

Microservices sind kein Ersatz für ESB.

Microservices ist ein Konzept für die Entwicklung von Backend-Systemen, einschließlich seiner API.Das Gegenteil von Microservices Ansatz ist ein Monolith. Wenn die API direkt von den konsumierenden Systemen konsumiert wird, kommen wir zur Punkt-zu-Punkt-Integration (Spaghetti). Wenn der Kunde eine Middleware verwendet, die oft API-Gateway genannt wird, können wir eine zentralisierte Sichtbarkeit, Sicherheit und Ablaufverfolgung (wie bei ESB) haben. API-Gateways sind einfacher als ESBs und eignen sich daher besser für die horizontale Skalierung. API-Gateways sollten keine zusätzliche Geschäfts-/Integrationslogik enthalten.

ESB tut das gleiche wie API-Gateway (fungiert als Proxy), aber zusätzlich ermöglicht es, Business-Logik zu integrieren, mehrere Dienste in einer oder anderen erweiterten Funktionen zu komponieren. ESBs wuchsen oft zu lästigen Lösungen mit hohem Overhead und nur geringem Mehrwert, und deshalb wurden sie gehasst.

Fazit

ESB zusammen mit Microservices Architektur verwendet werden können, gibt es viele Unternehmen, die ESB halten einfach und es ist fast gleich so API-Gateways genannt.

Meine Meinung

API-Gateways werden die Einführung neuer Funktionalitäten und werden immer komplexer, näher an ESB kommen.