Publisher-Subscriber patroon

Een toepassing in staat stellen om asynchroon meerdere geïnteresseerde consumenten op de hoogte te brengen van gebeurtenissen, zonder dat de afzenders aan de ontvangers worden gekoppeld.

Ook wel : Pub/sub messaging genoemd

Context en probleem

In cloudtoepassingen en gedistribueerde toepassingen moeten onderdelen van het systeem vaak informatie verstrekken aan andere onderdelen wanneer er gebeurtenissen plaatsvinden.

Asynchrone berichten zijn een efficiënte manier om afzenders los tekoppelen van consumenten en te voorkomen dat de afzender wordt geblokkeerd om te wachten op een antwoord. Het gebruik van een toegewezen berichtenwachtrij voor elke consument schaalt echter niet effectief naar veel consumenten. Bovendien zijn sommige consumenten mogelijk alleen geïnteresseerd in een subset van de informatie. Hoe kan de afzender gebeurtenissen aankondigen aan alle geïnteresseerde consumenten zonder hun identiteit te kennen?

Oplossing

Introduceer een subsysteem voor asynchrone berichten met het volgende:

• Een invoerberichtenkanaal dat wordt gebruikt door de afzender. De afzender verpakt gebeurtenissen in berichten met behulp van een bekende berichtindeling en verzendt deze berichten via het invoerkanaal. De afzender in dit patroon wordt ook wel de uitgever genoemd.

  Notitie

  Een bericht is een pakket met gegevens. Een gebeurtenis is een bericht dat andere onderdelen waarschuwt over een wijziging of een actie die heeft plaatsgevonden.

• Eén uitvoerberichtenkanaal per consument. De consumenten worden abonnees genoemd.

• Een mechanisme voor het kopiëren van elk bericht van het invoerkanaal naar de uitvoerkanalen voor alle abonnees die geïnteresseerd zijn in dat bericht. Deze bewerking wordt doorgaans verwerkt door een intermediair, zoals een berichtenbroker of gebeurtenisbus.

In het volgende diagram ziet u de logische onderdelen van dit patroon:

Pub-/subberichten hebben de volgende voordelen:

• Er worden subsystemen losgekoppeld die nog moeten communiceren. Subsystemen kunnen onafhankelijk worden beheerd en berichten kunnen correct worden beheerd, zelfs als een of meer ontvangers offline zijn.

• Het verhoogt de schaalbaarheid en verbetert de reactiesnelheid van de afzender. De afzender kan snel één bericht naar het invoerkanaal verzenden en vervolgens terugkeren naar de verantwoordelijkheden van de kernverwerking. De infrastructuur voor berichten is verantwoordelijk voor het leveren van berichten aan geïnteresseerde abonnees.

• Dit verbetert de betrouwbaarheid. Asynchrone berichten helpen toepassingen soepel te blijven werken bij toegenomen belastingen en onregelmatige fouten effectiever af te handelen.

• Hierdoor is uitgestelde of geplande verwerking mogelijk. Abonnees kunnen wachten om berichten op te halen buiten piekuren, of berichten kunnen worden gerouteerd of verwerkt volgens een specifieke planning.

• Het maakt eenvoudigere integratie mogelijk tussen systemen die gebruikmaken van verschillende platforms, programmeertalen of communicatieprotocollen, evenals tussen on-premises systemen en toepassingen die in de cloud worden uitgevoerd.

• Het faciliteert asynchrone werkstromen binnen een onderneming.

• Dit verbetert de testbaarheid. Kanalen kunnen worden bewaakt en berichten kunnen worden geïnspecteerd of geregistreerd als onderdeel van een algemene integratieteststrategie.

• Het biedt scheiding van problemen voor uw toepassingen. Elke toepassing kan zich richten op de belangrijkste mogelijkheden, terwijl de berichteninfrastructuur alles af handelen wat nodig is om berichten betrouwbaar naar meerdere consumenten te sturen.

Problemen en overwegingen

Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:

• Bestaande technologieën. Het wordt ten zeerste aanbevolen om beschikbare berichtenproducten en -services te gebruiken die ondersteuning bieden voor een model voor publiceren/abonneren, in plaats van uw eigen producten en services te bouwen. Overweeg in Azure het gebruik van Service Bus, Event Hubs of Event Grid. Andere technologieën die kunnen worden gebruikt voor pub-/subberichten zijn Redis, RabbitMQ en Apache Kafka.

• Abonnementsafhandeling. De berichteninfrastructuur moet mechanismen bieden waarmee consumenten zich kunnen abonneren op of zich kunnen afmelden voor beschikbare kanalen.

• Veiligheid. Verbinding maken met een berichtkanaal moet worden beperkt door beveiligingsbeleid om te voorkomen dat onbevoegde gebruikers of toepassingen meeluisteren.

• Subsets van berichten. Abonnees zijn doorgaans alleen geïnteresseerd in een subset van de berichten die worden gedistribueerd door een uitgever. Berichtenservices bieden abonnees vaak de mogelijkheid om de reeks berichten te beperken die worden ontvangen door:

  • Onderwerpen. Elk onderwerp heeft een toegewezen uitvoerkanaal en elke consument kan zich abonneren op alle relevante onderwerpen.
  • Filteren van inhoud. Berichten worden geïnspecteerd en gedistribueerd op basis van de inhoud van elk bericht. Elke abonnee kan de inhoud opgeven waarin deze is geïnteresseerd.

• Abonnees met jokertekens. Overweeg abonnees toe te staan zich te abonneren op meerdere onderwerpen via jokertekens.

