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. Producers zijn ontkoppeld van consumers; een producer weet niet welke consumers er 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 gebeurtenisafhankelijke architectuur kan gebruikmaken van een pub-/submodel of een gebeurtenisstroommodel.

• 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 nieuwe abonnees zien 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.

• Verwerken van complexe gebeurtenissen. Een consumer verwerkt een reeks gebeurtenissen, zoekend naar patronen in de gegevensgebeurtenissen door middel van een technologie als Azure Stream Analytics of Apache Storm. 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.

• Verwerking van gebeurtenisstroom. 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 met zich mee brengen als gebeurtenissen op volgorde moeten worden verwerkt of exactly-once-semantiek vereisen. 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.

Voordelen

• Producers en consumers worden ontkoppeld.
• Geen punt-naar-puntintegraties. 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 probleem betekenen als de gebeurtenissen op volgorde moeten worden verwerkt (binnen een consumertype) of als de verwerkingslogica niet idempotent is.

Aanvullende overwegingen

• De hoeveelheid gegevens die in een gebeurtenis moet worden meegenomen, kan een belangrijke overweging zijn die van invloed is op zowel de prestaties als de kosten. Door alle relevante informatie die nodig is voor verwerking in de gebeurtenis zelf te plaatsen, kunt u de verwerkingscode vereenvoudigen en extra zoekbewerkingen opslaan. Door de minimale hoeveelheid informatie in een gebeurtenis te plaatsen, zoals slechts een paar id's, worden de transporttijd en -kosten beperkt, maar is de verwerkingscode vereist om eventuele aanvullende informatie op te zoeken die nodig is. Bekijk dit blogbericht voor meer informatie.