Event-Driven өзегі

Event-Driven өзегі дегеніміз не?

Event-Driven ядро (EDC) - бұл бизнес-фактілер өзгермейтін оқиға ретінде тіркелетін және таратылатын, ал қалған функционалдылық (оқу, интеграция, талдау, кэш, нотификация) осы оқиғалар ағынының үстінен құрылатын архитектураның «омыртқасы». Ядро әлсіз байланыстылықты және масштабталуды қамтамасыз ете отырып, оқиғалар келісімшартын, жеткізу қағидаларын және тәртіп/теңсіздік инварианттарын белгілейді.

Негізгі идея: алдымен фактіні (ядро) жазу, содан кейін оны тәуелсіз түрде байыту және қажетті модельдерге енгізу. Бұл байланыстылықты азайтады және ішінара іркілістерге төзімділікті арттырады.

EDC мақсаттары мен қасиеттері

Фактілердің шындығы: әрбір оқиға - «не болды» деген өзгеріссіз жазба.
Әлсіз байланыс: продюсерлер тұтынушыларды білмейді; жүйені кеңейту - жазылушыларды қосу.
Масштабтау: партиялар/топиктер бойынша көлденең өсу, тәуелсіз тұтынушылар.
Бақылау және аудит: толассыз сәйкестендіргіштер, қайталанушылық, ретенция және қайталану.
Басқарылатын эволюция: схемалар нұсқалары, үйлесімділік, deprecation.

Сәулет компоненттері

1. Шина/оқиғалар брокері: Kafka/NATS/Pulsar/SNS + SQS - арналар, партиялар, ретенциялар.
2. Схемалар тізілімі: JSON Schema/Euro/Protobuf үйлесімділік пен эволюция үшін.
3. Outbox/CDC-контур: фактіні атомарлық бекіту + «қос жазбасыз» жариялау.
4. Проекциялар/оқу (CQRS): жылдам сұрау үшін материалданған көріністер.
5. Сағалар/оркестрлеу: оқиғалар/командалар арқылы ұзақ өмір сүру процестерін үйлестіру.
6. Байыту: сыни жолға әсер етпейтін жеке топиктер '.enriched '/' .derived'.
7. Обсервабилити: оқиғалар мен лагтар бойынша трассалау, логикалау, метрика.

Оқиға үлгісі

Оқиға түрлері

Domain Events: бизнес-фактілер ('payment. authorized`, `kyc. approved`).
Integration Events: сыртқы жүйелерге бағытталған (тұрақты, баяу өзгереді).
Change Data Capture (CDC): жазбаның техникалық өзгерістері (көші-қон/интеграция үшін пайдаланыңыз).
Audit/Telemetry: акторлардың әрекеттері, қауіпсіздік, SLA.

Міндетті атрибуттар (ядро)

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"
}

Ұсыныстар: 'event _ id' жаһандық бірегей, 'partition _ key' мәні үшін ретті орнатады, 'trace _ id' корреляцияны қамтамасыз етеді.

Жеткізу семантикасы және іспеттілігі

At-least-once (көптеген брокерлерде әдепкі): тұтынушылар іспеттес болуға міндетті.
At-most-once: екінші дәрежелі телеметриялар үшін ғана қолайлы.
Exactly-once: транзакциялар/демпотенттік кілттер/лейктер арқылы ағын және сақтау деңгейінде қол жеткізіледі (қымбат, жақсы себеп қажет).

Тұтынушының ұқсастық үлгісі

'event _ id '/' (event_id, consumer_id)' бойынша дедуп-кесте TTL ≥ топик ретенциясы.
insert орнына Upsert; 'sequence '/' occurred _ at' бойынша проекцияларды нұсқалау.
Транзакция аясындағы операциялар: «көрді» белгісі + күйінің өзгеруі.

Тәртіп және партияландыру

Партия шегінде кепілдендірілген тәртіп.
Бір агрегат мәніндегі барлық оқиғалар бір партияға түсетіндей етіп 'partition _ key' дегенді таңдаңыз ('user _ id', 'payment _ id').
«Ыстық кілттерден» аулақ болыңыз: жүктемені бөлу қажет болса, тұз/төменгі кілттері бар хеш.

