In dit artikel worden de verschillende typen berichten en de entiteiten beschreven die deelnemen aan een berichteninfrastructuur. Op basis van de vereisten van elk berichttype raadt het artikel Azure Messaging-services aan. De opties omvatten Azure Service Bus Messaging, Azure Event Grid en Azure Event Hubs. Zie Berichtenservices vergelijken voor productvergelijking.
Op architectuurniveau is een bericht een datagram dat is gemaakt door een entiteit (producent), om informatie te distribueren, zodat andere entiteiten (consumenten) op de hoogte kunnen zijn en dienovereenkomstig kunnen handelen. De producent en de consument kunnen rechtstreeks of optioneel communiceren via een intermediaire entiteit (berichtenbroker). Dit artikel is gericht op asynchrone berichten met behulp van een berichtenbroker.
We kunnen berichten classificeren in twee hoofdcategorieën. Als de producent een actie van de consument verwacht, is dat bericht een opdracht. Als het bericht de consument informeert dat er een actie is ondernomen, is het bericht een gebeurtenis.
Opdrachten
De producent verzendt een opdracht met de intentie dat de consument(en) een bewerking uitvoert binnen het bereik van een zakelijke transactie.
Een opdracht is een bericht met hoge waarde en moet ten minste één keer worden bezorgd. Als een opdracht verloren gaat, kan de hele zakelijke transactie mislukken. Een opdracht mag ook niet meer dan één keer worden verwerkt. Als u dit doet, kan dit leiden tot een onjuiste transactie. Een klant kan dubbele orders krijgen of twee keer worden gefactureerd.
Opdrachten worden vaak gebruikt voor het beheren van de werkstroom van een multistep zakelijke transactie. Afhankelijk van de bedrijfslogica kan de producent verwachten dat de consument het bericht bevestigt en de resultaten van de bewerking rapporteert. Op basis van dat resultaat kan de producent een passende actiewijze kiezen.
Gebeurtenissen
Een gebeurtenis is een type bericht dat een producent aanroept om feiten aan te kondigen.
De producent (bekend als de uitgever in deze context) heeft geen verwachtingen dat de gebeurtenissen tot een actie leiden.
Geïnteresseerde consumenten kunnen zich abonneren, luisteren naar gebeurtenissen en acties ondernemen, afhankelijk van hun verbruiksscenario. Gebeurtenissen kunnen meerdere abonnees of helemaal geen abonnees hebben. Twee verschillende abonnees kunnen reageren op een gebeurtenis met verschillende acties en niet op de hoogte zijn van elkaar.
De producent en consument worden losjes gekoppeld en onafhankelijk beheerd. De producent verwacht niet dat de consument de gebeurtenis weer aan de producent zal bevestigen. Een consument die niet langer geïnteresseerd is in de gebeurtenissen, kan zich afmelden, waardoor de consument uit de pijplijn wordt verwijderd zonder dat dit van invloed is op de producent of de algehele functionaliteit van het systeem.
Er zijn twee categorieën gebeurtenissen:
De producent roept gebeurtenissen op om discrete feiten aan te kondigen. Een veelvoorkomende use-case is gebeurtenismelding. Azure Resource Manager genereert bijvoorbeeld gebeurtenissen wanneer resources worden gemaakt, gewijzigd of verwijderd. Een abonnee van deze gebeurtenissen kan een logische app zijn waarmee waarschuwingsmails worden verzonden.
De producent genereert gerelateerde gebeurtenissen in een reeks, of een stroom gebeurtenissen, gedurende een bepaalde periode. Normaal gesproken wordt een stream gebruikt voor statistische evaluatie. De evaluatie kan plaatsvinden in een tijdelijk venster of wanneer gebeurtenissen binnenkomen. Telemetrie is een veelvoorkomende use-case (bijvoorbeeld status- en belastingcontrole van een systeem). Een ander geval is gebeurtenisstreaming vanaf IoT-apparaten.
Een veelvoorkomend patroon voor het implementeren van gebeurtenisberichten is het patroon Publisher-Subscriber .
Rol en voordelen van een berichtenbroker
Een tussenliggende berichtenbroker biedt de functionaliteit van het verplaatsen van berichten van producent naar consument en kan meer voordelen bieden.
Loskoppelen
Een berichtenbroker koppelt de producent los van de consument in de logica die de berichten genereert en gebruikt. In een complexe werkstroom kan de broker bedrijfsactiviteiten aanmoedigen om losgekoppeld te worden en de werkstroom te coördineren.
Voor één zakelijke transactie zijn bijvoorbeeld afzonderlijke bewerkingen vereist die in een bedrijfslogicareeks worden uitgevoerd. De producent geeft een opdracht uit waarmee een consument een bewerking start. De consument bevestigt het bericht in een afzonderlijke wachtrij die is gereserveerd voor het opstellen van antwoorden voor de producent. Pas nadat het antwoord is ontvangen, verzendt de producent een nieuw bericht om de volgende bewerking in de reeks te starten. Een andere consument verwerkt dat bericht en verzendt een voltooiingsbericht naar de antwoordwachtrij. Met behulp van berichten coördineren de services de werkstroom van de transactie onder elkaar.
Een berichtenbroker biedt tijdelijke ontkoppeling. De producent en consument hoeven niet gelijktijdig te worden uitgevoerd. Een producent kan een bericht verzenden naar de berichtenbroker, ongeacht de beschikbaarheid van de consument. Omgekeerd wordt de consument niet beperkt door de beschikbaarheid van de producent.
De gebruikersinterface van een web-app genereert bijvoorbeeld berichten en gebruikt een wachtrij als berichtbroker. Wanneer de consument klaar is, kan deze berichten ophalen uit de wachtrij en het werk uitvoeren. Tijdelijke ontkoppeling helpt de gebruikersinterface responsief te blijven. Het wordt niet geblokkeerd terwijl de berichten asynchroon worden verwerkt.
Het kan lang duren voordat bepaalde bewerkingen zijn voltooid. Nadat een opdracht is uitgevoerd, hoeft de producent niet te wachten totdat de consument deze heeft voltooid. Een berichtenbroker helpt asynchrone verwerking van berichten.
Load balancing
Producenten kunnen een groot aantal berichten plaatsen die door veel consumenten worden verwerkt. Gebruik een berichtenbroker om de verwerking over servers te distribueren en de doorvoer te verbeteren. Consumenten kunnen op verschillende servers worden uitgevoerd om de belasting te verspreiden. Consumenten kunnen dynamisch worden toegevoegd om het systeem uit te schalen wanneer dat nodig is of anderszins wordt verwijderd.
In het patroon Concurrerende consumenten wordt uitgelegd hoe u meerdere berichten gelijktijdig verwerkt om de doorvoer te optimaliseren, de schaalbaarheid en beschikbaarheid te verbeteren en de werkbelasting te verdelen.
Herverdeling van belasting
Het aantal berichten dat door de producent of een groep producenten wordt gegenereerd, kan variabel zijn. Soms kan er een groot volume zijn dat pieken in berichten veroorzaakt. In plaats van consumenten toe te voegen om dit werk af te handelen, kan een berichtenbroker fungeren als een buffer en consumenten berichten geleidelijk in hun eigen tempo leegmaken zonder het systeem te benadrukken.
Het patroon Load Leveling op basis van wachtrij biedt meer informatie.
Betrouwbare berichten
Een berichtenbroker helpt ervoor te zorgen dat berichten niet verloren gaan, zelfs niet als de communicatie tussen de producent en de consument mislukt. De producent kan berichten posten naar de berichtenbroker en de consument kan ze ophalen wanneer de communicatie opnieuw tot stand is gebracht. De producent wordt niet geblokkeerd, tenzij de verbinding met de berichtenbroker wordt verbroken.
Tolerante berichten
Een berichtenbroker kan tolerantie toevoegen aan de consumenten in uw systeem. Als een consument mislukt tijdens het verwerken van een bericht, kan een ander exemplaar van de consument dat bericht verwerken. Het opnieuw verwerken is mogelijk omdat het bericht zich in de broker blijft voordoen.
Technologiekeuzes voor een berichtenbroker
Azure biedt verschillende berichtenbrokerservices, elk met een scala aan functies. Voordat u een service kiest, moet u de intentie en vereisten van het bericht bepalen.
Azure Service Bus Messaging
Azure Service Bus Messaging-wachtrijen zijn goed geschikt voor het overdragen van opdrachten van producenten naar consumenten. Hier volgen enkele overwegingen.
Pull-model
Een consument van een Service Bus-wachtrij peilt voortdurend Service Bus om te controleren of er nieuwe berichten beschikbaar zijn. De client-SDK's en de Azure Functions-trigger voor Service Bus abstraheren dat model. Wanneer er een nieuw bericht beschikbaar is, wordt de callback van de consument aangeroepen en wordt het bericht naar de consument verzonden.
Gegarandeerde levering
Met Service Bus kan een consument de wachtrij bekijken en een bericht van andere consumenten vergrendelen.
Het is de verantwoordelijkheid van de consument om de verwerkingsstatus van het bericht te rapporteren. Alleen wanneer de consument het bericht markeert als verbruikt, verwijdert Service Bus het bericht uit de wachtrij. Als er een fout, time-out of crash optreedt, ontgrendelt Service Bus het bericht zodat andere consumenten het kunnen ophalen. Op deze manier gaan berichten niet verloren tijdens de overdracht.
Een producent kan per ongeluk hetzelfde bericht twee keer verzenden. Een producentexemplaren mislukken bijvoorbeeld na het verzenden van een bericht. Een andere producent vervangt het oorspronkelijke exemplaar en verzendt het bericht opnieuw. Azure Service Bus-wachtrijen bieden een ingebouwde ontdubbelingsfunctie waarmee dubbele berichten worden gedetecteerd en verwijderd. Er is nog steeds een kans dat er twee keer een bericht wordt bezorgd. Als een consument bijvoorbeeld mislukt tijdens het verwerken, wordt het bericht geretourneerd naar de wachtrij en wordt het opgehaald door dezelfde of een andere consument. De logica voor berichtverwerking in de consument moet idempotent zijn, zodat zelfs als het werk wordt herhaald, de status van het systeem niet wordt gewijzigd.
Berichtvolgorde
Als u wilt dat consumenten de berichten ontvangen in de volgorde waarin ze worden verzonden, garanderen Service Bus-wachtrijen de eerste in-first-out (FIFO) bestelde levering met behulp van sessies. Een sessie kan een of meer berichten bevatten. De berichten zijn gecorreleerd met de eigenschap SessionId . Berichten die deel uitmaken van een sessie, verlopen nooit. Een sessie kan worden vergrendeld voor een consument om te voorkomen dat de berichten worden verwerkt door een andere consument.
Zie Berichtensessies voor meer informatie.
Berichtpersistentie
Service Bus-wachtrijen ondersteunen tijdelijke ontkoppeling. Zelfs wanneer een consument het bericht niet beschikbaar of niet kan verwerken, blijft het in de wachtrij.
Langlopende controlepunttransacties
Zakelijke transacties kunnen lange tijd worden uitgevoerd. Elke bewerking in de transactie kan meerdere berichten bevatten. Gebruik controlepunten om de werkstroom te coördineren en tolerantie te bieden voor het geval een transactie mislukt.
Service Bus-wachtrijen staan controlepunten toe via de sessiestatusmogelijkheid. Statusgegevens worden incrementeel vastgelegd in de wachtrij (SetState) voor berichten die deel uitmaken van een sessie. Een consument kan bijvoorbeeld de voortgang bijhouden door elke nu en dan de status (GetState) te controleren. Als een consument uitvalt, kan een andere consument statusinformatie gebruiken om het laatst bekende controlepunt te bepalen om de sessie te hervatten.
Wachtrij met dode letters (DLQ)
Een Service Bus-wachtrij heeft een standaardsubqueee, de wachtrij voor dead-letter (DLQ) genoemd, voor het opslaan van berichten die niet kunnen worden bezorgd of verwerkt. Service Bus of de logica voor berichtverwerking in de consument kan berichten toevoegen aan de DLQ. De DLQ bewaart de berichten totdat ze uit de wachtrij worden opgehaald.
Hier volgen voorbeelden van wanneer een bericht zich in de DLQ bevindt:
Een gifbericht is een bericht dat niet kan worden verwerkt omdat het onjuist is ingedeeld of onverwachte informatie bevat. In Service Bus-wachtrijen kunt u gifberichten detecteren door de eigenschap MaxDeliveryCount van de wachtrij in te stellen. Als het aantal keren dat hetzelfde bericht wordt ontvangen groter is dan die eigenschapswaarde, verplaatst Service Bus het bericht naar de DLQ.
Een bericht is mogelijk niet langer relevant als het niet binnen een bepaalde periode wordt verwerkt. Met Service Bus-wachtrijen kan de producent berichten posten met een time-to-live-kenmerk. Als deze periode verloopt voordat het bericht wordt ontvangen, wordt het bericht in de DLQ geplaatst.
Bekijk berichten in de DLQ om de reden van de fout te bepalen.
Hybride oplossing
Service Bus overbrugt on-premises systemen en cloudoplossingen. On-premises systemen zijn vaak moeilijk te bereiken vanwege firewallbeperkingen. Zowel de producent als de consument (on-premises of de cloud) kan het Service Bus-wachtrijeindpunt gebruiken als de locatie voor ophalen en afzetten voor berichten.
Het patroon Messaging Bridge is een andere manier om deze scenario's af te handelen.
Onderwerpen en abonnementen
Service Bus ondersteunt het patroon Publisher-Subscriber via Service Bus-onderwerpen en -abonnementen.
Deze functie biedt de producent een manier om berichten naar meerdere consumenten uit te zenden. Wanneer een onderwerp een bericht ontvangt, wordt het doorgestuurd naar alle geabonneerde consumenten. Een abonnement kan eventueel filtercriteria hebben waarmee de consument een subset berichten kan ophalen. Elke consument haalt berichten op van een abonnement op een vergelijkbare manier als een wachtrij.
Zie Azure Service Bus-onderwerpen voor meer informatie.
Azure Event Grid
We raden Azure Event Grid aan voor discrete gebeurtenissen. Event Grid volgt het patroon Publisher-Subscriber. Wanneer gebeurtenisbronnen gebeurtenissen activeren, worden ze gepubliceerd naar Event Grid-onderwerpen. Consumenten van deze gebeurtenissen maken Event Grid-abonnementen door gebeurtenistypen en gebeurtenis-handler op te geven waarmee de gebeurtenissen worden verwerkt. Als er geen abonnees zijn, worden de gebeurtenissen verwijderd. Elke gebeurtenis kan meerdere abonnementen hebben.
Pushmodel
Event Grid stuurt berichten door aan de abonnees in een pushmodel. Stel dat u een Event Grid-abonnement hebt met een webhook. Wanneer een nieuwe gebeurtenis binnenkomt, plaatst Event Grid de gebeurtenis op het webhook-eindpunt.
Geïntegreerd met Azure
Kies Event Grid als u meldingen wilt ontvangen over Azure-resources. Veel Azure-services fungeren als gebeurtenisbronnen met ingebouwde Event Grid-onderwerpen. Event Grid ondersteunt ook verschillende Azure-services die kunnen worden geconfigureerd als gebeurtenis-handlers. U kunt zich eenvoudig abonneren op deze onderwerpen om gebeurtenissen te routeren naar gebeurtenis-handlers van uw keuze. U kunt event grid bijvoorbeeld gebruiken om een Azure-functie aan te roepen wanneer een blobopslag wordt gemaakt of verwijderd.
Aangepaste onderwerpen
Maak aangepaste Event Grid-onderwerpen als u gebeurtenissen wilt verzenden vanuit uw toepassing of een Azure-service die niet is geïntegreerd met Event Grid.
Als u bijvoorbeeld de voortgang van een hele zakelijke transactie wilt zien, wilt u dat de deelnemende services gebeurtenissen genereren wanneer ze hun afzonderlijke bedrijfsactiviteiten verwerken. In een web-app worden deze gebeurtenissen weergegeven. Een manier om deze taak uit te voeren, is door een aangepast onderwerp te maken en een abonnement toe te voegen met uw web-app die is geregistreerd via een HTTP-webhook. Naarmate zakelijke services gebeurtenissen naar het aangepaste onderwerp verzenden, pusht Event Grid ze naar uw web-app.
Gefilterde gebeurtenissen
U kunt filters in een abonnement opgeven om Event Grid te instrueren om slechts een subset van gebeurtenissen naar een specifieke gebeurtenis-handler te routeren. U geeft de filters op in het abonnementsschema. Elke gebeurtenis die naar het onderwerp wordt verzonden met waarden die overeenkomen met het filter, wordt automatisch doorgestuurd naar dat abonnement.
Inhoud in verschillende indelingen wordt bijvoorbeeld geüpload naar Blob Storage. Telkens wanneer een bestand wordt toegevoegd, wordt er een gebeurtenis gegenereerd en gepubliceerd naar Event Grid. Het gebeurtenisabonnement heeft mogelijk een filter waarmee alleen gebeurtenissen voor afbeeldingen worden verzonden, zodat een gebeurtenishandler miniaturen kan genereren.
Zie Gebeurtenissen filteren voor Event Grid voor meer informatie over filteren.
Hoge doorvoersnelheid
Event Grid kan 10.000.000 gebeurtenissen per seconde per regio routeren. De eerste 100.000 bewerkingen per maand zijn gratis. Zie voor kostenoverwegingen hoeveel kost Event Grid?
Tolerante levering
Hoewel geslaagde levering voor gebeurtenissen niet zo cruciaal is als opdrachten, wilt u mogelijk nog steeds enige garantie, afhankelijk van het type gebeurtenis. Event Grid biedt functies die u kunt inschakelen en aanpassen, zoals beleid voor opnieuw proberen, verlooptijd en onbestelbare letters. Zie De bezorging van Event Grid-berichten en probeer het opnieuw voor meer informatie.
Het proces voor opnieuw proberen van Event Grid kan helpen bij tolerantie, maar het is niet fail-safe. In het proces voor opnieuw proberen kan Event Grid het bericht meerdere keren bezorgen, overslaan of een aantal nieuwe pogingen vertragen als het eindpunt lange tijd niet meer reageert. Zie Schema voor opnieuw proberen voor meer informatie.
U kunt niet-bezorgde gebeurtenissen persistent maken voor een blob-opslagaccount door dead-lettering in te schakelen. Er is een vertraging bij het bezorgen van het bericht aan het blob-opslageindpunt en als dat eindpunt niet reageert, wordt de gebeurtenis genegeerd door Event Grid. Zie Locatie voor dode letters instellen en beleid voor opnieuw proberen voor meer informatie.
Azure Event Hubs
Wanneer u met een gebeurtenisstroom werkt, is Azure Event Hubs de aanbevolen berichtenbroker. In wezen is het een grote buffer die grote hoeveelheden gegevens met lage latentie kan ontvangen. De ontvangen gegevens kunnen snel worden gelezen via gelijktijdige bewerkingen. U kunt de ontvangen gegevens transformeren met behulp van elke realtime analyseprovider. Event Hubs biedt ook de mogelijkheid om gebeurtenissen op te slaan in een opslagaccount.
Snelle opname
Event Hubs kan miljoenen gebeurtenissen per seconde opnemen. De gebeurtenissen worden alleen aan de stream toegevoegd en worden geordend op tijd.
Pull-model
Net als Event Grid biedt Event Hubs ook mogelijkheden voor Publisher-Subscriber. Een belangrijk verschil tussen Event Grid en Event Hubs is de manier waarop gebeurtenisgegevens beschikbaar worden gesteld aan de abonnees. Event Grid pusht de opgenomen gegevens naar de abonnees, terwijl Event Hubs de gegevens beschikbaar maakt in een pull-model. Wanneer gebeurtenissen worden ontvangen, voegt Event Hubs deze toe aan de stream. Een abonnee beheert de cursor en kan vooruit en terug in de stream gaan, een tijdverschil selecteren en een reeks opnieuw afspelen in zijn tempo.
Streamprocessors zijn abonnees die gegevens ophalen uit Event Hubs voor transformatie en statistische analyse. Gebruik Azure Stream Analytics en Apache Spark voor complexe verwerking, zoals aggregatie in de loop van de tijdvensters of anomaliedetectie.
Als u op elke gebeurtenis per partitie wilt reageren, kunt u de gegevens ophalen met behulp van de eventprocessorhost of met behulp van een ingebouwde connector zoals Azure Logic Apps om de transformatielogica te bieden. Een andere optie is om Azure Functions te gebruiken.
Partitionering
Een partitie is een deel van de gebeurtenisstroom. De gebeurtenissen worden gedeeld met behulp van een partitiesleutel. Verschillende IoT-apparaten verzenden bijvoorbeeld apparaatgegevens naar een Event Hub. De partitiesleutel is de apparaat-id. Wanneer gebeurtenissen worden opgenomen, worden deze door Event Hubs verplaatst naar afzonderlijke partities. Binnen elke partitie worden alle gebeurtenissen geordend op tijd.
Een consument is een exemplaar van code waarmee de gebeurtenisgegevens worden verwerkt. Event Hubs volgt een gepartitioneerd consumentenpatroon. Elke consument leest alleen een specifieke partitie. Het hebben van meerdere partities resulteert in snellere verwerking omdat de stream gelijktijdig kan worden gelezen door meerdere consumenten.
Exemplaren van dezelfde consument vormen één consumentengroep. Meerdere consumentengroepen kunnen dezelfde stroom met verschillende intenties lezen. Stel dat een gebeurtenisstroom gegevens van een temperatuursensor bevat. Eén consumentengroep kan de stroom lezen om afwijkingen te detecteren, zoals een piek in temperatuur. Een andere stroom kan dezelfde stroom lezen om een doorlopende gemiddelde temperatuur in een tijdelijk venster te berekenen.
Event Hubs ondersteunt het patroon Publisher-Subscriber door meerdere consumentengroepen toe te staan. Elke consumentengroep is een abonnee.
Zie Partities voor meer informatie over Partitionering van Event Hubs.
Event Hubs Capture
Met de functie Capture kunt u de gebeurtenisstroom opslaan in een Azure Blob Storage of Data Lake Storage. Deze manier om gebeurtenissen op te slaan is betrouwbaar omdat zelfs als het opslagaccount niet beschikbaar is, capture uw gegevens gedurende een bepaalde periode bewaart en vervolgens naar de opslag schrijft nadat het beschikbaar is.
Opslagservices kunnen ook aanvullende functies bieden voor het analyseren van gebeurtenissen. Als u bijvoorbeeld gebruikmaakt van de toegangslagen van een blob-opslagaccount, kunt u gebeurtenissen opslaan in een dynamische laag voor gegevens die regelmatig toegang nodig hebben. U kunt deze gegevens gebruiken voor visualisatie. U kunt ook gegevens opslaan in de archieflaag en af en toe ophalen voor controledoeleinden.
Capture slaat alle gebeurtenissen op die zijn opgenomen door Event Hubs en is handig voor batchverwerking. U kunt rapporten over de gegevens genereren met behulp van een MapReduce-functie. Vastgelegde gegevens kunnen ook fungeren als de bron van waarheid. Als bepaalde feiten zijn gemist tijdens het samenvoegen van de gegevens, kunt u verwijzen naar de vastgelegde gegevens.
Zie Gebeurtenissen vastleggen via Azure Event Hubs in Azure Blob Storage of Azure Data Lake Storage voor meer informatie over deze functie.
Ondersteuning voor Apache Kafka-clients
Event Hubs biedt een eindpunt voor Apache Kafka-clients . Bestaande clients kunnen hun configuratie bijwerken om naar het eindpunt te verwijzen en gebeurtenissen naar Event Hubs te verzenden. U hoeft geen codewijzigingen aan te brengen.
Zie Event Hubs voor Apache Kafka voor meer informatie.
Cross-overscenario's
In sommige gevallen is het voordelig om twee berichtenservices te combineren.
Het combineren van services kan de efficiëntie van uw berichtensysteem verhogen. In uw zakelijke transactie gebruikt u bijvoorbeeld Azure Service Bus-wachtrijen om berichten te verwerken. Wachtrijen die meestal niet-actief zijn en berichten ontvangen, zijn af en toe inefficiënt, omdat de consument voortdurend de wachtrij voor nieuwe berichten peilt. U kunt een Event Grid-abonnement met een Azure-functie instellen als gebeurtenis-handler. Telkens wanneer de wachtrij een bericht ontvangt en er geen consumenten luisteren, verzendt Event Grid een melding die de Azure-functie aanroept die de wachtrij leeg maakt.
Zie het overzicht van Azure Service Bus-integratie met Event Grid voor meer informatie over het verbinden van Service Bus met Event Grid.
De Enterprise-integratie met behulp van berichtwachtrijen en referentiearchitectuur voor gebeurtenissen toont een implementatie van Service Bus naar Event Grid-integratie.
Hier volgt een ander voorbeeld: Event Grid ontvangt een reeks gebeurtenissen waarin voor sommige gebeurtenissen een werkstroom is vereist, terwijl anderen voor meldingen zijn. De metagegevens van het bericht geven het type gebeurtenis aan. Een manier om onderscheid te maken, is door de metagegevens te controleren met behulp van de filterfunctie in het gebeurtenisabonnement. Als er een werkstroom is vereist, verzendt Event Grid deze naar de Azure Service Bus-wachtrij. De ontvangers van die wachtrij kunnen de benodigde acties uitvoeren. De meldingen worden verzonden naar Logic Apps om e-mailberichten met waarschuwingen te verzenden.
Verwante patronen
Houd rekening met deze patronen bij het implementeren van asynchrone berichten:
- Patroon Concurrerende consumenten. Mogelijk moeten meerdere consumenten concurreren om berichten uit een wachtrij te lezen. In dit patroon wordt uitgelegd hoe u meerdere berichten gelijktijdig verwerkt om de doorvoer te optimaliseren, de schaalbaarheid en beschikbaarheid te verbeteren en de workload te verdelen.
- Priority Queue Pattern (Patroon Wachtrij met prioriteit). In gevallen waarin de bedrijfslogica vereist dat sommige berichten worden verwerkt vóór anderen, beschrijft dit patroon hoe berichten die door een producent met een hogere prioriteit worden geplaatst, sneller worden ontvangen en verwerkt door een consument dan berichten met een lagere prioriteit.
- Patroon Load leveling op basis van wachtrij. Dit patroon maakt gebruik van een berichtenbroker om te fungeren als buffer tussen een producent en een consument om de impact op beschikbaarheid en reactiesnelheid van onregelmatige zware belastingen voor beide entiteiten te minimaliseren.
- Retry-patroon. Een producent of consument kan mogelijk geen verbinding maken met een wachtrij, maar de redenen voor deze fout kunnen tijdelijk en snel worden doorgegeven. In dit patroon wordt beschreven hoe u deze situatie kunt afhandelen om tolerantie toe te voegen aan een toepassing.
- Scheduler Agent Supervisor-patroon. Berichten worden vaak gebruikt als onderdeel van een werkstroom-implementatie. Dit patroon laat zien hoe berichten een set acties in een gedistribueerde set services en andere externe resources kunnen coördineren en een systeem in staat stelt acties te herstellen en opnieuw uit te voeren die mislukken.
- Choreograafpatroon. Dit patroon laat zien hoe services berichten kunnen gebruiken om de werkstroom van een zakelijke transactie te beheren.
- Claimcontrolepatroon. Dit patroon laat zien hoe u een groot bericht splitst in een claimcontrole en een nettolading.
Communitybronnen.
Blogpost van Jonathon Oliver: Idempotentie
Blogpost van Martin Fowler: Wat bedoel je met "Event-Driven"?