Hændelsesdrevet arkitektur · Mindmaps
Hændelsesdrevet arkitektur. Et redigerbart mindmap med farvede grene, underemner og forbindelser. Buede linjer viser sammenhænge; pile bruges, når retningen har betydning.
Hændelsesdrevet arkitektur afkobler systemer ved at lade dem kommunikere gennem hændelser: producenter publicerer, hvad der er sket, bussen router det til subscribers, og et hændelseslager gemmer historikken.
Hændelsesdrevet arkitektur · Mindmaps
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
Sådan læser du mindmappet
- Begynd ved emnet i midten, og følg en farvet gren til de tilhørende idéer.
- Buede linjer viser sammenhænge; pile bruges, når retningen har betydning.
Producers
Denne gren samler “An event records something that HAPPENED — “order placed”, “user updated” — not an instruction to anyone in particular. Producers don't know who is listening.”.
Event bus
Denne gren samler “Events are published to the bus”, “The bus decouples producers from consumers: a producer keeps publishing whether or not any consumer is ready, and consumers subscribe to the events they care about.”.
Consumers
Denne gren samler “Consumers process events asynchronously”, “The test of the architecture: add a service that reacts to existing events, and not one producer changes. This is the flexibility the pattern buys.”.
Event history
Denne gren samler “The event log is the system of record: every state change, in order, forever. Current state is a projection that can be rebuilt from it.”, “Events can be replayed for audit or recovery”.
Forbindelser på tværs
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.
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
Tilpas emnet i midten
Giv emnet et navn, der passer til dit projekt eller din undervisning.
Udbyg grenene
Rediger idéerne, og tilføj eksempler eller noter.
Forbind beslægtede idéer
Tegn forbindelser på tværs af grene; brug kun pile, når retningen betyder noget.
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.
Rediger dette mindmap i QueryChart
Åbn mindmappet på et redigerbart lærred. Flyt idéer, tilføj grene, og tegn forbindelser.