Իրադարձական ճարտարապետություն

Իրադարձական ճարտարապետություն (EDA)

1) Ի՞ նչ է իրադարձությունը և ինչու է EDA-ն։

Իրադարձությունը անփոփոխ փաստ է, որն արդեն տեղի է ունեցել օրինագծում («PlayerVerified», «Payts Captured»)։ EDA-ն կառուցում է տվյալներ այս փաստերի հրապարակման և դրանց վրա արձագանքների շուրջ

ծառայությունների թույլ կապը,

սպառողների մասշտաբը անկախ է,

repley/պրոյեկտների վերակառուցում,

թափանցիկ աուդիտ։

EDA-ն չի վերացնում սինխրոն API-ը, այն ավելացնում է դրանք 'խաչաձև ծառայության կախվածությունը ասինխրոն շերտին։

2) Իրադարձությունների տեսակները

Հիբրիդային 'կարևոր բիզնես փաստերը (Orance Placed, BonusGranted)։

Ինտեգրացիոն '«նկարներ «/փոփոխություններ արտաքին համակարգերի համար (UserPortated, WalletBalts Changed)։

Տեխնիկական 'կյանքի ցիկլը և հեռուստատեսությունը (Heartbeat, PipelineFailed)։

Թիմերը (ոչ թե իրադարձություններ, այլ մոտակայքում) '«դարձրեք X» հրահանգները։

Առաջարկություն ՝ հիբրիդային իրադարձությունները առաջնային են։ ինտեգրացիոն ձևավորվում են հատուկ սպառողների պրոյեկտներ։

3) Իրադարձությունների և սխեմաների պայմանագրերը

Схема: Avro/Protobuf/JSON Schema + Schema Registry; ռազմավարություն '«BACKWARD» սպառողների էվոլյուցիայի համար, «FOX» կրիտիկական թեմաների վրա։

CloudEvents (id, source, type, time, wwww.acontentttype) - միանձնյա վերնագրեր։

Պարտադիր մետատվյալներ ՝ «event _ id» (ULID/UUID), «occcurred _ at», «schema _ version», «www.relation _ id »/« causation _ id», «idempotency _ key»։

Տարբերակումը 'add-only դաշտեր, փոխակերպման արգելք/սեմանտիկ կոտրվածքներ; նոր տեսակներ 'նոր թեմաներ/տեսակներ։

Օրինակ (Avro, հատված)

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) Առաքում, կարգուկանոն և ներդաշնակություն

At-leport-once-ը, որպես դեֆոլտ, անհրաժեշտ է վերամշակողների գաղափարախոսություն։

Կարգը 'երաշխավորված է կուսակցության ներսում (Kafka) կամ հերթերը (RabbitMQ), բայց կարող է խախտվել գետերի ժամանակ։ իրադարձության բանալին պետք է արտացոլի կարգադրության կանոնավոր գրանուլան (օրինակ ՝ «player _ id»)։

Համաձայնություն 'փողի/վարկերի համար միայն ամսագրերի/սագայի/փոխհատուցման միջոցով։ խուսափեք LWW-ից։

Կարդալու մոդելը 'պրոյեկտներն ու քեշները կարող են լինել eventium, ցույց տվեք «նորարարություն»... և օգտագործեք RNOT ռազմավարությունը խիստ ճանապարհների համար։

5) Outbox/Inbox и CDC

Windobox: Ծառայությունը գրում է փաստը իր BD-ում և մեկ գործարքի ժամանակ www.worker-ը հրապարակում է անվադողեր։

Inbox: սպառողը պահպանում է «event _ id» 'դեդուպի վերամշակման արդյունքում։

CDC (Change You Capture) 'BD (binlog/WAL) փոփոխությունների հոսքը անվադողերի մեջ' ինտեգրումներ կառուցելու համար առանց կիրառման փոփոխության։

Idempotency-ը '«idempotency _ key »/« event _ id» -ի վերամշակումը, չի փոխի արտաքին աշխարհը մինչև ամրագրումը։

6) CQRS и Event Sourcing

CQRS 'մենք կիսում ենք write մոդելը և read-պրոյեկտները։ նախագծերը կառուցվում են իրադարձություններից և կարող են հետ կանգնել։

Event Sourcing: ագրեգատի վիճակը = նրա իրադարձությունների շրջանակը։ Պլյուսներ 'ամբողջական աուդիտ/repley; մինուս 'ներարկման/սխեմաների/սարքավորումների բարդություն։

