Hændelsesdrevne arkitekturer

Hændelsesdrevet arkitektur (EDA) er et designmønster, hvor komponenter kommunikerer ved at udsende og reagere på hændelser. I stedet for at kalde funktioner direkte publicerer dele af systemet hændelser, når der sker noget interessant.

Denne tilgang bidrager til at skabe systemer, der er:

• Løst koblede: Komponenterne behøver ikke at kende hinanden.
• Skalerbare: Du kan nemt tilføje flere forbrugere uden at ændre producenterne.
• Modstandsdygtige: Fejl i én del er mindre tilbøjelige til at få hele systemet til at bryde sammen.

En hændelse er en registrering af noget, der er sket. Det er normalt en lille, uforanderlig meddelelse, der indeholder data om hændelsen, men ikke kommandoen til at udføre en handling.

Tænk på det som en avisoverskrift: "Bruger oprettet" eller "Ordre afgivet".

Vigtige egenskaber:

• Faktum: Den beskriver noget, der er sket.
• Uforanderlig: Når en hændelse først er publiceret, ændres den ikke.
• Informativ: Indeholder relevante data (f.eks. bruger-ID og tidsstempel).

I en EDA er der to hovedroller:

• Producenter: Det er komponenter, der opretter og publicerer hændelser. Når en bruger tilmelder sig, kan "User Service" producere hændelsen "User Signed Up".
• Forbrugere: Det er komponenter, der abonnerer på hændelser og reagerer på dem. En "Welcome Email Service" kan forbruge hændelser af typen "User Signed Up" for at sende en velkomstmail.

Producenten er ligeglad med, hvem der forbruger hændelsen, og forbrugerne er ligeglade med, hvem der producerede den. Det muliggør en effektiv løs kobling!

Hvordan finder producenter og forbrugere hinanden? Det er her, en meddelelsesmægler kommer ind i billedet. En mægler fungerer som mellemled: Den modtager hændelser fra producenter og leverer dem til interesserede forbrugere.

Den tilbyder:

• Løs kobling: Producenter og forbrugere kommunikerer ikke direkte.
• Vedholdenhed: Hændelser kan gemmes, indtil forbrugerne er klar.
• Routing: Sender hændelser til de korrekte forbrugere baseret på regler.

Almindelige eksempler omfatter RabbitMQ, Apache Kafka og AWS SQS.

Clojure egner sig godt til hændelsesdrevne systemer på grund af fokusset på uforanderlighed og samtidighed. Vi bruger ofte dedikerede klientbiblioteker til at interagere med meddelelsesmæglere.

Til RabbitMQ er langohr et populært valg i Clojure. Det tilbyder en enkel API til at oprette forbindelse samt publicere og forbruge meddelelser.

Lad os se på, hvordan man opsætter en grundlæggende forbindelse og publicerer en hændelse ved hjælp af langohr (konceptuelt, da en komplet opsætning er for omfattende til et lille kodestykke).

For at publicere en hændelse opretter vi forbindelse til meddelelsesmægleren og sender vores hændelsesdata til en bestemt exchange. En exchange fungerer som et postkontor, der dirigerer meddelelser.

Her er et forenklet eksempel på publicering af hændelsen "user.signed-up" til en topic-exchange med navnet "events":

Forbrugere opretter forbindelse til mægleren og erklærer en kø. Derefter binder de denne kø til en exchange med en routing-nøgle for at modtage bestemte typer hændelser. Når en hændelse ankommer, behandler en handlerfunktion den.

Dette eksempel viser en forbruger, der lytter efter hændelser af typen "user.signed-up":

Ud over simpel løs kobling tilbyder EDA betydelige fordele i komplekse systemer:

• Skalerbarhed: Tilføj nemt flere forbrugere, der kan behandle hændelser parallelt, eller skalér producenter uafhængigt.
• Modstandsdygtighed: Hvis en forbruger svigter, holder meddelelsesmægleren hændelserne, indtil forbrugeren er tilbage, så datatab undgås.
• Revisionsspor: Hændelser kan logges, så der oprettes et tydeligt revisionsspor over systemets aktiviteter.
• Behandling i realtid: Reagér øjeblikkeligt på ændringer på tværs af forskellige tjenester.

Det er et grundlæggende mønster for mikrotjenester og distribuerede systemer.

Et beslægtet, effektivt begreb er Event Sourcing. I stedet for at gemme en applikations aktuelle tilstand gemmer du alle ændringer som en sekvens af uforanderlige hændelser.

Applikationens tilstand kan derefter genskabes ved at afspille disse hændelser igen. Det giver en komplet historisk registrering og forenkler kompleks tilstandshåndtering i visse scenarier.

Selvom begreberne er beslægtede, fokuserer EDA på kommunikation mellem tjenester, mens Event Sourcing fokuserer på, hvordan en enkelt tjeneste håndterer sin egen tilstand.

Godt klaret! Du har udforsket grundprincipperne i hændelsesdrevne arkitekturer.

• Vi lærte, at hændelser er uforanderlige fakta om ting, der er sket.
• Producenter udgiver hændelser, og forbrugere reagerer på dem.
• En meddelelsesbroker faciliterer denne kommunikation og sikrer afkobling og robusthed.
• Clojure-biblioteker som langohr gør det nemt at integrere med brokere som RabbitMQ.

EDA er et vigtigt mønster til opbygning af skalerbare, robuste og afkoblede backend-systemer. Bliv ved med at øve dig i meddelelsessystemer for at styrke din forståelse!