Hadisə arxitekturası
Hadisə arxitekturası (EDA)
1) Hadisə nədir və niyə EDA
Hadisə - artıq domendə («PlayerVerified», «PaymentCaptured») baş vermiş dəyişməz faktdır. EDA bu faktların və onlara reaksiyaların dərc ətrafında inteqrasiya qurur:- xidmətlərin zəif əlaqəsi,
- müstəqil istehlakçı miqyası,
- replay/proyeksiyaların yenidən qurulması,
- şəffaf audit.
EDA sinxron API-ləri ləğv etmir - asenxron təbəqəyə xaç xidməti asılılıqlarını çıxararaq onları tamamlayır.
2) Hadisə növləri
Domen: əhəmiyyətli biznes faktları (OrderPlaced, BonusGranted).
İnteqrasiya: xarici sistemlər üçün «şəkillər «/dəyişikliklər (UserUpdated, WalletBalanceChanged).
Texniki: həyat dövrü və telemetriya (Heartbeat, PipelineFailed).
Əmrlər (hadisə deyil, yaxınlıqda): «X» (CapturePayment) təlimatları.
Tövsiyə: domen hadisələri - ilkin; inteqrasiya xüsusi istehlakçılar üçün proyeksiyalar tərəfindən formalaşır.
3) Hadisə müqavilələri və sxemlər
Схема: Avro/Protobuf/JSON Schema + Schema Registry; Uyğunluq strategiyası: «BACKWARD» istehlakçıların təkamülü üçün, «FULL» kritik mövzularda.
CloudEvents (id, source, type, time, subject, datacontenttype) - vahid başlıqlar.
Məcburi meta məlumat: 'event _ id' (ULID/UUID), 'occurred _ at', 'producer', 'schema _ version', 'correlation _ id '/' causation _ id', 'idempotency _ key'.
Version: add-only sahələr, ad/semantik qırılma qadağan; yeni tiplər - yeni mövzular/tiplər.
json
{
"type":"record","name":"PaymentCaptured","namespace":"events.v1",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"payment_id","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":"string"},
{"name":"player_id","type":"string"}
]
}
4) Çatdırılma, sifariş və uyğunluq
At-least-once bir defolt kimi → prosessorların idempotentliyi lazımdır.
Sifariş: Partiya (Kafka) və ya növbə (RabbitMQ) daxilində zəmanət verilir, lakin retralar zamanı pozula bilər; hadisə açarı domen qranulunu (məsələn, 'player _ id') əks etdirməlidir.
Uyğunluq: pul/kreditlər üçün - yalnız jurnallar/dastanlar/kompensasiyalar vasitəsilə; LWW-dən çəkinin.
Oxu modeli: proyeksiyalar və caches eventual ola bilər - «yeniləmə gedir»... göstərin və ciddi yollar üçün RNOT strategiyalarından istifadə edin.
5) Outbox/Inbox и CDC
Outbox: Xidmət onun DB faktını yazır və bir əməliyyatda outbox cədvəlində → vorker şində dərc edir.
Inbox: İstehlakçı «event _ id» dedup üçün emal nəticəsi ilə saxlayır.
CDC (Change Data Capture): Tətbiq dəyişikliyi olmadan inteqrasiyalar qurmaq üçün DB-dən (binlog/WAL) şinə dəyişiklik axını.
Idempotency: 'idempotency _ key '/' event _ id' emalı, fiksasiya qədər xarici dünyanı dəyişməyin.
6) CQRS и Event Sourcing
CQRS: write modeli və read-proyeksiyaları paylaşın; proyeksiyalar hadisələrdən ibarətdir və geridə qala bilər.
Event Sourcing: aqreqatın vəziyyəti = onun hadisələrinin yığılması. Üstünlüklər: tam audit/replay; mənfi cəhətləri: miqrasiyaların/sxemlərin/snapshotların mürəkkəbliyi.
Təcrübə: ES - hər yerdə deyil, tarix və kompensasiyanın vacib olduğu yerlərdə; CQRS - demək olar ki, həmişə EDA.
7) Dastanlar: orkestr və xoreoqrafiya
Orkestr: koordinator komandalar göndərir və cavab tədbirlərini gözləyir; mürəkkəb proseslər üçün əlverişlidir (KYC → Deposit → Bonus).
Xoreoqrafiya: xidmətlər bir-birinin hadisələrinə reaksiya verir; asan, lakin izləmək daha çətindir.
Həmişə kompensasiya və addımların müddəti müəyyən edin.
8) Topologiyaların layihələndirilməsi (Kafka/RabbitMQ)
Kafka
Top per domen hadisəsi: 'payments. captured. v1`, `players. verified. v1`.
Partizan açarı: 'player _ id '/' wallet _ id' - sifarişin vacib olduğu yerdə.
`replication. factor=3`, `min. insync. replicas = 2 ', prodüser' acks = all '.
Retention: vaxt (məsələn, 7-90 gün) və/və ya compaction (açar üzrə son vəziyyət).
backoff ilə retry və DLQ üçün topics.
RabbitMQ
Exchanges: `topic`/`direct`, routing key `payments. captured. v1`.
Geniş fan-out üçün - 'topic' + bir neçə sıra; RPC/komandalar üçün - ayrı-ayrı növbələr.
HA üçün Quorum Queues; TTL + retrains üçün dead-letter exchange.
9) Müşahidə və SLO EDA
SLI/SLO:- End-to-end latency (occurred_at → emal): p50/p95/p99.
- Lag/age: istehlakçı geriliyi (Kafka consumer lag, Rabbit backlog age).
- Throughput nəşr/emal.
- DLQ-rate və təkrar payı.
- Biznes əməliyyatlarının uğuru (məsələn, «depozit 5s ≤ təsdiq edilmişdir»).
- 'trace _ id '/' correlation _ id' (OTel) vasitəsilə hadisələrin korrelyasiyası.
- Metrik → trek nümunələri (exemplars).
- Dashboard «Producer → Broker → Consumer» ilə burn-rate alerts.
10) Replay, retenshn və backfill
Proyeksiyaların yenidən qurulması/nasazlıqların düzəldilməsi üçün replay: Yeni proyeksiyaya/neyspace sürün, sonra oxunuşu dəyişdirin.
Retenshn: hüquqi/biznes tələbləri (GDPR/PCI); həssas sahələr - şifrələyin və/və ya tokenləşdirin.
Backfill: birdəfəlik mövzular/növbələr, aydın RPS limitləri, məhsulu boğmamaq üçün.
11) Təhlükəsizlik və uyğunluq
TLS in-tranzit, mTLS daxili müştərilər üçün.
Avtorizasiya: per-topic/per-exchange ACL; namespace/vhost vasitəsilə multitenancy.
PII: hadisədə sahələri minimuma endirmək; envelope metadata ayrıca, faydalı yük lazım olduqda şifrələmək.
Hadisələrə giriş auditi, «hər şeyə qadağa» açarları.
Retenshn siyasəti və silmə hüququ (GDPR): ya məlumat bağlantıları saxlayın, ya da tombstone hadisələri və projeksiyalarda silmə.
12) EDA-da test
Contract tests: istehlakçılar sxemlərin gözləntilərini (consumer-driven) təsdiqləyirlər.
Replay Tests: yeni prosessor/sxem versiyası vasitəsilə tarixi nümunə qaçış.
Chaos ssenariləri: broker gecikməsi/itkisi, düyünlərin düşməsi, istehlakçı gecikməsi → SLO çərçivəsində qalır.
CI-də Smoke: müvəqqəti mövzularda qısa son-end paypline.
13) Miqrasiya «CRUD-inteqrasiya → EDA»
1. Domen faktlarını müəyyən edin.
2. Outbox-u ilkin xidmətlərə daxil edin.
3. Minimum domen hadisələrini dərc edin və 1-2 proyeksiyanı birləşdirin.
4. Sinxron inteqrasiyaları abunələrlə əvəz edərək tədricən söndürün.
5. Schema Registry və uyğunluq siyasətini daxil edin.
6. Hadisələri add-only sahələrlə genişləndirin; sındırma - yalnız yeni növləri vasitəsilə.
14) Anti-nümunələr
Hadisələr = «DTO API» (çox yağlı, daxili modeldən asılıdır) - istehlakçıları pozur.
Schema Registry və uyğunluq olmaması - «kövrək» inteqrasiya.
Koddan nəşr və DB-yə yazmaq atomar deyil (no outbox) - hadisələri itirin.
«Hər yerdə Exactly-once» - faydasız yüksək qiymət; daha yaxşı at-least-once + idempotentlik.
Bir «universal» partizan açarı → isti partizan.
Düz proyeksiyaya replay - onlayn SLO-ları sındırır.
15) Giriş çek siyahısı (0-45 gün)
0-10 gün
Domen hadisələrini və onların açarlarını (sifariş qranulları) müəyyən edin.
Schema Registry-ni genişləndirin və uyğunluq strategiyasını təsdiq edin.
1-2 xidmət outbox/inbox əlavə edin; minimum CloudEvents-envelope.
11-25 gün
retry/DLQ, backoff, empotent prosessorları daxil edin.
Daşbordlar: lag/age/end-to-end; burn-rate alert.
Hadisələrin sənədləşdirilməsi (kataloq), owner's və sxemlərin review prosesləri.
26-45 gün
Birinci proyeksiyanın replay/yenidən qurulması; runbook replay və backfill.
Təhlükəsizlik siyasəti (TLS, ACL, PII), retenshn, GDPR prosedurları.
Broker və istehlakçılar üçün müntəzəm chaos və game-days.
16) Yetkinlik metrikası
100% domen hadisələri sxemlərlə təsvir olunur və qeydiyyata alınır.
Outbox/inbox bütün prodüserlər/ Tier-0/1.
SLO: p95 end-to-end latency və 99% ≥ hədəfləri daxilində consumer lag.
Replay/Backfill downtime olmadan həyata keçirilir; yoxlanılmış runbook var.
Version: yeni sahələr - qırılmadan; köhnə istehlakçılar düşmür.
Təhlükəsizlik: TLS + mTLS, ACL per topic, giriş jurnalları, PII/retenshn siyasəti.
17) Mini snippet
Kafka Producer (etibarlı nəşr, fikirlər):properties acks=all enable.idempotence=true max.in.flight.requests.per.connection=1 compression.type=zstd linger.ms=5
Consumer prosessor (idempotentlik, psevdokod):
python if inbox.contains(event_id): return # дедуп process(event) # побочные эффекты детерминированы inbox.commit(event_id) # atomically with side-effect commit_offset()
DLX (ideya) vasitəsilə RabbitMQ Retry:
- `queue: tasks` → on nack → DLX `tasks. retry. 1m '(TTL = 60s) → qaytarılması' tasks '; sonra '5m/15m'.
18) Nəticə
EDA inteqrasiyanı dəqiq müqavilələr və idarə olunan uyğunluq ilə biznes faktlarının axınına çevirir. Təməl qurun: sxemlər + reyestr, outbox/inbox, sifariş açarları, idempotent prosessorları, SLO və müşahidə, təhlükəsiz retenshn və replay. Sonra hadisələr miqyaslı, analitik və yeni sahələr üçün «həqiqət mənbəyi» olacaq - kövrək əlaqələr və gecə miqrasiyaları olmadan.