In der Softwarearchitektur ist Publish-Subscribe ein Nachrichtenmuster, bei dem Absender von Nachrichten, so genannte Publisher, die Nachrichten nicht so programmieren, dass sie direkt an bestimmte Empfänger gesendet werden, die als Abonnenten bezeichnet werden, sondern stattdessen die veröffentlichten Nachrichten kategorisieren Klassen ohne Wissen darüber, welche Abonnenten (sofern vorhanden) möglicherweise vorhanden sind. In ähnlicher Weise bekunden Abonnenten Interesse an einer oder mehreren Klassen und erhalten nur Nachrichten, die von Interesse sind, ohne zu wissen, welche Herausgeber, wenn überhaupt, vorhanden sind.
Publish-Subscribe ist ein Geschwister des Nachrichtenwarteschlangen-Paradigmas und ist normalerweise ein Teil eines größeren nachrichtenorientierten Middleware-Systems. Die meisten Nachrichtensysteme unterstützen sowohl das Pub / Sub- als auch das Nachrichtenwarteschlangenmodell in ihrer API, z. Java Message Service (JMS).
Dieses Muster bietet eine größere Netzwerkskalierbarkeit und eine dynamischere Netzwerktopologie, wodurch die Flexibilität zur Änderung des Herausgebers und der Struktur der veröffentlichten Daten verringert wird.
Nachrichtenfilterung [ edit ]
Im Publish-Subscribe-Modell erhalten Abonnenten normalerweise nur eine Teilmenge der insgesamt veröffentlichten Nachrichten. Das Auswählen von Nachrichten für den Empfang und die Verarbeitung wird als Filterung bezeichnet. Es gibt zwei gebräuchliche Formen der Filterung: themenbasiert und inhaltsbasiert.
In einem themenbasierten System werden Nachrichten zu "Themen" oder benannten logischen Kanälen veröffentlicht. Abonnenten in einem themenbasierten System erhalten alle Nachrichten, die zu den Themen veröffentlicht wurden, für die sie abonniert wurden, und alle Abonnenten eines Themas erhalten die gleichen Nachrichten. Der Herausgeber ist dafür verantwortlich, die Nachrichtenklassen zu definieren, die Abonnenten abonnieren können.
In einem inhaltsbasierten System werden Nachrichten nur an einen Abonnenten zugestellt, wenn die Attribute oder der Inhalt dieser Nachrichten den vom Abonnenten definierten Bedingungen entsprechen. Der Teilnehmer ist für die Klassifizierung der Nachrichten verantwortlich.
Einige Systeme unterstützen einen Hybrid der beiden; Publisher veröffentlichen Nachrichten zu einem Thema, während Abonnenten inhaltsbasierte Abonnements für ein oder mehrere Themen registrieren.
Topologien [ edit ]
In vielen Pub / Sub-Systemen buchen die Verleger Nachrichten an einen zwischengeschalteten Nachrichtenbroker oder Ereignisbus, und Abonnenten registrieren Abonnements bei diesem Broker und lassen den Broker durchführen die Filterung Der Broker führt normalerweise eine Speicher- und Weiterleitungsfunktion aus, um Nachrichten von Verlegern an Abonnenten weiterzuleiten. Darüber hinaus kann der Broker vor dem Routing Nachrichten in einer Warteschlange priorisieren.
Abonnenten können sich zur Erstellungszeit, zur Initialisierungszeit oder zur Laufzeit für bestimmte Nachrichten registrieren. In GUI-Systemen können Teilnehmer so codiert werden, dass sie Benutzerbefehle handhaben (z. B. Klicken einer Schaltfläche), was der Bauzeitregistrierung entspricht. Einige Frameworks und Softwareprodukte verwenden XML-Konfigurationsdateien, um Abonnenten zu registrieren. Diese Konfigurationsdateien werden zum Zeitpunkt der Initialisierung gelesen. Die ausgefeilteste Alternative ist, wenn Abonnenten zur Laufzeit hinzugefügt oder entfernt werden können. Letzterer Ansatz wird beispielsweise in Datenbank-Triggern, Mailing-Listen und RSS verwendet.
Die Middleware des Data Distribution Service (DDS) verwendet keinen Broker in der Mitte. Stattdessen teilt jeder Verleger und Abonnent im Pub / Sub-System Metadaten über IP-Multicast miteinander. Der Verleger und die Abonnenten zwischenspeichern diese Informationen lokal und leiten Nachrichten anhand der gegenseitigen Erkennung in der gemeinsam genutzten Kenntnis weiter.
Geschichte [ edit ]
Eines der ältesten öffentlich beschriebenen Pub / Sub-Systeme war das "News" -Subsystem des Isis Toolkit, das 1987 von der Association for Computing Machinery (ACM) beschrieben wurde ) Konferenz über Symposium zu Betriebssystemprinzipien (SOSP '87) in einem Vortrag "Nutzung virtueller Synchronie in verteilten Systemen. 123-138". [1]
Vorteile [ edit
Lose Kopplung [ edit ]
- Verleger sind lose an Abonnenten gekoppelt und müssen nicht einmal wissen, ob sie existieren. Da das Thema im Mittelpunkt steht, dürfen Verleger und Abonnenten die Systemtopologie nicht kennen. Jeder kann unabhängig vom anderen normal weiterarbeiten. Im traditionellen, eng gekoppelten Client-Server-Paradigma kann der Client keine Nachrichten an den Server senden, während der Serverprozess nicht ausgeführt wird, und der Server kann keine Nachrichten empfangen, es sei denn, der Client läuft. Viele Pub / Sub-Systeme entkoppeln nicht nur die Standorte der Verleger und Abonnenten, sondern entkoppeln sie auch zeitlich. Eine von Middleware-Analysten mit solchen Pub / Sub-Systemen verwendete gemeinsame Strategie besteht darin, einen Herausgeber auszuschalten, damit der Abonnent das Backlog (eine Form der Bandbreitenbeschränkung) bearbeiten kann.
Scalability [ edit ]]
- Pub / sub bietet die Möglichkeit einer besseren Skalierbarkeit als herkömmliche Client-Server, durch Parallelbetrieb, Message-Caching, baum- oder netzwerkbasiertes Routing usw. Bei bestimmten Arten von eng gekoppelten Hochvolumen-Volumes Unternehmensumgebungen: Durch die Skalierung von Systemen zu Rechenzentren mit Tausenden von Servern, die die Pub / Sub-Infrastruktur gemeinsam nutzen, verlieren derzeitige Anbieter-Systeme diesen Vorteil häufig. Die Skalierbarkeit für Pub / Sub-Produkte unter hoher Last stellt in diesem Zusammenhang eine Forschungsherausforderung dar.
- Außerhalb der Unternehmensumgebung hat das Pub / Sub-Paradigma seine Skalierbarkeit auf Volumina bewiesen, die weit über denen eines einzelnen Rechenzentrums liegen Bereitstellen von Internet-weitem verteiltem Messaging über Web-Syndication-Protokolle wie RSS und Atom. Diese Syndication-Protokolle akzeptieren eine höhere Latenz und fehlende Zustellgarantien, im Gegenzug für die Fähigkeit selbst eines Low-End-Webservers, Nachrichten an (möglicherweise) Millionen separate Teilnehmerknoten zu syndizieren.
Nachteile [ edit ]
Die schwerwiegendsten Probleme bei Pub / Sub-Systemen sind ein Nebeneffekt ihres Hauptvorteils: die Entkopplung von Publisher und Abonnenten.
Nachrichtenzustellungsprobleme [ edit ]
Ein Pub / Sub-System muss sorgfältig entworfen werden, um stärkere Systemeigenschaften bereitzustellen, die eine bestimmte Anwendung erfordern kann, z. B. eine gesicherte Zustellung.
- Der Broker in einem Pub / Sub-System kann so ausgelegt sein, dass er Nachrichten für eine bestimmte Zeit ausliefert, aber dann den Zustellversuch abbricht, unabhängig davon, ob er von allen Teilnehmern eine Bestätigung des erfolgreichen Empfangs der Nachricht erhalten hat oder nicht. Ein so gestaltetes Pub / Sub-System kann nicht die Zustellung von Nachrichten an Anwendungen garantieren, die eine solche gesicherte Zustellung erfordern. Eine engere Kopplung der Designs eines solchen Herausgeber- und Teilnehmerpaares muss außerhalb der Pub / Sub-Architektur erzwungen werden, um eine solche gesicherte Zustellung zu erreichen (z. B. indem der Abonnent verpflichtet wird, Empfangsnachrichten zu veröffentlichen).
- Ein Publisher in einem Pub / Sub-System kann davon ausgehen, dass ein Teilnehmer zuhört, obwohl dies tatsächlich nicht der Fall ist. Eine Fabrik kann ein Pub / Sub-System verwenden, bei dem Geräte Probleme oder Ausfälle an einen Abonnenten veröffentlichen können, der diese Probleme anzeigt und protokolliert. Wenn der Logger ausfällt (abstürzt), erhalten Herausgeber von Geräteproblemen nicht notwendigerweise eine Benachrichtigung über den Loggerfehler und Fehlermeldungen werden von keinem Gerät im Pub / Sub-System angezeigt oder aufgezeichnet. Dies ist auch eine Designherausforderung für alternative Messaging-Architekturen, wie z. B. ein Client / Server-System. Wenn in einem Client / Server-System ein Fehlerprotokollierer ausfällt, erhält das System einen Hinweis auf den Fehlerprotokollierfehler (Serverfehler). Das Client / Server-System muss sich jedoch mit diesem Fehler auseinandersetzen, indem er redundante Protokollierungsserver online bereitstellt oder Fallback-Protokollierungsserver dynamisch erzeugt. Dies erhöht die Komplexität der Client- und Server-Designs sowie der gesamten Client / Server-Architektur. In einem Pub / Sub-System können jedoch redundante Protokollteilnehmer, die exakte Duplikate des vorhandenen Loggers sind, zum System hinzugefügt werden, um die Zuverlässigkeit der Protokollierung zu erhöhen, ohne dass dies Auswirkungen auf andere Geräte im System hat. In einem Pub / Sub-System kann das Merkmal der gesicherten Fehlermeldungsprotokollierung nach der Implementierung der Grundfunktionalität der Geräteproblem-Meldungsprotokollierung inkrementell hinzugefügt werden.
Das Pub / Sub-Muster eignet sich gut für kleine Netzwerke mit einer geringen Anzahl von Herausgebern und Teilnehmerknoten und geringes Nachrichtenvolumen. Mit zunehmender Anzahl von Knoten und Nachrichten steigt jedoch die Wahrscheinlichkeit von Instabilitäten, wodurch die maximale Skalierbarkeit eines Pub / Sub-Netzwerks begrenzt wird. Beispiele für Durchsatzinstabilitäten bei großen Maßstäben sind:
- Laststöße - Zeiten, in denen der Teilnehmer den Netzwerkdurchsatz sättigt, gefolgt von Perioden mit geringem Nachrichtenaufkommen (nicht ausgelastete Netzwerkbandbreite).
- Verlangsamung - da immer mehr Anwendungen das System verwenden (selbst wenn sie auf separaten Pub / Sub-Kanälen kommunizieren ) Der Nachrichtenfluss an einen einzelnen Abonnenten verlangsamt sich
Bei Pub / Sub-Systemen, die Broker (Server) verwenden, ist das Argument für einen Broker, Nachrichten an einen Abonnenten zu senden, In-Band und kann Sicherheitsprobleme verursachen. Makler könnten dazu verleitet werden, Benachrichtigungen an den falschen Client zu senden, wodurch die Ablehnung von Dienstanfragen gegenüber dem Client verstärkt wird. Makler selbst könnten überlastet sein, wenn sie Ressourcen zuweisen, um erstellte Abonnements zu verfolgen.
Selbst bei Systemen, die nicht auf Broker angewiesen sind, kann ein Abonnent möglicherweise Daten erhalten, zu deren Empfang er nicht berechtigt ist. Ein nicht autorisierter Herausgeber kann möglicherweise falsche oder beschädigte Nachrichten in das Pub / Sub-System eingeben. Dies gilt insbesondere für Systeme, die ihre Nachrichten senden oder multicastieren. Durch die Verschlüsselung (z. B. Transport Layer Security (SSL / TLS)) können nicht autorisierte Zugriffe verhindert werden, schädliche Nachrichten können jedoch nicht durch autorisierte Herausgeber eingeführt werden. Andere Architekturen als pub / sub, wie z. B. Client / Server-Systeme, sind auch anfällig für autorisierte Nachrichtensender, die sich in böswilliger Weise verhalten.
No comments:
Post a Comment