Dieser Blog ist Teil der Reihe, in der wir 101 Konzepte von Ground Zero für ein Publikum diskutieren, das über begrenzte Grundkenntnisse verfügt. Dieser Artikel gehört zur Serie für Fortgeschrittene, da es darum geht, die Grundlagen der Messaging-Designprinzipien zu verstehen, hauptsächlich den Anwendungsfall der Publisher-Subscriber-basierten Architektur, die in der asynchronen Kommunikation verwendet wird.

Einige der früheren Blogs in der 101-Serie lauten wie folgt:

API 101
Asynchrone Kommunikation 101 Datenbanken 101 Datenbankdesign 101

Was ist Pub-Sub?

Im Falle einer verteilten Architektur ist das Publisher-Subscriber- Messaging-Muster zum Entkoppeln der ereigniserzeugenden Quelle von der ereignisempfangenden Quelle und zum Entsperren der End-2-End-Systeme, die in großem Umfang ausgeführt werden, konzipiert. Der Absender, der auch als Herausgeber bezeichnet wird, überträgt die Nachrichten als Ereignisse in einem vordefinierten Nachrichtenformat an einen Middle-Layer-Broker ( Kafka, EventHub, Service Bus usw. ), von dem einzelne/mehrere Abonnenten abhängig von der gewählten Abonnementrichtlinie abhören können.

Das Pub-Sub-Modell unterstützt sowohl Unicast- als auch Broadcast -Anwendungsfälle im Gegensatz zu einem Message Queue-Muster , das nur Unicast -basierte Anwendungsfälle unterstützt.

Allgemeine Begriffe

• Publisher – Clients, die die Nachricht generieren und sie in die Messaging-Infrastruktur einreihen.
• Abonnent – ​​Clients, die die Nachricht empfangen und sie in der Messaging-Infrastruktur aus der Warteschlange entfernen.
• Message Broker – Die mittlere Schicht, die Anfragen zum Veröffentlichen und Lesen von Nachrichten von verschiedenen Clients verarbeitet. Es hält Daten innerhalb eines Clusters in Form von Themen über Replikate und Partitionen hinweg repliziert.
• Thema – Eindeutige logische Kategorien innerhalb des Brokers, der Nachrichten/Ereignisse in Bezug auf eine bestimmte Anwendung/einen Geschäftsanwendungsfall bereitstellt.
• Partition – Themen können weiter in logische Einheiten unterteilt werden, die als Partitionen bezeichnet werden, um eine parallele Verarbeitung von Nachrichten zu ermöglichen. Jede Partition enthält eindeutige Datensätze, die durch Offsets identifiziert werden.
• QOS – Eine Vereinbarung zwischen dem Herausgeber und dem Abonnenten, die angibt, wie oft eine tatsächliche Nachricht zugestellt werden soll – mindestens einmal, höchstens einmal, genau einmal.

Das Publisher-Subscriber-Modell wird für Anwendungsfälle verwendet, die eine große Menge an generierten Ereignissen erfordern und eine sofortige Garantie von Nachrichten nicht von vorrangiger Bedeutung ist. Anwendungen, die in die angegebenen Buckets fallen, sind gute Kandidaten für dieses Muster.

• Anwendungen, bei denen keine starke Konsistenz für Ereignisse zwischen Sender und Empfänger erforderlich ist und die Anordnung von Daten/Ereignissen keine geschäftlichen Auswirkungen hat. Dies ist ein schließlich konsistentes Entwurfsmuster.
• Anwendungen, bei denen die Echtzeitantwort von Abonnenten keinen Einfluss auf den tatsächlichen Geschäftsablauf hat.
• Abonnenten, die zu verschiedenen Themen gehören, sind unabhängig und können unterschiedliche Verfügbarkeits- und Betriebszeitmetriken haben.

Um einen Publisher-Subscriber auf die richtigen SLAs für Zuverlässigkeit und Verfügbarkeit zu skalieren, um die End-2-End-Geschäftsanwendungsfälle zu bedienen, werden die folgenden Designüberlegungen empfohlen.

• Idempotente Abonnenten – Abhängig vom Gesamt-QOS-Set und im Fall von Fehlern können mehrere Abonnenten dieselbe Nachricht mehr als einmal senden. Daher sind Abonnenten verpflichtet, Idempotenz aufrechtzuerhalten , dh wiederholte Nachrichten nicht mehr als einmal zu verarbeiten und doppelte Nachrichtenbehandlung zu haben.
• Nachrichtenreihenfolge und -priorität – Nachrichten können abhängig von mehreren Faktoren wie Partitionen, Verbrauchergruppen in einem anderen Zeitrahmen als ihrer Erstellung verarbeitet werden. Daher sollte jede Nachricht im gesamten Geschäfts-/Anwendungsablauf unabhängig sein.
• Warteschlange für unzustellbare Nachrichten – Abhängig von der TTL-Einrichtung für Nachrichten und der Verfügbarkeit/Fehlerbehandlung der Verbraucher können einige der Nachrichten in der Warteschlange für unzustellbare Nachrichten landen . Diese Nachrichten sollten von den Herausgebern erneut verarbeitet werden, um geschäftliche Auswirkungen zu vermeiden.
• Sicherheit – Unterschiedliche Themen auf den Message Brokern sollten unabhängige Autorisierungsrichtlinien sein, um sicherzustellen, dass Clients nicht versehentlich Informationen aus einem anderen Thema austauschen. Clientzertifikate und gegenseitiges TLS sind einige gute Sicherheitsrichtlinien.

Zusammenfassung

Pub-Sub ist ein gängiges, unkompliziertes Designmuster, das in Aysnc-basierten verteilten Systemen verwendet wird, da es hilft, für Millionen von Kunden zu skalieren, ohne dass eine komplexe Bereitstellungssemantik beibehalten werden muss. Für komplexe Anwendungsfälle, in denen die Nachrichten/Ereignisse dynamische Routing -Muster aufweisen müssen, sind jedoch andere Entwurfsmuster wie z . Wir werden versuchen, sie in den kommenden 101-Blogs zum Erlernen funktionaler Architektur zu behandeln.

Für Feedback senden Sie bitte eine Nachricht an amit[dot]894[at]gmail[dot]com oder wenden Sie sich an einen der Links unter https://about.me/amit_raj .