• Bi-directionele communicatie. De kanalen in een publiceren/abonneren-systeem worden behandeld als unidirectioneel. Als een specifieke abonnee bevestiging moet verzenden of de status moet terugsturen naar de uitgever, kunt u overwegen het aanvraag-/antwoordpatroon te gebruiken. Dit patroon maakt gebruik van één kanaal om een bericht naar de abonnee te verzenden en een afzonderlijk antwoordkanaal om terug te communiceren met de uitgever.

• Volgorde van berichten. De volgorde waarin consumenten exemplaren berichten ontvangen, wordt niet gegarandeerd en komt niet noodzakelijkerwijs overeen met de volgorde waarin de berichten zijn gemaakt. Ontwerp het systeem om ervoor te zorgen dat de berichtverwerking idempotent is om eventuele afhankelijkheden van de volgorde van de verwerking van berichten te elimineren.

• Berichtprioriteit. Sommige oplossingen vereisen mogelijk dat berichten in een specifieke volgorde worden verwerkt. Het patroon Wachtrij met prioriteit biedt een mechanisme om ervoor te zorgen dat specifieke berichten vóór andere berichten worden bezorgd.

• Vertreintreiningsberichten. Een onjuist ingedeeld bericht of een taak waarvoor toegang tot resources nodig is die niet beschikbaar zijn, kan ertoe leiden dat een exemplaar van de service mislukt. Het systeem moet voorkomen dat dergelijke berichten naar de wachtrij worden geretourneerd. Leg in plaats daarvan de details van deze berichten vast en sla ze ergens anders op, zodat ze indien nodig kunnen worden geanalyseerd.

• Herhaalde berichten. Hetzelfde bericht kan meer dan één keer worden verzonden. De afzender kan bijvoorbeeld mislukken na het plaatsen van een bericht. Vervolgens wordt er mogelijk een nieuw exemplaar van de afzender opstart en wordt het bericht herhaald. De infrastructuur voor berichten moet dubbele berichtdetectie en -verwijdering implementeren (ook wel bekend als ontdubbeling) op basis van bericht-ID's om berichten altijd te kunnen leveren.

• Verlopen van berichten. Een bericht kan een beperkte levensduur hebben. Als deze niet binnen deze periode wordt verwerkt, is deze mogelijk niet meer relevant en moet deze worden verwijderd. Een afzender kan een verlooptijd opgeven als onderdeel van de gegevens in het bericht. Een ontvanger kan deze informatie onderzoeken voordat wordt besloten of de bedrijfslogica die aan het bericht is gekoppeld, moet worden gebruikt.

• Berichtplanning. Een bericht kan tijdelijk worden geseed en mag niet worden verwerkt tot een bepaalde datum en tijd. Het bericht moet tot nu toe niet beschikbaar zijn voor een ontvanger.

Wanneer dit patroon gebruiken

Gebruik dit patroon wanneer:

• Een toepassing moet informatie uitzenden naar een groot aantal consumenten.

• Een toepassing moet communiceren met een of meer onafhankelijk ontwikkelde toepassingen of services, die verschillende platforms, programmeertalen en communicatieprotocollen kunnen gebruiken.

• Een toepassing kan informatie naar consumenten verzenden zonder dat er realtime reacties van de consumenten nodig zijn.

• De systemen die worden geïntegreerd, zijn ontworpen ter ondersteuning van een model voor uiteindelijke consistentie voor hun gegevens.

• Een toepassing moet informatie communiceren met meerdere consumenten, die mogelijk verschillende beschikbaarheidsvereisten of uptimeschema's hebben dan de afzender.

In de volgende gevallen is dit patroon mogelijk niet geschikt:

• Een toepassing heeft slechts enkele consumenten die aanzienlijk andere informatie nodig hebben dan de producerende toepassing.

• Een toepassing vereist bijna realtime interactie met consumenten.

Voorbeeld

In het volgende diagram ziet u een architectuur voor bedrijfsintegratie die gebruikmaakt van Service Bus om werkstromen te coördineren en Event Grid subsystemen op de hoogte te stellen van gebeurtenissen die optreden. Zie Enterprise integration on Azure using message queues and events (Bedrijfsintegratie in Azure met behulp van berichtenwachtrijen en gebeurtenissen) voor meer informatie.

Volgende stappen

De volgende richtlijnen kunnen relevant zijn bij het implementeren van dit patroon:

• Kies tussen Azure-services die berichten bezorgen.

• De gebeurtenisgestuurde architectuurstijl is een architectuurstijl die gebruikmaakt van pub-/subberichten.

• Asynchronous Messaging Primer (Inleiding in asynchrone berichtpatronen). Berichtenwachtrijen zijn een mechanisme voor asynchrone communicatie. Als een consumentenservice een antwoord naar een toepassing moet verzenden, is het mogelijk nodig om een vorm van antwoordberichten te implementeren. De inleiding in asynchrone berichten biedt informatie over het implementeren van aanvraag-/antwoordberichten via berichtenwachtrijen.

Verwante informatie

De volgende patronen zijn mogelijk relevant bij het implementeren van dit patroon:

• Waarnemerpatroon. Het Publish-Subscribe is gebaseerd op het patroon Waarnemer door onderwerpen los te koppelen van waarnemers via asynchrone berichten.

• Message Broker-patroon. Veel berichtensubsystemen die ondersteuning bieden voor een model voor publiceren/abonneren worden geïmplementeerd via een berichtenbroker.