Kernel bazat pe evenimente
Ce este kernelul condus de eveniment
Event-Driven Core (EDC) este „coloana vertebrală” a arhitecturii, în care faptele de afaceri sunt capturate și distribuite ca evenimente imuabile, iar restul funcționalității (citire, integrare, analiză, cache-uri, notificări) este construită pe partea de sus a fluxului acestor evenimente. Nucleul stabilește contractul de eveniment, regulile de livrare și invarianții de ordine/idempotență, oferind conectivitate slabă și scalabilitate.
Ideea cheie: mai întâi scrieți faptul (de bază), apoi îmbogățiți-l independent și proiectați-l în modelele dorite. Acest lucru reduce conectivitatea și crește rezistența la eșecuri parțiale.
Obiective și proprietăți EDC
Adevărul: Fiecare eveniment este o înregistrare imuabilă a „ceea ce s-a întâmplat”.
Conectivitate slabă: producătorii nu cunosc consumatorii; extinderea sistemului - prin adăugarea de abonați.
Scalare: creștere orizontală după partid/subiect, consumatori independenți.
Observabilitate și audit: identificatori end-to-end, reproductibilitate, retenții și reluare.
Evoluția gestionată: versiuni de schemă, compatibilitate, depreciere.
Componente arhitecturale
1. Bus/event broker: Kafka/NATS/Pulsar/SNS + SQS - canale, petreceri, retenţii.
2. Schema Registry: JSON Schema/Avro/Protobuf pentru compatibilitate și evoluție.
3. Outbox/contur CDC: fixarea faptelor atomice + publicarea fără „scriere dublă”.
4. Proiecții/Citiri (CQRS): vizualizări materializate pentru interogări rapide.
5. Sagas/orchestrație: coordonarea proceselor de lungă durată prin evenimente/echipe.
6. Îmbogățire: subiecte individuale „.bogățit ”/„ .derived” fără a afecta calea critică.
7. Observabilitate: trasare, exploatare forestieră, măsurători după evenimente și lag-uri.
Modelul evenimentului
Tipuri de evenimente
Domenii Evenimente: Business Facts ('payment. autorizat „,” kyc. aprobat ").
Evenimente de integrare: axate pe sisteme externe (stabile, în schimbare lentă).
Modificarea capturii de date (CDC): modificări tehnice ale înregistrării (utilizarea pentru migrații/integrări).
Audit/Telemetrie: actori, securitate, SLA.
Atribute necesare (Core)
json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}Recomandări: 'event _ id' este unic la nivel global,' partition _ key 'stabilește ordinea pentru entitate,' trace _ id' oferă corelație.
Semantică de livrare și idempotență
Cel puțin o dată (implicit pentru mulți brokeri): Consumatorii trebuie să fie idempotent.
At-most-once: acceptabil numai pentru telemetrie secundară.
Exact o dată: realizat la nivelul fluxului și de stocare prin tranzacții/chei idempotente/cutii de udare (mai scumpe, au nevoie de un motiv bun).
Modelul idempotenței consumatorilor
Dedup tabel de 'event _ id'/' (event_id, consumer_id)' cu TTL ≥ topic retention.
Upsert în loc de inserare; versioning projections by 'secventa '/' happened _ at'.
Tranzacții în cadrul tranzacției: marcați „văzut” + schimbare de stat.
Comanda și partiționarea
Ordine garantată în cadrul partidului.
Selectați 'partition _ key', astfel încât toate evenimentele aceleiași entități agregate să se încadreze în același lot ('user _ id',' payment _ id').
Evitați „cheile fierbinți”: hash cu sare/sub-chei dacă aveți nevoie pentru a distribui sarcina.
Scheme și evoluție
Aditiv-first: noi câmpuri opționale, interzicerea schimbării tipurilor/semanticii fără o versiune majoră.
Compatibilitate: ÎNAPOI/ÎNAINTE în registrul schemei; CI blochează schimbările incompatibile.
Denumire: 'domeniu. acțiune. v {major} '(' plata. autorizat. v1 ').
Migraţii: publicaţi perechi 'v1' şi 'v2' în paralel, oferiţi dual-write prin outbox, trageţi 'v1' după tranziţie.
Outbox и CDC
Outbox (recomandat pentru servicii tranzactionale)
1. Într-o singură tranzacție de baze de date: salvați înregistrarea domeniului și evenimentul în outbox.
2. Editorul de fundal citește outbox-ul, publică brokerului, marchează „trimis”.
3. Garanții: nici o „pierdere” de fapt în cădere, nici o desincronizare.
CDC (Modificarea capturii de date)
Adecvat pentru sistemele/migrațiile existente; sursa - jurnal de replicare DB.
Necesită filtrarea/transcodarea la evenimente de domeniu (nu traduceți tabele brute în afara).
CQRS și proiecții
Comenzile schimbă starea (adesea sincron), evenimentele formează proiecții (asincron).
Proiecțiile sunt concepute pentru interogări (căutare, liste, rapoarte), actualizate de către abonați.
Desincronizarea temporară este norma: arată un UX stabil („datele vor fi actualizate în câteva secunde”).
Sagas: Coordonarea proceselor
Orchestrație: Un coordonator trimite comenzi și așteaptă evenimente.
Coregrafie: participanții reacționează la evenimentele celuilalt (mai simplu, dar necesită disciplină în contracte).
Reguli: compensații clare și temporizări, pași repetabili, manipulatori idempotenți.
Observabilitate
Trace/Span: Trace 'trace _ id'/' span _ id' prin anteturi la generarea evenimentelor.
Valori: întârzierea consumatorilor, rata de publicare/consum, rata literelor moarte, cota de eliminare a duplicatelor.
DLQ/parcare: mesaje nereușite - la un subiect separat cu alertă; asigură reprocesarea.
Securitate și conformitate
Clasificarea datelor: nucleul conține doar minimul necesar de date PII/financiare (modelul piramidei inverse), detalii - în îmbogățire.
Semnătura/hash-ul atributelor critice, controlul integrității.
Criptare în zbor și în repaus, drepturi de partiționare după subiect/consumator (IAM/ACL).
Politicile de retenție și drepturile de uitat: clar definite pentru fiecare subiect.
Performanță și stabilitate
Backpressure: consumatorii au concurență limitată, brokerul are cote/limite.
Lot și compresie-Grup înregistrează pentru a reduce deasupra capului.
Retrai cu jitter și DLQ în loc de încercări nesfârșite.
Reechilibrare-rezistență: magazin compensează tranzacțional/extern, accelera un start rece cu instantanee.
Șabloane tipice pentru evenimente
Core de plată
"plata. inițiat. v1 '→' plata. autorizat. v1 '→' plata. capturat. v1 '→' plata. stabilit. v1 '
Refuzuri: "plata. a refuzat. v1 ',' plata. rambursate. v1 '
Partiționare: 'payment _ id'
SLA: lag de bază ≤ 2c p95; Idempotența consumatorilor este obligatorie.
CCM/verificare
'kyc. a început. v1 '→' kyc. document. primit. v1 '→' kyc. aprobat. v1 '/' kyc. respinsă. v1 '
PII - minim; detalii document - in 'kyc. îmbogățit. v1 'cu acces restricţionat.
Audit/Securitate
Audit. înregistrat. v1 „cu atribute” actor „,” subiect „,” acțiune „,” a avut loc _ la „,” trace _ id'.
Păstrarea/arhivarea continuă; Integritate sporită (WORM)
Antipatterns
Eveniment Fat: sarcini utile supraîncărcate inutil, scurgeri PII.
RPC ascuns prin evenimente: așteptând răspunsuri sincrone „aici și acum”.
CDC-uri brute spre exterior: Conectivitate strânsă la schema DB.
Fără idempotență la consumatori: dublele duc la efecte secundare duble.
Un subiect comun „pentru orice”: conflict de interese, ordine problematică, evoluție complexă.
Implementare EDC pas cu pas
1. Maparea domeniului: Evidențiați agregatele cheie și ciclurile de viață.
2. Catalog de evenimente: nume, sensuri, invarianți, câmpuri obligatorii.
3. Scheme și Registry - Selectați un format, activați regulile de compatibilitate.
4. Outbox/CDC: Pentru fiecare producător, definiți un mecanism de publicare a faptelor.
5. Partiționare: Selectați tastele și evaluați tastele fierbinți/repartiție.
6. Idempotență: model de eliminare a duplicatelor + tranzacționalitate a consumatorilor.
7. Proiectii-Defini modele materializate şi actualiza SLA-uri.
8. Observabilitate: urmărire, lag-uri, DLQ, alerte.
9. Securitate/PII: clasificarea datelor, criptare, ACL.
10. Ghid pentru evoluție: politica versiunii, depreciere, scriere dublă pentru migrații.
Lista de verificare a producției
- Fiecare eveniment are 'event _ id',' trace _ id', 'happened _ at', 'partition _ key'.
- Scheme în registru, verificări de compatibilitate activate.
- Identitatea consumatorului implementată și testată.
- DLQ/parcare și alerte sunt configurate pentru a publica/consuma erori.
- Proiecțiile sunt recreate din jurnal (reluare) cu un timp acceptabil.
- Acces limitat la PII; sarcina utilă minimă e în kernel.
- SLA-urile prin lag-uri/livrare sunt măsurate și vizibile pe tablouri de bord.
- Există un plan pentru migrarea versiunilor de evenimente și deprecierea ferestrelor.
ÎNTREBĂRI FRECVENTE
Cu ce este EDC diferit de „doar un autobuz”?
Nucleul nu este doar brokerul, ci și contractul de eveniment, regulile de ordine/idempotență, procesele de evoluție și observabilitatea.
Putem construi doar pe CDC?
CDC este potrivit pentru integrări/migrații, dar evenimentele de domeniu exprimă mai clar sensul și experiența schimbărilor de baze de date mai stabile.
Cum rămâne cu consecvenţa?
Acceptăm eventuala coerență și design UX/procese pentru aceasta (indicatori de actualizare, retray, compensare).
Când este nevoie de mai exact o dată?
Rare: atunci când dublarea este strict inacceptabilă și imposibil de compensat. Mai des, cel puțin o dată + idempotența este suficientă.
Total
Kernel-ul Event-Driven transformă fluxul de fapte de afaceri într-o bază de încredere pentru sistem. Contractele de evenimente clare, disciplina de livrare și observabilitatea generează scalabilitate, reziliență și rata de evoluție - fără conexiunile sincrone fragile și „furtuna” regresiilor în schimbare.