Окуя архитектурасы

Окуя архитектурасы (EDA)

1) Эмне окуя жана эмне үчүн EDA

Окуя - буга чейин доменде болгон өзгөрүлбөс факт ("PlayerVerified", "PaymentCaptured"). EDA бул фактыларды жана аларга болгон реакцияларды жарыялоонун айланасында интеграцияны курат:

кызматтардын алсыз байланышы,
керектөөчүлөрдү өз алдынча масштабдоо,
реплика/проекцияларды кайра куруу,
ачык-айкын аудит.

EDA синхрондуу API жокко чыгарбайт - бул аларды асинхрондук катмарга кросс-сервистик көз карандылыктарды алып салуу менен толуктайт.

2) Окуялардын түрлөрү

домен: маанилүү бизнес-фактылар (OrderPlaced, BonusGranted).
Интеграциялык: тышкы системалар үчүн "сүрөттөр "/өзгөртүүлөр (UserUpdated, WalletBalanceChanged).
Техникалык: жашоо жана телеметрия (Heartbeat, PipelineFailed).
Командалар (окуя эмес, бирок жакын жерде): "X жасоо" (CapturePayment) көрсөтмөлөрү.

Сунуш: домендик окуялар - баштапкы; конкреттүү керектөөчүлөр үчүн проекциялар менен түзүлөт.

3) Иш-чаралардын келишимдери жана схемалары

Схема: Avro/Protobuf/JSON Schema + Schema Registry; шайкештик стратегиясы: 'BACKWARD' керектөөчүлөрдүн эволюциясы үчүн, 'FULL' критикалык темаларда.
CloudEvents (id, source, type, time, subject, datacontenttype) - бир тектүү аталыштар.
Милдеттүү метадеректер: 'event _ id' (ULID/UUID), 'occurred _ at', 'producer', 'schema _ version', 'correlation _ id '/' causation _ id', 'idempotency _ key'.
Версиялоо: add-only талаалар, атын өзгөртүүгө/семантикалык бузууга тыюу салуу; жаңы түрлөрү - жаңы темалар/түрлөрү.

Мисал (Евро, фрагмент):

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-least-once → иштеткичтердин демпотенттиги керек.
Тартиби: партиянын ичинде кепилденген (Kafka) же кезек (RabbitMQ), бирок ретра учурунда бузулушу мүмкүн; окуянын ачкычы ордендин домендик грануласын чагылдырышы керек (мисалы, 'player _ id').
Шайкештик: акча/кредиттер үчүн - журналдар/сагалар/компенсациялар аркылуу гана; LWW алыс.

Окуу модели: проекциялар жана кэштер eventual болушу мүмкүн - "жаңылануу жүрүп жатат"... жана катуу жолдор үчүн RNOT стратегияларын колдонуңуз.

5) Outbox/Inbox и CDC

Outbox: кызмат бир бүтүм менен анын DD жана outbox таблицасында чындыкты жазат → воркер шинага жарыялайт.
Inbox: керектөөчү сактайт 'event _ id' үчүн кайра иштетүү натыйжасы.
CDC (Change Data Capture): DDдан (binlog/WAL) тиркемесин өзгөртпөстөн интеграцияны куруу үчүн шинага өзгөртүү агымы.
Idempotency: 'idempotency _ key '/' event _ id' иштетүү, бекитүү чейин тышкы дүйнөнү өзгөртүүгө болбойт.

6) CQRS и Event Sourcing

CQRS: write моделин жана окуу проекцияларын бөлүшүү; проекциялар окуялардан турат жана артта калышы мүмкүн.
Event Sourcing: Агрегаттын абалы = анын окуяларынын жыйындысы. Артыкчылыктары: толук аудит/реплика; минустары: миграциянын/схемалардын/снапшоттун татаалдыгы.
Практика: ES - бардык жерде эмес, тарых жана компенсация маанилүү болгон жерде; CQRS - дээрлик дайыма EDA.

7) Сагалар: оркестр жана хореография

Оркестр: координатору буйрук жиберет жана иш-жооп күтүп; татаал процесстер үчүн ыңгайлуу (KYC → Deposit → Bonus).
Хореография: кызматтар бири-биринин окуяларына жооп берет; байкоо жүргүзүү оңой, бирок кыйыныраак.
Ар дайым компенсацияларды жана чектүү кадамдарды аныктаңыз.

8) Топологияларды долбоорлоо (Kafka/RabbitMQ)

Kafka