Схемалар мен эволюция

Additive-first: жаңа опциондық өрістер, major-нұсқасыз түрлерді/семантиканы ауыстыруға тыйым салу.
Үйлесімділік: BACKWARD/FORWARD схемалар тізілімінде; CI сыйыспайтын өзгерістерді бұғаттайды.
Атауы: 'domain. action. v{major}` (`payment. authorized. v1`).
Көші-қон: 'v1' және 'v2' жұптарын параллель жариялаңыз, қос сәулеленуді қамтамасыз етіңіз (outbox арқылы dual-write), ауысқаннан кейін 'v1' дегенді түсіріңіз.

Outbox и CDC

Outbox (транзакциялық сервистер үшін ұсынылады)

1. Бір ДБ-транзакциясында: домендік жазба мен оқиғаны outbox ішінде сақтаймыз.
2. Фондық паблишер outbox оқиды, брокерге жариялайды, «жіберілді» деп белгілейді.
3. Кепілдіктер: құлаған кезде «жоғалту» фактісі жоқ, синхронизация жоқ.

CDC (Change Data Capture)

Қолданыстағы жүйелер/көші-қон үшін қолайлы; дереккөз - ДБ репликациясы.
Домендік оқиғаларды сүзгілеуді/қайта кодтауды талап етеді («шикі» кестелерді сырттан көрсетпеңіз).

CQRS және проекциялар

Командалар жай-күйін өзгертеді (көбінесе синхронды), оқиғалар - проекцияларды қалыптастырады (асинхронды).
Проекциялар сұрауларға (іздеу, тізімдер, есептер) есептелген, жазылушылар жаңартады.
Уақытша инхронизация - норма: тұрақты UX көрсетіңіз («деректер бірнеше секундтан кейін жаңартылады»).

Сағалар: процестерді үйлестіру

Оркестрлеу: бір үйлестіруші командалар жібереді және оқиғаларды күтеді.
Хореография: қатысушылар бір-бірінің оқиғаларына ден қояды (жеңілірек, бірақ келісімшарттарда тәртіпті талап етеді).
Ережелер: нақты өтемдер мен тайм-ауттар, қайталанатын қадамдар, демпотенттік өңдегіштер.

Бақылау

Trace/Span: 'trace _ id '/' span _ id' оқиғалар пайда болғанда тақырыптар арқылы лақтырыңыз.
Өлшемдер: тұтынушылар легі, жариялау/тұтыну жылдамдығы, dead-letter rate, дедупликация үлесі.
DLQ/parking lot: сәтсіз хабарламалар - алерті бар жеке топикке; қайта өңдеуді қамтамасыз етіңіз.

Қауіпсіздік және сәйкестік

Деректерді жіктеу: ядрода тек қажетті PII/финдандар минимумы (кері пирамида моделі), бөлшектер - байытуда болады.
Критикалық атрибуттардың қолы/хэштері, тұтастығын бақылау.
In-flight және at-rest шифрлау, (IAM/ACL) тақырыптары бойынша құқықтарды секциялау.
Ретенция саясаты және ұмыту құқығы: әрбір топик үшін нақты айқындалған.

Өнімділік және тұрақтылық

Backpressure: тұтынушыларда - бәсекелестікті шектеу, брокерде - квоталар/лимиттер.
Batch-өңдеу және компрессия: үстеме шығындарды азайту үшін жазбаларды топтаңыз.
Шексіз әрекеттердің орнына джиттермен және DLQ ретрайлері.
Rebalance-төзімділік: оффсеттерді транзакциялық/сыртқы сақтаңыз, салқын басталуды снапшоттармен жылдамдатыңыз.

Оқиғаның үлгі үлгілері

Төлемдердің өзегі

`payment. initiated. v1` → `payment. authorized. v1` → `payment. captured. v1` → `payment. settled. v1`

Қателер: 'payment. declined. v1`, `payment. refunded. v1`

Партиялануы: 'payment _ id'

SLA: ядро лаг ≤ 2с p95; тұтынушылардың біртұтастығы міндетті.

