it-swarm.com.de

Warum ESB in der Microservices-Architektur als schlecht angesehen wird

In der Microservices-Architektur sollten autonome Unternehmensdienste direkt miteinander kommunizieren. Die Kommunikation kann synchron (Orchestrierung) oder ereignisbasiert (Choreografie) sein. Ein API-Gateway kann die APIs für den Client zusammenfassen (Backends für Frontends). Mit microservices streben wir zwei ultimative Ziele an

  • Geringe Kopplung
  • Hoher Zusammenhalt

Dies garantiert eine kontinuierliche Bereitstellung, eine fein abgestimmte Skalierung, eine schnelle Technologieanpassung, Wiederverwendbarkeit und Überprüfbarkeit - natürlich zu einem Preis höherer Komplexität.

Es wird jedoch dringend davon abgeraten, ESB (Enterprise Service Bus) oder andere Middleware zu verwenden. Microservices und ESB werden oft als konkurrierende Lösungen angesehen. Warum wird ein ESB so schlecht gesehen? Solange es nur als Meditationskanal mit einigen zusätzlichen Überwachungs- und Authentifizierungsebenen verwendet wird (keine Geschäftslogik), was ist das Problem bei der Verwendung in der Microservice-Architektur?

15
Tuomas Toivonen

Ich habe zwei ESB-Rollouts in verschiedenen Unternehmen miterlebt, in beiden Fällen mit dem gleichen ehrgeizigen Ziel, lediglich bei der Überwachung und Authentifizierung zu helfen und "besseren" Zugang zu Legacy-Systemen zu ermöglichen. In beiden Fällen wurde der ESB in nur ein bis zwei Jahren zu einer einzigen Fehlerquelle, einem Engpass für Veränderungen und im Allgemeinen zu einer Hürde für alle Projekte.

ESBs sind einfach zu praktisch , um sie nicht zu verwenden. Zuerst fügen Sie nur ein spezielles Routing für eine Nachricht hinzu, die Sie an ein System senden möchten, und dann lösen Sie schnell die Übersetzung einer XML-Nachricht in ein anderes Format, da Sie dies können. Anschließend fügen Sie weitere XSLTs oder ähnliches hinzu, um ein Versionsupdate zu installieren, dessen Behebung im Client-System zu teuer wäre. Und so weiter...

In Kürze haben Sie die Geschäftslogik . Alle Teams müssen sich mit dem ESB-Team bezüglich aller Rollouts, neuer Nachrichten oder sogar Änderungen der Nachrichtenformate abstimmen. Es wird die Unabhängigkeit töten (die niedrige Kopplung) Ihrer Teams.

Der Sinn der Microservices-Architektur besteht, wie Sie bereits betont haben, darin, autonomen Betrieb nicht nur für den Service, sondern auch für sein Team zu aktivieren. Dies ermöglicht einen schnellen Wechsel. Im Idealfall würde dies bedeuten:

  • Vermeiden Sie Synchronisationspunkte mit anderen Teams, sei es zum Testen, zum Rollout, zur Konfiguration oder zum Betrieb (d. H. Sie müssen funktionsübergreifend arbeiten und DevOps usw. ausführen).
  • Vermeiden Sie die Laufzeit von Synchronisationspunkten mit anderen Diensten. Dies bedeutet, dass synchrone Anrufe unabhängig von der Technologie vermieden werden. Sie sollten nur Feuer-und-Vergessen-Aktionen ausführen und niemals eine Antwort anfordern, auch wenn die Antwort zu einem späteren Zeitpunkt eingeht.
  • Vermeiden Sie Abhängigkeiten zu anderen Teams. Dies bedeutet, dass Code-Sharing (von Code mit Geschäftslogik oder geschäftsrelevanten Objekten) vermieden wird.

Grundsätzlich sollten Sie in der Lage sein, Ihren Mikroservice weiter zu betreiben (und neue Versionen einzuführen), auch wenn der Rest des Unternehmens seinen Betrieb eingestellt hat und in den Urlaub gefahren ist.

Natürlich ist das ein "idealisiertes" Szenario, aber ein ESB widerspricht definitiv allen oben genannten Zielen. Es ist ein Synchronisationspunkt, eine zentrale Abhängigkeit sowohl zur Laufzeit als auch organisatorisch.

21