it-swarm.com.de

Microservices: Was sind intelligente Endpunkte und dumme Pipes?

Ich habe einen Artikel " Microservices " von Martin Fowler gelesen und finde es schwierig, Smart Endpoint s und Dumb Pipes zu verstehen. Bitte erläutern Sie diese Begriffe, Beispiele sind willkommen.

15
Ivan Voroshilin

Ich habe den Artikel nicht gelesen, also kann ich nur spekulieren, was er genau bedeuten kann. Da er jedoch ESB als Beispiel gegen Microservices und ZeroMQ als Beispiel für Mikrodienstleistungen nennt, hoffe ich, dass meine Spekulation ziemlich genau ist:

Eine der Ideen von Unix (und Linux) besteht darin, kleine unabhängige Anwendungen zu erstellen und diese über Pipes zu verbinden. Der wahrscheinlich häufigste Satz von zwei Befehlen, den ich verwende, ist ps und grep wie folgt: ps aux | grep PROCESS_NAME - hier sehen Sie eine Dumb Pipe, die nur die Ausgabe von ps an stdin von grep weiterleitet. 

Andere Messaging-Systeme wie ZeroMQ funktionieren ähnlich, obwohl sie etwas komplexer sein können, wie die Round-Robin-Verteilung und die zuverlässige Bereitstellung. Erlang als Sprache ist auf kleinen intelligenten Endpunkten aufgebaut, die Nachrichten untereinander senden. Die Vorteile liegen auf der Hand und werden auch in dem Artikel erwähnt. Kleine Anwendungen sind leichter zu warten, die Entkopplung erleichtert das Skalieren.

Auf der anderen Seite sind Microservices am häufigsten große Unternehmensanwendungen, wie der erwähnte Enterprise Service Bus. Ich habe nicht wirklich genug mit diesen zusammengearbeitet, um Ihnen ein bestimmtes Beispiel zu geben, aber im Allgemeinen enthalten diese Busse eine Vielzahl von Funktionen, die entweder über Skripts oder über die Konfiguration enthalten sind. Diese Funktionalität umfasst meistens einen konfigurierbaren Workflow mit erweitertem Routing und kann sogar die Nachrichten transformieren, sodass unterschiedliche Endpunkte sie verarbeiten können.

Ein Beispiel könnte sein: Wenn Sie möchten, dass Sie eine Vorabaktion in einem System durchführen, z. B. die Anforderungen in einem bereits laufenden Projekt ändern, könnte dies einen Workflow starten, bei dem der ESB automatisch unterschiedliche Benachrichtigungen an verschiedene Akteure in Bezug auf die geänderten Anforderungen sendet und warten Sie, bis ein oder mehrere dieser Akteure bestätigt sind, bevor diese Änderung angewendet wird. Dies wäre im Grunde das Gegenteil - dumme Endpunkte (die nur Daten an den Bus senden/von diesem empfangen) und eine sehr intelligente Pipe (der Bus, der konfiguriert werden kann, um alle möglichen Unternehmensszenarien zu behandeln).

Ich bin ziemlich zuversichtlich, dass es Enterprise-Service-Busse gibt, die ähnliche Szenarien abwickeln. Dies ist das Gegenteil von einfachen "dummen" ZeroMQ-artigen Message-Passing-Frameworks.

Grundsätzlich muss die Logik irgendwo implementiert werden - entweder im großen ESB oder in den Endpunkten. Die Idee der Microservices besteht darin, sie in die Endpunkte und nicht in den Bus zu integrieren und eine ähnliche Philosophie zu haben wie Unix-Anwendungen.

14
peter

Ich denke, dass Martin Fowlers Artikel wahnsinnig kurz ist, weil er das ESB-Konzept falsch zeichnet. Diese Fehlcharakterisierung ist weit verbreitet. Wie oft haben Sie ein Diagramm gesehen, das den "Bus" als eine Leitung darstellt, durch die die Nachrichten fließen? Ich habe sicherlich die Zählung verloren und es macht mich jedes Mal zusammenzucken. Ein „Bus“ ist keine Pipe. Es ist ein Mechanismus, mit dem "Enabled Services" in einer verteilten, serviceorientierten Umgebung leicht zugänglich sind. Die klassische Analogie ist eine Sammelschiene in einer Fabrik. Obwohl Strom durch die Sammelschiene fließt, ist dies nicht der Grund dafür, dass es sich um einen „Bus“ handelt. Es ist ein „Bus“, weil er die gesamte Länge der Fertigungshalle durchläuft. Jede Maschine (Service-Implementierungen) kann leicht in die Bar einrasten, um Strom zu erhalten (von einem Erzeugungsdienst), wo auch immer sich diese Maschine gerade befindet. Der Bus ist ein allgegenwärtiger Enabler, der Flexibilität und Veränderung im Laufe der Zeit unterstützt.

Die einzigen Dinge, die in einem Servicebus leben, sind Dienste, und sie werden im Allgemeinen am besten als Mikrodienste implementiert, wo immer dies möglich oder wünschenswert ist. Das Mantra von "intelligenten Endpunkten, Dumb Pipes" geht weit zurück, bevor Microservices auf den Markt kamen. Ich habe es vor vielen Jahren von einem Mitglied des Microsoft BizTalk-Teams in einer öffentlichen Debatte mit einem führenden Befürworter des ESB gehört. Der ESB-Typ plädierte für die Erwünschtheit sehr feinkörniger eigenständiger Transformationsdienste (Mikrodienste) und nicht für den typischen BizTalk-Ansatz, bei dem Transformationen an Endpunkten (intelligente Endpunkte) durchgeführt werden. Der ESB-Mann kritisierte BizTalk und behauptete, es sei "monolithisch" und könne daher nicht verwendet werden, um solche feinkörnigen, unabhängig voneinander einsetzbaren Dienste zu implementieren. Der BizTalk-Typ wies darauf hin, dass er sachlich falsch war (wie später im BizTalk ESB-Toolkit gezeigt wurde), der Hauptpunkt war jedoch die generelle Erwünschtheit, Transformation an den Endpunkten der Nachricht (aus Integrationsperspektive) anstelle eines Downstream-Dienstes durchzuführen im Austausch aufgerufen (konzeptionell weiter unten in der "Pipe").

