Gebeurtenisafhankelijke architectuurstijl

Een gebeurtenisafhankelijke architectuur bestaat uit gebeurtenisproducers die een stroom gebeurtenissen genereert, en uit gebeurtenisconsumers die naar de gebeurtenissen luisteren.

Gebeurtenissen worden vrijwel realtime afgeleverd, zodat consumers onmiddellijk op de gebeurtenissen kunnen reageren. Producenten worden losgekoppeld van consumenten: een producent weet niet welke consumenten luisteren. Consumers zijn ook ontkoppeld van elkaar en elke consumer ziet alle gebeurtenissen. Dit wijkt af van een patroon met concurrerende consumers, waarbij consumers berichten uit een wachtrij halen en een bericht slechts één keer wordt verwerkt (ervan uitgaande dat er geen fouten worden gemaakt). In sommige systemen, zoals IoT, moeten gebeurtenissen bij zeer hoge volumes worden ingenomen.

Een gebeurtenisgestuurde architectuur kan een publiceren/abonneren-model (ook wel pub/sub genoemd) of een gebeurtenisstroommodel gebruiken.

• Pub/sub: De berichteninfrastructuur houdt abonnementen bij. Wanneer een gebeurtenis wordt gepubliceerd, wordt de gebeurtenis verzonden naar elk abonnee. Nadat een gebeurtenis is ontvangen, kan deze niet opnieuw worden afgespeeld en zien nieuwe abonnees de gebeurtenis niet.

• Gebeurtenissen streamen: gebeurtenissen worden naar een logboek geschreven. Gebeurtenissen zijn strikt geordend (binnen een partitie) en duurzaam. Clients abonneren zich niet op de stroom; in plaats daarvan kan een client een deel van de stroom lezen. De client is ervoor verantwoordelijk de positie in de stroom naar voren te halen. Dit betekent dat een client op elk gewenst moment kan deelnemen en gebeurtenissen opnieuw kan afspelen.

Consumers kennen een aantal veelvoorkomende variaties:

• Verwerking van eenvoudige gebeurtenissen. Een gebeurtenis activeert onmiddellijk een actie in de consumer. U kunt bijvoorbeeld Azure Functions gebruiken met een Service Bus-trigger, zodat een functie wordt uitgevoerd zodra een bericht in een Service Bus-onderwerp wordt gepubliceerd.

• Correlatie van basis gebeurtenis. Een consument moet een klein aantal discrete bedrijfsgebeurtenissen verwerken, meestal gecorreleerd door een bepaalde id, waarbij bepaalde informatie van eerdere gebeurtenissen moet worden bewaard die moeten worden gebruikt bij het verwerken van latere gebeurtenissen. Dit patroon wordt ondersteund door bibliotheken zoals NServiceBus en MassTransit.

• Verwerken van complexe gebeurtenissen. Een consument verwerkt een reeks gebeurtenissen, op zoek naar patronen in de gebeurtenisgegevens, met behulp van een technologie zoals Azure Stream Analytics. U kunt bijvoorbeeld uitlezingen van een ingesloten apparaat gedurende een bepaalde periode aggregeren en een melding genereren als het zwevend gemiddelde een zekere drempelwaarde overschrijdt.

• Verwerken van gebeurtenisstromen. Gebruik een platform voor gegevensstromen, zoals Azure IoT Hub of Apache Kafka, als een pijplijn om gebeurtenissen op te nemen en ze naar streamprocessors door te leiden. De streamprocessors verwerken of transformeren de stroom. Er kunnen meerdere streamprocessors zijn voor verschillende subsystemen van de toepassing. Deze benadering is zeer geschikt voor IoT-werkbelastingen.

De bron van de gebeurtenissen kan extern zijn, zoals fysieke apparaten in een IoT-oplossing. In dat geval moet het systeem in staat zijn de gegevens op te nemen bij een volume en doorvoer die door de gegevensbron wordt vereist.

In het bovenstaande logische diagram wordt elk type consumer als een vak weergegeven. In de praktijk zijn vaak meerdere exemplaren van een consumer aanwezig om te voorkomen dat de consumer een Single Point of Failure wordt. Er kunnen ook meerdere exemplaren nodig zijn om het volume en de frequentie van gebeurtenissen te verwerken. Ook kan één consumer gebeurtenissen voor meerdere threads verwerken. Dit kan uitdagingen opleveren als gebeurtenissen op volgorde moeten worden verwerkt of exact één keer semantiek moeten zijn vereist. Zie Coördinatie minimaliseren.

Wanneer gebruikt u deze architectuur?

• Meerdere subsystemen moeten dezelfde gebeurtenissen verwerken.
• Realtime verwerking met een minimum aan tijdsverlies.
• Verwerking van complexe gebeurtenissen, zoals patroonvergelijking of aggregatie binnen bepaalde tijdvensters.
• Gegevens van hoog volume en met hoge snelheid, zoals IoT.

Vergoedingen

• Producers en consumers worden ontkoppeld.
• Geen punt-naar-punt-integraties. Het is eenvoudig nieuwe gebruikers aan het systeem toe te voegen.
• Consumers kunnen onmiddellijk reageren op gebeurtenissen zodra ze binnenkomen.
• Uiterst schaalbaar en gedistribueerd.
• Subsystemen hebben onafhankelijke weergaven van de gebeurtenisstroom.

Uitdagingen

• Gegarandeerde levering. In sommige systemen, met name in IoT-scenario's, is het essentieel dat gebeurtenissen worden geleverd.
• Verwerking van gebeurtenissen op volgorde of slechts één keer. Elk type consumer wordt gewoonlijk uitgevoerd in meerdere exemplaren, voor tolerantie en schaalbaarheid. Dit kan een uitdaging creëren als de gebeurtenissen op volgorde moeten worden verwerkt (binnen een consumententype) of idempotent berichtverwerkingslogica niet is geïmplementeerd.
• Berichten in verschillende services coördineren. Bedrijfsprocessen omvatten vaak meerdere services die publiceren en abonneren op berichten om een consistent resultaat te bereiken voor een hele workload. Werkstroompatronen zoals het choreograafpatroon en Saga Orchestration kunnen worden gebruikt om berichtstromen over verschillende services betrouwbaar te beheren.

Aanvullende overwegingen

• De hoeveelheid gegevens die in een gebeurtenis moet worden opgenomen, kan een belangrijke overweging zijn die van invloed is op zowel prestaties als kosten. Door alle relevante informatie die nodig is voor verwerking in het evenement zelf te plaatsen, kan de verwerkingscode worden vereenvoudigd en extra zoekacties worden opgeslagen. Als u de minimale hoeveelheid informatie in een gebeurtenis plaatst, zoals slechts een paar id's, vermindert u de transporttijd en kosten, maar vereist de verwerkingscode om aanvullende informatie op te zoeken die nodig is. Bekijk dit blogbericht voor meer informatie hierover.
• Hoewel een aanvraag alleen zichtbaar is voor het onderdeel voor het verwerken van aanvragen, zijn gebeurtenissen vaak zichtbaar voor meerdere onderdelen in een workload, zelfs als deze onderdelen niet of niet bedoeld zijn om ze te gebruiken. Houd rekening met de informatie die u in gebeurtenissen opneemt om onbedoelde blootstelling aan informatie te voorkomen.

Verwante resources

• Communitydiscussievideo over de overwegingen voor het kiezen van een choreograaf en indeling.