Top per домен окуясы: 'payments. captured. v1`, `players. verified. v1`.
Партиялаштыруу ачкычы: 'player _ id '/' wallet _ id' - тартип маанилүү болгон жерде.
`replication. factor=3`, `min. insync. replicas = 2 ', продюсер' acks = all '.
Retention: убакыттын өтүшү менен (мисалы, 7-90 күн) жана/же compaction (ачкычтын акыркы абалы).
backoff менен retry жана DLQ үчүн топиктер.

RabbitMQ

Exchanges: `topic`/`direct`, routing key `payments. captured. v1`.
Кеңири күйөрман үчүн - 'topic' + бир нече кезек; RPC/командалар үчүн - өзүнчө кезек.
HA үчүн Quorum Queues; TTL + retrains үчүн dead-letter алмашуу.

9) Байкоо жана SLO EDA

SLI/SLO:

End-to-end latency (occurred_at → иштетилген): p50/p95/p99.
Lag/age: керектөөчүлөрдүн артта калуусу (Kafka consumer lag, Rabbit backlog age).
Throughput жарыялоо/иштетүү.
DLQ-rate жана кайталоо үлүшү.
Бизнес-операциялардын ийгилиги (мисалы, "депозит 5с ≤ тастыкталган").

Практикалар:

'trace _ id '/' correlation _ id' (OTel) аркылуу окуяларды корреляциялоо.
Нускалар (exemplars) метрика → трасса.
Dashboard "Producer → Broker → Consumer" burn-rate alerts менен.

10) Replay, retenshn жана backfill

Проекцияларды кайра куруу/мүчүлүштүктөрдү оңдоо үчүн реплика: жаңы проекцияга/неймспейске айдап, анан окууну которуңуз.
Retenshn: юридикалык/бизнес талаптар (GDPR/PCI); сезгич талаалар - шифрлөө жана/же токенизациялоо.
Backfill: бир жолу колдонулуучу темалар/кезектер, RPS так чектери өнүмдөрдү муунтуп жок.

11) Коопсуздук жана комплаенс

TLS in-transit, mTLS ички кардарлар үчүн.
Authorization: per-topic/per-exchange ACL; namespace/vhost аркылуу multitenancy.
PII: окуяда талааларды азайтуу; envelope өзүнчө метадеректер, зарыл болсо, пайдалуу жүктөрдү шифрлөө.
Иш-чараларга жетүү аудити, "бардык жөндөмдүү" ачкычтарга тыюу салуу.
Retenshn саясаты жана алып салуу укугу (GDPR): же маалымат шилтемелерди сактоо, же tombstone-окуялар жана проекцияларда алып салуу.

12) EDA сыноо

Contract tests: керектөөчүлөр схемаларды күтүүлөрүн тастыктайт (керектөөчү-айдоочу).
Replay-тесттер: жаңы иштеп чыгуучу/схемасы чыгаруу аркылуу тарыхый үлгү айдап.
Chaos-жагдайлар: брокердин кечигүү/жоготуу, түйүндөрдүн кулашы, керектөөчү артта → SLO алкагында кала берет.
CI жылы Smoke: кыска-end-to-end убакыт темалар боюнча колдонмо.

13) Миграция "CRUD-интеграция → EDA"

1. Домендик фактыларды аныктаңыз.
2. баштапкы кызмат outbox киргизүү.
3. Минималдуу домен окуяларын жарыялап, 1-2 проекцияларды туташтырыңыз.
4. Бара-бара аларды жазылуу менен алмаштыруу, пункту синхрондуу бириктирүү өчүрүү.
5. Схеманы жана шайкештик саясатын киргизиңиз.
6. окуяларды add-only талаалар менен кеңейтүү; сыныктар - жаңы түрлөрү аркылуу гана.

14) Анти-үлгүлөрү

Окуялар = "DTO API" (өтө майлуу, ички моделине көз каранды) - керектөөчүлөрдү сындырат.
Жок Schema каттоо жана шайкештиги - "алсыз" бириктирүү.
Коддон жарыялоо жана DDге жазуу атомардык эмес (жок outbox) - окуяларды жоготот.
"Exactly-once бардык жерде" - пайдасы жок жогорку баа; жакшыраак at-least-once + боштук.
Бир "универсалдуу" партиялаштыруу ачкычы → ысык партия.
Прод-проекцияга түздөн-түз реплика - онлайн SLOларды бузат.

15) киргизүү чек-тизмеси (0-45 күн)

0-10 күн

Домендик окуяларды жана алардын ачкычтарын аныктоо (тартиптин гранулдары).
Schema Registry жайгаштыруу жана шайкештик стратегиясын бекитүү.
1-2 кызмат outbox/inbox кошуу; минималдуу CloudEvents-envelope.

11-25 күн

retry/DLQ киргизүү, backoff, иштеткичтердин боштугу.
Dashbord: lag/age/end-to-end; burn-rate алерта.
Иш-чаралардын документтери (каталог), owner's жана схемаларды ревю процесстери.

26-45 күн

Биринчи проекциянын репликасы/реструктуризациясы; runbook реплика жана backfill.
Коопсуздук саясаты (TLS, ACL, PII), retenshn, GDPR жол-жоболору.
брокер жана керектөөчүлөр үчүн үзгүлтүксүз chaos-жана оюн-күн.

16) Жетилүү метрикасы

100% домен окуялар схемалар менен сүрөттөлгөн жана катталган.
Outbox/inbox бардык өндүрүүчүлөр/ Tier-0/1.
SLO: p95 end-to-end latency жана керектөөчү lag максаттардын чегинде ≥ 99%.
Replay/Backfill downtime жок ишке ашырылат; текшерилген runbook 'ы бар.
Версиялоо: жаңы талаалар - сыныксыз; керектөөчүлөр түшпөйт.
Коопсуздук: TLS + mTLS, ACL per topic, кирүү журналдары, PII/retenshn саясаты.

17) Мини Сниппет

Kafka Producer (ишенимдүү жарыялоо, идеялар):

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

Consumer-иштетүүчү (idempotentity, psevdocode):

python if inbox. contains (event_id): return # dedup process (event) # side effects are deterministic 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 так келишимдер жана башкарылуучу ырааттуулук менен бизнес-фактылардын агымына интеграцияны айландырат. пайдубалын куруу: схемалар + реестр, outbox/inbox, тартиптин ачкычтары, демпотент иштеп, SLO жана байкоо, коопсуз retenshn жана реплика. Ошондо окуялар масштабдоо үчүн сиздин "чындык булагы" болуп калат, аналитика жана жаңы fich - алсыз байланыштар жана түнкү көчүрүү жок.

Окуя архитектурасы