Պրակտիկա 'ES-ը ամենուր չէ, այլ այնտեղ, որտեղ կարևոր է պատմությունը և փոխհատուցումը։ CQRS-ը գրեթե միշտ EDA-ում է։

7) Սագի 'նվագախումբ և խորեոգրաֆիա

Orcestration: 108 ուղարկում է թիմերին և սպասում է պատասխանների իրադարձություններին։ հարմար է բարդ գործընթացների համար (KYC no Deposit no Bonus)։

Խորեոգրաֆիա 'ծառայությունները արձագանքում են միմյանց իրադարձություններին։ ավելի հեշտ է, բայց ավելի դժվար է գտնել։

Միշտ որոշեք փոխհատուցումը և քայլերը։

8) Տեղաբանության նախագծումը (Kafka/RabbitMQ)

Kafka

Կուսակցության բանալին '«player _ id »/« wallet _ id», որտեղ կարևոր է կարգը։

Per per-ի տիրույթի իրադարձությունը '"payments. captured. v1`, `players. verified. v1`.

`replication. factor=3`, `min. insync. replicas = 2 «, վաճառող 'acks = all»։

Retention: Ժամանակի ընթացքում (օրինակ 7-90 օր) և/կամ compaction (վերջին վիճակը)։

Retry-ի և DLQ-ի համար backoff-ի հետ։

RabbitMQ

Լայն ֆան-աուտայի համար '«topic» + մի քանի հերթեր; RPC/թիմերի համար անհատական գծեր են։

Exchanges: `topic`/`direct`, routing key `payments. captured. v1`.

Corrum Queues-ը HA-ի համար։ TTL + dead-letter-ը պատրաստված է գետերի համար։

9) Դիտարկումը և SLO EDA-ն

• End-to-end latency (occurred _ at): p50/p95/p99։
• Lag/age 'սպառողների հրաժարումը (Kafka consumer lag, Rabbit backlog age)։
• Throughput հրատարակություններ/վերամշակումներ։
• DLQ-rate-ը և խոհարարների մասը։
• Բիզնեսի վիրահատությունների հաջողությունը (օրինակ, «դեպոզիտը ապացուցված է 355c»)։

Պրակտիկա

Իրադարձությունների հարաբերակցությունը «trace _ id »/« edrelation _ id» (OTel) միջոցով։

Դիագրամները (exemplars) ռուսական մայրուղուց։

Dashbords «Winder no Broker no Consumer» -ը burn-rate ալերտերով։

10) Repley, retenshn և backfill

Պրոյեկցիաների վերակազմավորման/ուղիների ուղղման համար, անցեք նոր պրոյեկցիա/նյարդային սպեյս, ապա փոխեք ընթերցանությունը։

Retenshn: իրավաբանական/բիզնես պահանջներ (GDPR/PCI); զգայուն դաշտերը ծածկագրեք և/կամ թունավորեք։

Backfill: Միանգամյա թեմաներ/հերթեր, RPS-ի հստակ սահմանաչափեր, որպեսզի չփորձեն։

11) Անվտանգությունն ու կոմպլենսը

TMS-transit, mTSA ներքին հաճախորդների համար։

Հեղինակային իրավունքը 'per-topic/per-international ACL; multitenancy namespace/vhost միջոցով։

PII 'նվազեցնել դաշտերը իրադարձության մեջ։ envelope մեթադները առանձին են, օգտակար բեռները կոդավորելու անհրաժեշտության դեպքում։

Իրադարձությունների հասանելիության աուդիտը, «բոլոր հզոր» արգելքը։

Քաղաքական գործիչները և հեռացման իրավունքը (GDPR), կամ պահպանեք հղումները տվյալների վրա, կամ tombstone իրադարձությունները և հեռացումը նախագծերում։

12) Փորձարկումը EDA-ում

Euract tes.ru: սպառողները առաջնորդում են իրենց սխեմաների սպասումները (consumer-driven)։

Replay-թեստեր 'պատմական նմուշի պրոգոն նոր վերամշակողի/սխեմայի տարբերակի միջոցով։

Chaos-սցենարներ 'բրոքերի ուշացում/կորուստ, հանգույցների նվազում, SLO շարժիչների սպառողի հրաժարվելը մնում է շրջանակներում։

Smoke-ում, կարճ end-to-end-pline-ում։

13) «CRUD ինտեգրացիաների ինտեգրումը EDA»

1. Նույնականացրեք հիբրիդային փաստերը։

2. Ներդրեք www.box-ը սկզբնական ծառայություններում։

3. Հրապարակեք նվազագույն հիբրիդային իրադարձությունները և միացրեք 1-2 պրոյեկտները։

4. Աստիճանաբար անջատեք կետային սինխրոն բջիջները ՝ դրանք փոխարինելով բաժանորդագրություններով։

5. Մուտքագրեք Schema Registry-ը և ինտեգրման քաղաքականությունը։

6. Ընդարձակեք add-only դաշտերի իրադարձությունները։ կոտրվածքները միայն նոր տեսակների միջոցով են։

14) Anti-patterna

Իրադարձությունները = «DTO API» (չափազանց ճարպոտ, կախված են ներքին մոդելից) կոտրում են սպառողներին։

Schema Registry-ի և ոճի բացակայությունը «փխրուն» է։

Կոդի հրապարակումը և BD-ում ձայնագրումը ատոմային չեն (ոչ www.box) - կորցնում են իրադարձությունները։

«Exactly-once» -ը ամենուր բարձր գինն է առանց օգուտների։ ավելի լավ է at-least-once + idempotent։

Մեկ «համընդհանուր» կուսակցության բանալին հաստատվում է տաք կուսակցության կողմից։

Repley-ը հենց պրոդ-պրոյեկցիայի մեջ է, կոտրում է առցանց SLO-ն։

15) Ներդրման թուղթ (0-45 օր)

0-10 օր

Որոշեք հիբրիդային իրադարձությունները և նրանց բանալիները (կարգուկանոնի նռնակներ)։

Տեղակայել Schema Registry-ը և հաստատել մրցույթի ռազմավարությունը։

Ավելացնել www.box/inbox 1-2-ում; Նվազագույն CloudEvents-envelope-ը։

11-25 օր

Ներդրել retry/DLQ, backoff, բուժողների գաղափարախոսություն։

Dashbords: lag/age/end-to-end; burn-rate alerta։

Իրադարձությունների իրականացումը (կատալոգը), owner 's-ը և սխեմաների հոսքի գործընթացները։

26-45 օր

Անվտանգության քաղաքականությունը (TFC, ACL, PII), rentenshn, GDPR ընթացակարգերը։

Repley/առաջին պրոյեկցիայի վերակառուցում; runbook repley և backfill.

Winchaos-ը և game-days-ը բրոքերի և սպառողների համար։

16) Հասունության մետրերը

Երկրորդային իրադարձությունների 100 տոկոսը նկարագրված է սխեմաներով և գրանցվել։

Windobox/inbox-ը ծածկում է Tier-0/1 բոլոր վաճառողները։

SLO: p95 end-to-end latency և consumer lag նպատակներով 3699%։

Repley/Backfill-ը կատարվում է առանց dountaima; կան ստուգված runbook 't

Տարբերակումը 'նոր դաշտեր' առանց կոտրվածքների։ հին սպառողները չեն ընկնում։

Անվտանգություն ՝ TMS + mTSA, ACL per topic, հասանելիության ամսագրեր, PII/retenshn քաղաքականություն։

17) Մինի-նիպետներ

Kafka Syster (հուսալի հրատարակություն, գաղափարներ)

properties acks=all enable.idempotence=true max.in.flight.requests.per.connection=1 compression.type=zstd linger.ms=5

Consumer-վերամշակող (idempotention, կեղծ)

python if inbox.contains(event_id): return # дедуп process(event)            # побочные эффекты детерминированы inbox.commit(event_id)        # atomically with side-effect commit_offset()

RabbitMQ Retry-ը DLX-ի միջոցով (գաղափարը)

`queue: tasks` → on nack → DLX `tasks. retry. 1m "(TTL = 60s) արտադրվում է" tasks "-ում։ հաջորդը '5m/15m "։

18) Եզրակացություն

EDA-ն վերածում է բիզնեսի փաստերի հոսքը հստակ պայմանագրերով և կառավարվող համաձայնությամբ։ Դուք կառուցում եք հիմքը '+ 105, www.box/inbox, կարգի բանալիներ, կուռքեր, SLO և դիտողություններ, անվտանգ ռետենշեն և ռելե։ Այդ ժամանակ իրադարձությունները կդառնան ձեր «ճշմարտության աղբյուրը» մասշտաբի, վերլուծաբանների և նոր ֆիչի համար 'առանց փխրուն կապերի և գիշերային միգրացիաների։