Hvad betyder Hændelsesdrevet arkitektur?
I hændelsesdrevet arkitektur udsender et system en hændelse, når noget relevant er sket. Andre dele kan reagere uden at være kaldt direkte som led i en lang, tæt koblet kæde. En hændelse kan eksempelvis beskrive, at en ordre er oprettet eller et dokument er valideret.
En hændelse beskriver normalt noget, der er sket, mens en kommando beder nogen udføre noget. Skellet gør ansvar tydeligere. “Ordre oprettet” kan have flere interesserede modtagere; “send ordrebekræftelse” er en konkret handling med et mere afgrænset ansvar.
Uafhængige modtagere med fælles kontrakt
En hændelseskanal kan være en kø, en broker eller en vedvarende strøm. Modtagere behandler beskeder efter deres egne behov og kapacitet. Det kan gøre systemet mere fleksibelt, men flytter noget kompleksitet til levering, rækkefølge og observation.
En hændelse bør have identifikation, type, kilde og en kendt datastruktur. Den kan indeholde nødvendige data eller blot en reference, som modtageren slår op. Store datakopier gør modtageren mindre afhængig af opslag, men kan blive forældede. Referencer kan give aktuelle data, men kræver adgang til kildesystemet. Valget bør følge den konkrete proces.
Alle systemer er ikke opdaterede samtidig
Når modtagere arbejder asynkront, kan der gå tid mellem ændringen i kilden og opdateringen i andre systemer. Brugerflader og rapporter bør kunne vise denne forsinkelse. Aftal, hvordan dubletter, gamle beskeder og ukendte versioner håndteres. En fælles korrelationsidentifikation gør det lettere at følge samme forretningsforløb gennem flere tjenester. Uden den kan hver del se sund ud, selv om den samlede opgave er gået i stå.
Et eksempel fra praksis
Når et dokument er godkendt internt, udsendes en hændelse med dokument-ID og version. Én modtager opdaterer søgeindekset, en anden registrerer arkivering, og en tredje opretter en intern opgave. Hvis søgeindekset er midlertidigt utilgængeligt, kan de andre dele stadig fortsætte efter deres egne regler. Testen undersøger, om den forsinkede indeksopdatering kan genoptages, og om en ældre version ikke overskriver en nyere.
Typiske faldgruber
- At antage, at alle modtagere er opdaterede, når hændelsen er udsendt.
- At ændre hændelsens felter uden at tage hensyn til eksisterende modtagere.
- At udsende flere personoplysninger end modtagerne har brug for.
Det skal I afklare
- Skeln mellem hændelser og kommandoer.
- Definér identifikation, version og ansvar for hver hændelsestype.
- Test forsinkelse, dubletter og afstemning på tværs af tjenester.
Spørgsmål og svar
Er webhooks hændelsesdrevet arkitektur?
Webhooks kan være en del af den. Arkitekturen omfatter også, hvordan hændelser gemmes, fordeles, behandles og overvåges. Et enkelt webhook-kald beskriver ikke hele løsningen.
Skal alle systemer bygges sådan?
Nej. Et lille, synkront forløb kan være enklere. Hændelser er særligt relevante, når flere uafhængige processer skal reagere på ændringer og kan håndtere en vis forsinkelse.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- Microsoft: Event-driven architecture ↗Producenter, modtagere og asynkrone hændelseskanaler.
- CNCF: CloudEvents ↗Fælles beskrivelse af hændelsesdata mellem systemer.