Hændelsesdrevet arkitektur — producér, publicér, forbrug

Hændelsesdrevet arkitektur — producér, publicér, forbrug

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs fra venstre mod højre: udsend, publicér, forbrug og bevar.
• Producentrækken peger aldrig på en forbruger — hver pil krydser bussen, og det er afkoblingen gjort synlig.
• Den nederste gren er hændelseslageret: de samme hændelser, der forbruges i realtid, bevares også til genafspilning og revision.

At producere og publicere

»Tjenester producerer domænehændelser« er producentens eneste ansvar — at registrere, at noget er sket. »Hændelser publiceres til bussen« og »Bussen router hændelser til subscribers« er publiceringstrinnet: bussen tager imod hændelser og leverer dem til dem, der har abonneret. Kommentaren på udsendelsesboksen gør reglen eksplicit — producenter ved ikke, hvem der lytter, og det er dét, der gør systemet udvideligt.

Forbrug i realtid

»Forbrugere behandler hændelser asynkront« er vejen til højre: subscribers handler på hver hændelse — opdaterer en læsemodel, sender en mail, udløser et workflow — i deres eget tempo. Den asynkrone behandling er grunden til, at en langsom forbruger ikke gør en producent langsom, og til at diagrammet holder de to i hver sin banegruppe.

At bevare historikken

»Hændelseslageret bevarer hele historikken« registrerer hver hændelse i rækkefølge, og »Hændelser kan afspilles igen til revision eller genopretning« er dét, registreringen er til for — at genopbygge en tilstand, besvare et revisionsspørgsmål eller fodre en ny forbruger med fortiden. »Nye forbrugere kommer til uden at røre producenterne« er prøven på arkitekturen: fordi historikken findes, og bussen router efter abonnement, ændrer det intet opstrøms at tilføje en tjeneste.

Key relationships and takeaways

• En hændelse registrerer, hvad der er sket; den er ikke en kommando til nogen bestemt.
• Bussen afkobler producenter fra forbrugere — ingen af dem kender den andens identitet eller tempo.
• Hændelseslageret gør historikken til en autoritativ kilde, der kan afspilles igen.
• Forbrugere er asynkrone: en langsom forbruger blokerer aldrig en producent.
• Nye forbrugere kommer til ved at abonnere — hele arkitekturens udsagn om fleksibilitet hviler på det.

When to use this visual

• At undervise et team, der går fra forespørgsel/svar til hændelser, i opdelingen producent-bus-forbruger.
• At designe en ny integration: hændelseslageret svarer på, om historikken skal bevares, eller om hændelser kan forbruges og glemmes.
• At gennemgå et eksisterende hændelsesdrevet system for den klassiske fejl — en forbruger, der reelt er en synkron afhængighed.

Sådan fungerer det

1. Omdøb parterne til jeres eget system

   Erstat producenter, forbrugere og hændelsesnavne med jeres reelle tjenester og de hændelser, de publicerer, og tilføj dem, det generiske diagram mangler.

2. Navngiv topics og deres forbrugere

   Notér ved hver hændelse på bussen navnet på topicet, og hvem der abonnerer, så afkoblingen bliver et dokumenteret kort frem for et udsagn.

3. Tilføj grenene for fejl

   Indsæt, hvad der sker, når bussen er nede, en forbruger dør midt i en hændelse, eller en hændelse ankommer to gange — hver med den idempotens eller den retry, der håndterer det.

4. Udvid hændelseslageret

   Tilføj de regler for bevaring og genafspilning, jeres system faktisk bruger — hvor længe historikken gemmes, og hvilke tilstande der genopbygges ud fra den — så banegruppen »Hændelseslager« afspejler jeres politik.

Ofte stillede spørgsmål

Hvad er hændelsesdrevet arkitektur?

Det er en arkitekturstil, hvor komponenter kommunikerer ved at publicere og abonnere på hændelser frem for at kalde hinanden direkte. En tjeneste, der opretter eller ændrer noget, publicerer en hændelse, der beskriver, hvad der er sket; bussen router den til hver subscriber, det angår; og et hændelseslager gemmer historikken. Fordi producenter aldrig navngiver deres forbrugere, kan systemet vokse uden at røre det, der allerede findes.

Hvad er forskellen på en kommando og en hændelse?

En kommando er en instruktion rettet mod en bestemt modtager — »behandl denne ordre« — og den forventer et udfald. En hændelse er en registrering af, at noget allerede er sket — »ordre afgivet« — og den navngiver ingen modtager. Forskellen betyder noget, fordi kommandoer kobler afsenderen til modtageren, mens hændelser lader modtageren være fri til at ændre sig. Producenterne i diagrammet udsender kun hændelser, og det er dét, der holder bussen løs.

Hvad er hændelseslageret til for?

Hændelseslageret er systemets bevarede historik: hver hændelse, i rækkefølge, permanent. Det tjener tre formål — revision (hvad skete der, og hvornår), genopretning (genopbyg en tjenestes tilstand ved at afspille dens hændelser igen) og udvidelse (en ny forbruger kan indhente det forsømte ved at læse fortiden). Diagrammet tegner det som den nederste gren, fordi det er en anden anvendelse af de samme hændelser, som forbrugerne behandler i realtid.

Hvilke fejltilstande har hændelsesdrevet arkitektur?

De klassiske er: hændelser, der leveres mere end én gang (så forbrugere skal være idempotente), hændelser, der behandles i forkert rækkefølge (så forbrugere skal håndtere rækkefølgen), og dead letter-køen (hændelser, der fejler igen og igen). Den asynkrone behandling i diagrammet er dét, der gør dem håndterbare — en forbruger kan prøve igen uden at blokere producenten — og derfor er grenene for fejl i vejledningstrinnene den praktiske halvdel af designet.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis dette hændelsesdrevne lærred som dit eget diagram, omdøb producenter og forbrugere til jeres egne tjenester, og tegn jeres hændelser.

Redigér dette diagram i QueryChart (FlowJam)