Übersetzung
Messaging ist ein grundlegender Bestandteil jedes verteilten Systems. Sie ermöglicht es einem Produzenten, eine Nachricht an beliebig viele Verbraucher zu senden, und es ist nicht notwendig, Informationen über den Verbraucher zu kennen. Das ist eine große Hilfe für wirklich asynchrone und entkoppelnde Kommunikation.
Wenn du RabbitMQ verwendest, zeigt das obige Diagramm eine sehr einfache, aber typische Struktur. Ein Produzent sendet eine Nachricht an den Switch. Nach der Routing-Logik legt der Switch die Nachricht in die an den Switch gebundene Warteschlange. Genauer gesagt, wenn es sich um einen Broadcast-Switch handelt, wird die Kopie dieser Nachricht wiederholt an jede Warteschlange gesendet. Ein Konsument kann die Nachricht dann empfangen und verarbeiten.
Eine wichtige Annahme, damit die obige Struktur für Produzenten und Verbraucher erfolgreich funktioniert, ist, dass alle RabbitMQ-Komponenten (also Warteschlangen, Schalter und Bindungen) im Voraus erstellt werden müssen. Ein Konsument kann keine Nachricht an einen Switch senden. Wenn der Switch nicht existiert, kann ein Konsument keine Nachrichten aus einer nicht existierenden Warteschlange verarbeiten.
Daher ist es nicht schwer zu verstehen, dass bevor Produzent/Konsument die Nachricht sendet/empfängt, ein Produzent/Konsument-Wert eine Warteschlange-, Wechsel- und Bindungsbeziehung schaffen lässt. Schauen wir uns die Vor- und Nachteile beider Methoden an.
1. Verantwortlichkeiten unterscheiden
Bildübersetzung (1. Der Produzent erstellt einen Switch 2. Der Consumer erstellt eine Warteschlange und bindet die Warteschlange an den Switch)
Damit Produzenten und Konsumenten sich vollständig entkoppeln können, wissen Produzenten idealerweise nur Informationen über den Schalter (nicht die Warteschlange), und die Konsumenten nur über die Warteschlange (nicht über den Schalter). Die Bindungsbeziehung zeigt die Beziehung zwischen dem Switch und der Warteschlange an
Eine mögliche Möglichkeit ist, dass der Produzent die Erstellung des Switches übernimmt und der Konsument die Warteschlange erstellt und diese an den Switch bindet. Der Vorteil dieser Entkopplungsmethode besteht darin, dass der Konsument, wenn er eine Warteschlange benötigt, lediglich eine Warteschlange erstellen und entsprechend der Nachfrage binden muss, sodass der Produzent keine Informationen über die Warteschlange wissen muss. Dies ist jedoch keine ausreichende Entkopplung: Denn der Konsument muss den Schalter kennen, um ihn binden zu können.
2. Produzenten erschaffen alles
Wenn der Producer läuft, kann er so konfiguriert werden, dass er alle erforderlichen Komponenten (Switches, Warteschlangen und Bindungen) erstellt. Der Vorteil dieses Ansatzes ist, dass keine Nachrichten verloren gehen (da die Warteschlange bereits erstellt und an den Switch gebunden ist und kein Konsument sie zuerst starten muss).
Das bedeutet jedoch, dass der Produzent alle Warteschlangen kennen muss, die mit dem Switch verknüpft werden müssen. Das ist eine stark gekoppelte Methode. Der Grund ist, dass der Produzent jedes Mal, wenn eine neue Warteschlange hinzugefügt werden muss, neu konfigurieren und deployen muss, um Warteschlangen zu erstellen und zu binden
3. Konsumenten erschaffen alles
Das Gegenteil ist, dass der Verbraucher die Switches, Warteschlangen und Bindings erstellt, die er während des Betriebs benötigt. Wie beim vorherigen Ansatz erzeugt diese Methode eine Kopplung, da der Konsument die Informationen über den an die Warteschlange gebundenen Switch kennen muss. Jegliche Änderungen am Switch (wie eine Umbenennung) bedeuten, dass alle Konsumenten neu konfiguriert und bereitgestellt werden müssen. Bei großen Warteschlangen und Verbrauchern kann diese Komplexität unerschwinglich sein.
4. Keiner von beiden erzeugt etwas
Ein völlig anderer Ansatz besteht darin, weder Produzent noch Verbraucher die erforderlichen Komponenten herzustellen. Stattdessen wird es vorher über die Benutzeroberfläche des Admin-Plugins oder die Admin-CLI erstellt. Diese Methode basiert auf folgenden Vorteilen:
- Produzenten und Verbraucher können völlig entkoppelt werden. Produzenten kennen nur den Austausch, und die Konsumenten kennen nur die Warteschlange.
- Dies kann als Teil der Bereitstellungspipeline einfach geskriptet und automatisiert werden
- Alle Änderungen, wie neue Warteschlangen, können hinzugefügt werden, ohne bestehende, eingesetzte Publisher und Verbraucher zu berühren
Zusammenfassung
In verteilten Systemen sind asynchrone Nachrichten eine nützliche Methode zur Entkopplung, aber um sie entkoppelt zu halten, ist es notwendig, eine effektive Strategie zur Aufrechterhaltung der zugrundeliegenden Messaging-Struktur zu pflegen (in RabbitMQ sind das Warteschlangen, Switches und Bindungen).
Während Publisher- und Verbraucherservices für die eigene Produktion dessen verantwortlich sein können, was sie benötigen, können sie in Bezug auf anfänglichen Nachrichtenverlust, Kopplung und betriebliche Wartung (in Bezug auf Konfiguration und Bereitstellung) kostspielig sein.
Wahrscheinlich ist der beste Weg, die Messaging-Systemkonfiguration dort zu handhaben, wo sie hingehört: Skripte außerhalb der Anwendung schreiben. Dies stellt sicher, dass die Dienste entkoppelt bleiben und das Warteschlangensystem sich dynamisch nach Bedarf ändern kann, ohne eine große Anzahl bestehender Dienste zu beeinträchtigen.
Original:Der Hyperlink-Login ist sichtbar.
Originalenglisch:Der Hyperlink-Login ist sichtbar.
|
Veröffentlicht am 03.05.2023 22:31:59
|
|
|
|
