Patroon Publisher-Subscriber

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 genoemd: Pub/sub messaging

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 effectieve manier om afzenders los te koppelen van consumenten en te voorkomen dat de afzender wordt geblokkeerd om te wachten op een antwoord. Het gebruik van een speciale berichtenwachtrij voor elke consument wordt echter niet effectief geschaald naar veel consumenten. Sommige consumenten zijn 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 asynchroon berichtensubsysteem dat het volgende bevat:

• Een invoerberichtenkanaal dat door de afzender wordt gebruikt. 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 gegevens. Een gebeurtenis is een bericht dat andere onderdelen op de hoogte stelt van een wijziging of een actie die is uitgevoerd.

• 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/sub messaging heeft de volgende voordelen:

• Het koppelt subsystemen die nog steeds 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 verzenden naar het invoerkanaal en vervolgens terugkeren naar de belangrijkste verwerkingsverantwoordelijkheden. De berichteninfrastructuur is verantwoordelijk voor het leveren van berichten aan geïnteresseerde abonnees.

• Dit verbetert de betrouwbaarheid. Asynchrone berichten helpen toepassingen soepeler te werken onder verhoogde belastingen en onregelmatige fouten effectiever af te handelen.

• Het maakt uitgestelde of geplande verwerking mogelijk. Abonnees kunnen wachten om berichten op te halen tot buiten piekuren, of berichten kunnen worden gerouteerd of verwerkt volgens een specifiek schema.

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

• Het vereenvoudigt asynchrone werkstromen binnen een onderneming.

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

• Het biedt scheiding van zorgen voor uw toepassingen. Elke toepassing kan zich richten op de kernmogelijkheden, terwijl de berichteninfrastructuur alles afhandelt dat nodig is om berichten betrouwbaar te routeren naar meerdere consumenten.

Problemen en overwegingen

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

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

• Verwerking van abonnementen. De berichteninfrastructuur moet mechanismen bieden die consumenten kunnen gebruiken om zich te abonneren op of af te melden bij beschikbare kanalen.

• Beveiliging. Verbinding maken met een berichtkanaal moet worden beperkt door beveiligingsbeleid om afluisteren door onbevoegde gebruikers of toepassingen te voorkomen.

• Subsets van berichten. Abonnees zijn meestal alleen geïnteresseerd in een subset van de berichten die worden gedistribueerd door een uitgever. Met berichtenservices kunnen abonnees vaak de set berichten beperken die worden ontvangen door:

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

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

• Bidirectionele communicatie. De kanalen in een publiceren-abonneren-systeem worden behandeld als unidirectioneel. Als een specifieke abonnee bevestiging moet verzenden of de status moet doorgeven aan de uitgever, kunt u overwegen om het patroon Aanvraag/antwoord 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.

• Berichtvolgorde. De volgorde waarin consumentenexemplaren berichten ontvangen, wordt niet gegarandeerd en geeft niet noodzakelijkerwijs de volgorde weer waarin de berichten zijn gemaakt. Ontwerp het systeem om ervoor te zorgen dat berichtverwerking idempotent is om eventuele afhankelijkheid van de volgorde van de berichtafhandeling te elimineren.

• Prioriteit van bericht. Voor sommige oplossingen is mogelijk vereist dat berichten in een specifieke volgorde worden verwerkt. Het patroon Prioriteitswachtrij biedt een mechanisme om ervoor te zorgen dat specifieke berichten voor anderen worden bezorgd.

• Gifberichten. 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 worden geretourneerd naar de wachtrij. Leg in plaats daarvan de details van deze berichten ergens anders vast, zodat ze indien nodig kunnen worden geanalyseerd. Sommige berichtenbrokers, zoals Azure Service Bus, ondersteunen dit via de functionaliteit van hun wachtrij met dode letters.

• Herhaalde berichten. Hetzelfde bericht kan meerdere keren worden verzonden. De afzender kan bijvoorbeeld mislukken na het plaatsen van een bericht. Vervolgens kan een nieuw exemplaar van de afzender het bericht starten en herhalen. De berichteninfrastructuur moet dubbele berichtdetectie en -verwijdering (ook wel ontdubbeling genoemd) implementeren op basis van bericht-id's om maximaal één keer berichten af te leveren. Als u berichteninfrastructuur gebruikt die geen berichten ontdubbelt, moet u er ook voor zorgen dat de logica voor berichtverwerking idempotent is.

• Verlooptijd van bericht. 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 bepaald of de bedrijfslogica moet worden uitgevoerd die aan het bericht is gekoppeld.

• Berichtplanning. Een bericht kan tijdelijk embargoed zijn en mag pas worden verwerkt als er een bepaalde datum en tijd is. Het bericht mag pas op dit moment beschikbaar zijn voor een ontvanger.

• Abonnees uitschalen. Als een bepaalde abonnee de snelheid van de ontvangen berichten niet kan bijhouden, gebruikt u het patroon Concurrerende consumenten om het uit te schalen.

Wanneer dit patroon gebruiken

Gebruik dit patroon wanneer:

• Een toepassing moet informatie uitzenden naar een aanzienlijk 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 verzenden naar consumenten zonder dat er realtime reacties van de consumenten nodig zijn.

• De systemen die worden geïntegreerd, zijn ontworpen ter ondersteuning van een uiteindelijk consistentiemodel voor hun gegevens.

• Een toepassing moet informatie doorgeven aan 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 een paar consumenten die aanzienlijk andere informatie nodig hebben dan de productietoepassing.

• Voor een toepassing is bijna realtime interactie met consumenten vereist.

Workloadontwerp

Een architect moet evalueren hoe het patroon Uitgever/Abonnee kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Opmerking

In het volgende diagram ziet u een architectuur voor bedrijfsintegratie die Gebruikmaakt van Service Bus om werkstromen te coördineren en Event Grid om subsystemen op de hoogte te stellen van gebeurtenissen die optreden. Zie Enterprise-integratie in Azure met behulp van berichtenwachtrijen en gebeurtenissen voor meer informatie.

Volgende stappen

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

• Kies tussen Azure-services die berichten bezorgen.

• 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.

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

• Waarnemerspatroon. Het patroon Publish-Subscribe bouwt voort op het waarnemerspatroon door onderwerpen van waarnemers te ontkoppelen via asynchrone berichten.

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

In dit blogbericht worden verschillende manieren beschreven om berichten te verwerken die niet in orde zijn.

Verwante resources

• De stijl gebeurtenisgestuurde architectuur is een architectuurstijl die gebruikmaakt van pub/sub messaging.
• Idempotent berichtverwerking
• Bedrijfsintegratie in Azure met behulp van berichtenwachtrijen en gebeurtenissen