Dies war eine erwachsene Debatte zwischen ernsthaften Praktizierenden. Ich stimmte mit dem BizTalk-Mann in diesem Punkt überein - intelligente Endpunkte, Dummköpfe. Ironischerweise förderte der ESB-Typ effektiv einen Microservice-Ansatz in einem ESB-Kontext. Für mich ist dies ein hervorragendes Beispiel dafür, wie das Mantra des Microservice wie jede andere Philosophie zu weit gehen kann.

14
CharlesY

Komponenten in einem System verwenden "Pipes" (HTTP/S, Warteschlangen usw.), um miteinander zu kommunizieren. Normalerweise fließen diese Pipes durch einen ESB (Enterprise Service Bus), der die Nachrichten, die zwischen den Komponenten weitergeleitet werden, auf verschiedene Weise erledigt. 

Es könnte tun:

  • Sicherheitskontrollen
  • Routing
  • Geschäftsablauf/Validierung
  • Transformation

Nach Abschluss dieser Aufgaben wird die Nachricht an die Komponente "Endpunkt" weitergeleitet. Dies ist ein Beispiel für "Smart Pipes", da sich innerhalb des ESB viele Logik- und Verarbeitungsfunktionen befinden (Teil des Systems "Pipes"). Die Endpunkte können dann "dumm" sein, da der ESB alle Arbeiten ausgeführt hat.

"Intelligente Endpunkte und Dumb Pipes" befürworten das umgekehrte Szenario. Die Kommunikationswege sollten der Geschäftsverarbeitung und -logik entzogen werden und Nachrichten nur buchstäblich zwischen Komponenten verteilen. Es sind dann die Komponenten selbst, die für die Verarbeitung/Logik/Validierung usw. dieser Nachrichten zuständig sind.

5
johnharris85

Es sind sehr allgemeine Fragen. Ich werde versuchen, es so zu halten

Intelligente Endpunkte  

Intelligente Endpunkte, die nur tatsächliche Geschäftsregeln bedeuten, und alle anderen Überprüfungen finden hinter den Endpunkten statt, die für die Benutzer dieser Endpunkte nicht sichtbar sind, und halten sie für einen Ort, an dem die eigentliche Magie stattfindet. 

Stumme Pipelines  

Unter stummen Pipelines werden alle Kommunikationsmittel verstanden, bei denen keine weiteren Aktionen, z. B. Validierungen, stattfinden, die Daten einfach über diesen bestimmten Kanal übertragen werden und bei Bedarf auch austauschbar sein. 

1
afr0

Martin Fowler: "Der zweite übliche Ansatz ist das Messaging über einen Nachrichtenbus mit geringem Gewicht. Die gewählte Infrastruktur ist normalerweise dumm (dumm wie nur als Nachrichtenrouter).".

Die Gründe für die Verwendung von intelligenten Endpunkten sind implizit: "Die Schlüsseleigenschaft einer Komponente ist der Begriff des unabhängigen Austauschs und der Aufrüstbarkeit. Dies bedeutet, dass wir nach Punkten suchen, an denen wir uns vorstellen können, eine Komponente neu zu schreiben, ohne ihre Mitarbeiter zu beeinträchtigen.".

Um letzteren zu unterstützen, muss ein Mikrodienst dem Verbraucher gegenüber tolerant sein. Z.B. Wenn Sie später ein obligatorisches Eingabeargument hinzufügen, wird die Schnittstelle beschädigt und sollte daher vermieden werden. Stattdessen sollte man Kompensationsstrategien wie Standardwerte verwenden oder eine Art internes "Routing" unterstützen, damit der Microservice immer noch eine gültige Antwort geben kann. Dies ist eine Art intelligenter "Endpunkt".

1
jeeka

Stumme Rohre bedeuten einfach Punkt-zu-Punkt-Verbindungen. Die Endpunkte erledigen die gesamte Arbeit und jegliche Komplexität wird aus dem Mechanismus herausgenommen, der sie verbindet. Ich denke, die Leute sprechen in diesem Gespräch von ESBs, weil stumme Pipes (Punkt-zu-Punkt-Verbindungen) in Unternehmen (und in vielen anderen) eine schreckliche Idee sind. ESBs sind keine "Dumb Pipes". ESBs sind ziemlich gute Definitionen für sehr intelligente Pfeifen. Und sie helfen dabei, die Kontrolle über das unglaublich haarige Chaos zu erhalten, das Punkt-zu-Punkt-Verbindungen immer dann herstellt, wenn Sie mehr als ein paar Dienste haben, die miteinander kommunizieren müssen. 

WSO2 hat gerade eine Reihe guter Webinare zu Microservices erstellt, die über dieses Konzept sprechen. Aber auch sie scheuen sich davor, das Konzept der Dummrohre zu verwenden. 

Jetzt können Dumb Pipes sinnvoll sein, wenn die Dienste nur auf Ad-hoc-Basis verwendet werden, nicht jedoch bei der Verwaltung komplexer Unternehmenssysteme. Das Einrichten mehrerer Netzwerkverbindungen für jeden Dienst ist das geringste.

0
Bill Rosmus