АКҚ/верификация

`kyc. started. v1` → `kyc. document. received. v1` → `kyc. approved. v1`/`kyc. rejected. v1`

PII - ең аз; құжаттың егжей-тегжейі - 'kyc. enriched. v1 'қатынауы шектеулі.

Аудит/қауіпсіздік

`audit. recorded. 'actor', 'subject', 'action', 'occurred _ at', 'trace _ id' төлсипаттарымен v1 '.
Үздіксіз ретенция/мұрағаттау; жоғары тұтастық (WORM-сақтау орны).

Антипаттерндер

Fat Event: қажетсіз артық жүктелген payload's, PII ағуы.
Оқиғалар арқылы Hidden RPC: «осында және қазір» синхронды жауаптарын күту.
Шикі CDC сыртқа: ДБ схемасымен тығыз байланыс.
Тұтынушыларда сәйкессіздік жоқ: екі жақты жанама әсерлерге әкеледі.
Барлығына ортақ бір топик: мүдделер қақтығысы, проблемалық тәртіп, күрделі эволюция.

EDC қадамдық енгізу

1. Доменнің картасын жасау: негізгі агрегаттар мен өмірлік циклдерді таңдаңыз.
2. Оқиғалар каталогы: атаулар, мағыналар, инварианттар, міндетті өрістер.
3. Сұлбалар мен тізілім: пішімді таңдаңыз, сыйысымдылық ережелерін қосыңыз.
4. Outbox/CDC: Әрбір продюсер үшін фактілерді жариялау механизмін анықтаңыз.
5. Партиялану: кілттерді таңдап, ыстық кілттерді/қайта бөлуді бағалаңыз.
6. Ұқсастық: дедуп үлгісі + тұтынушылардың транзакциялануы.
7. Проекциялар: материалданған модельдер мен SLA жаңартуларды анықтаңыз.
8. Обсервабилити: трассировка, лагтар, DLQ, алерталар.
9. Security/PII: деректерді жіктеу, шифрлау, ACL.
10. Эволюция бойынша гайд: көші-қон үшін нұсқа саясаты, депрекейт, dual-write.

Шығарылған чек парағы

Әрбір оқиғада 'event _ id', 'trace _ id', 'occurred _ at', 'partition _ key' бар.
Тізілімдегі схемалар, үйлесімділік тексерулері енгізілген.
Тұтынушылардың сәйкестігі іске асырылды және сыналды.
DLQ/parking lot және жариялау/тұтыну қателеріне тәуекелдер теңшелген.
Проекциялар логтан (replay) қолайлы уақытпен қайта тасымалданады.
PII қатынау шектелген; ядродағы ең аз payload '.
Лагтар/жеткізу бойынша SLA өлшенеді және дашбордтарда көрінеді.
Оқиғалар мен терезелердің көшіру жоспары бар.

FAQ

EDC «жай шинадан» немен ерекшеленеді?
Ядро - бұл тек брокер ғана емес, сонымен қатар оқиғалардың келісімшарты, тәртіп/демпотенттілік ережелері, эволюция процестері және бақылау.

Тек CDC құрылысын салуға бола ма?
CDC интеграция/көші-қон үшін жарамды, бірақ домендік оқиғалар мағынасын анық білдіреді және ДБ өзгерістерін тұрақты түрде бастан өткізеді.

Келісумен не істеу керек?
eventual consistency қабылдаймыз және UX/процестерді жобалаймыз (жаңарту индикаторлары, ретрациялар, өтемақылар).

exactly-once қашан қажет?
Сирек: екі есе көбейтуге жол берілмейді және орнын толтыру мүмкін емес. Көбінесе at-least-once + іспеттілік жеткілікті.

Жиынтығы

Event-Driven өзегі бизнес-фактілер ағынын жүйенің сенімді іргетасына айналдырады. Оқиғалардың нақты келісімшарттары, жеткізу тәртібі мен байқалушылық ауқымдылықты, тұрақтылықты және эволюция жылдамдығын береді - өзгерістер кезіндегі осал синхронды байланыстарсыз және регрессия «дауылынсыз».

Event-Driven өзегі