ღონისძიების არქიტექტურა

ღონისძიების არქიტექტურა (EDA)

1) რა არის მოვლენა და რატომ არის EDA

ღონისძიება არის უცვლელი ფაქტი, რომელიც უკვე მოხდა დომენში („PlayerVerified“, „PayseCaptured“). EDA აშენებს ინტეგრაციას ამ ფაქტებისა და მათზე რეაქციების გამოქვეყნების გარშემო:

სერვისების სუსტი კავშირი,
დამოუკიდებლად მომხმარებელთა მასშტაბები
replay/პროექციის რესტრუქტურიზაცია,
გამჭვირვალე აუდიტი.

EDA არ გააუქმებს სინქრონულ API- ს - ის ავსებს მათ ჯვარედინი მომსახურების დამოკიდებულებას ასინქრონულ ფენაში.

2) მოვლენების ტიპები

დომენი: მნიშვნელოვანი ბიზნეს ფაქტები (OrderPlaced, BonusGranted).
ინტეგრაცია: „სურათები „/ცვლილებები გარე სისტემებისთვის (WalletBalanChanged).
ტექნიკური: სასიცოცხლო ციკლი და ტელემეტრია (Heartbeat, PipelineFailed).
ბრძანებები (არა მოვლენები, არამედ იქვე): ინსტრუქციები „გააკეთე X“ (CapturePayment).

რეკომენდაცია: აფეთქების ღუმელის მოვლენები პირველადი; ინტეგრაცია იქმნება კონკრეტული მომხმარებლებისთვის პროგნოზებით.

3) ღონისძიებებისა და სქემების კონტრაქტები

Схема: Avro/Protobuf/JSON Schema + Schema Registry; თავსებადობის სტრატეგია: 'BACKWARD' მომხმარებელთა ევოლუციისთვის, 'FULL' კრიტიკულ თემებზე.
CloudEvents (id, წყარო, ტიპი, ტიპი, subject, datacontenttype) - ერთიანი სათაურები.
სავალდებულო მეტამონაცემები: 'event _ id' (ULID/UUID), 'occurred _ at', 'producer', 'schema _ version', 'correlation _ id '/' causation _ ion _ in _ in', ',', 'idedempotencidempotencempotencempotencon _ kem _ kem _ ked'.
ვერსია: 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-least-once, როგორც ნაგულისხმევი, საჭიროა გადამამუშავებლების იდემპოტენტურობა.
ბრძანება: გარანტირებულია პარტიის (Kafka) ან რიგის (RabbitMQ) შიგნით, მაგრამ შეიძლება დარღვეული იყოს ჭრილობების დროს; ღონისძიების გასაღები უნდა ასახავდეს წესრიგის დომენის ზღვარს (მაგალითად, 'player _ id').
კოორდინაცია: ფულადი/სესხებისთვის - მხოლოდ ჟურნალების/საგების/კომპენსაციის საშუალებით; თავიდან აიცილეთ LWW.

კითხვის მოდელი: პროექციები და ქეში შეიძლება იყოს მოვლენა - აჩვენეთ „განახლება“... და გამოიყენეთ RNOT სტრატეგიები მკაცრი გზებისთვის.

5) Outbox/Inbox и CDC

Outbox: სერვისი წერს ფაქტს თავის მონაცემთა ბაზაში და Outbox- ის ცხრილში ერთ გარიგებაში.
Inbox: მომხმარებელი ინარჩუნებს 'event _ id' დამუშავების შედეგს.
CDC (Change Data Capture): BD (binlog/WAL) - ის საბურავზე ცვლილებების ნაკადი ინტეგრაციის შესაქმნელად პროგრამის შეცვლის გარეშე.
Idempotence: idempotence _ key '/' event _ id 'დამუშავება, არ შეცვალოთ გარე სამყარო ფიქსაციამდე.

6) CQRS и Event Sourcing

CQRS: გაზიარეთ write მოდელი და read პროექცია; პროგნოზები აგებულია მოვლენებისგან და შეიძლება ჩამორჩეს.
ღონისძიება Sourcing: დანაყოფის მდგომარეობა = მისი მოვლენების პაკეტი. დადებითი: სრული აუდიტი/მიმოხილვა; უარყოფითი: მიგრაციის სირთულე/სქემები/სნაიპშოტები.
პრაქტიკა: ES არ არის ყველგან, არამედ იქ, სადაც ისტორია და კომპენსაცია მნიშვნელოვანია; CQRS - თითქმის ყოველთვის EDA- ში.

7) საგები: ორკესტრი და ქორეოგრაფია

ორკესტრი: კოორდინატორი აგზავნის ბრძანებებს და ელოდება მოვლენებს-პასუხებს; მოსახერხებელია რთული პროცესებისთვის (KYC - Deposit - Bonus).
ქორეოგრაფია: სერვისები რეაგირებენ ერთმანეთის მოვლენებზე; უფრო ადვილია, მაგრამ უფრო რთულია თვალყურის დევნება.
ყოველთვის განსაზღვრეთ კომპენსაცია და ნაბიჯების ვადა.

8) ტოპოლოგიის დიზაინი (Kafka/RabbitMQ)

Kafka

ტოპიკური დომენის მოვლენა: 'payments. captured. v1`, `players. verified. v1`.
განაწილების გასაღები: 'player _ id '/' wallet _ id' - იქ, სადაც წესრიგი მნიშვნელოვანია.
`replication. factor=3`, `min. insync. replicas = 2 ', მწარმოებელი' acks = all '.
Retention: დროულად (მაგ. 7-90 დღე) და/ან compaction (ბოლო სახელმწიფო გასაღებით).
Retry და DLQ ტოპები backoff- ით.

RabbitMQ

Exchanges: `topic`/`direct`, routing key `payments. captured. v1`.
ფართო გულშემატკივრისთვის - 'topic' + რამდენიმე ხაზი; RPC/გუნდებისთვის - ცალკეული რიგები.
~ rum Queues for HA; TTL + dead-letter ბირჟა ჭიდაობისთვის.

9) დაკვირვება და SLO EDA

SLI/SLO:

თანამედროვე ლიტერატურა (დამუშავებულია): p50/p95/p99.
Lag/age: მომხმარებელთა ჩამორჩენა (Kafka consumer lag, Rabbit backlog age).
Throughput პუბლიკაციები/დამუშავება.
DLQ-rate და გამეორებების წილი.
ბიზნეს ოპერაციების წარმატება (მაგ., „ანაბარი დადასტურებულია 5s“).

პრაქტიკა:

მოვლენების კორელაცია 'trace _ id '/' correlation _ id' (OTel) საშუალებით.
ეგზემპლარები (ექსპლარები) მეტრიკის ბილიკიდან.
დაშბორდები „Producter-Broker-Consumer“ - ით burn-rate ალერტებით.

10) Replay, retenshny და backfill

შენიშვნები პროექციების გადაკეთების/შეცდომების გამოსწორების მიზნით: გაიყვანეთ ახალ პროექციაში/ნეიმსპეისში, შემდეგ გადაიტანეთ კითხვა.
Retenshn: იურიდიული/ბიზნეს მოთხოვნები (GDPR/PCI); მგრძნობიარე ველები - დაშიფვრა ან/და ტოკენიზირება.
Backfill: ერთჯერადი თემები/ხაზები, RPS მკაფიო ლიმიტები, ისე რომ არ მოხდეს პროდუქტების ჩაქრობა.

11) უსაფრთხოება და შესაბამისობა

TLS in transit, mTLS შიდა მომხმარებლებისთვის.
საავტორო უფლებები: per-topic/per ბირჟა ACL; მრავალმხრივი namespace/vhost საშუალებით.
PII: ღონისძიებაში ველების შემცირება; envelope მეტამონაცემები ცალკე, საჭიროების შემთხვევაში დაშიფვრა დატვირთვის დატვირთვისთვის.
ღონისძიებებზე წვდომის აუდიტი, „ყველა ძლიერი“ გასაღების აკრძალვა.
პოლიტიკოსები ჭრიან და წაშლის უფლებას (GDPR): ან შეინახეთ ბმულები მონაცემებზე, ან tombstone მოვლენებზე და პროექციებში წაშლა.

12) ტესტირება EDA- ში

Contract tests: მომხმარებლები უხელმძღვანელებენ თავიანთ მოლოდინს სქემებზე (consumer-driven).
Replay ტესტები: ისტორიული ნიმუშის პროგონი სქემის ახალი დამუშავების/ვერსიის საშუალებით.
Chaos სცენარები: ბროკერის შეფერხება/დაკარგვა, კვანძების ვარდნა, მომხმარებლის ჩამორჩენა SLO რჩება ფარგლებში.
Smoke in CI: მოკლე დასასრული დროის თემებზე.

13) მიგრაცია „CRUD ინტეგრაცია - EDA“

1. დაადგინეთ დომენის ფაქტები.
2. შემოიტანეთ outbox თავდაპირველ სერვისებში.
3. გამოაქვეყნეთ მინიმალური დომენის მოვლენები და დააკავშირეთ 1-2 პროექცია.
4. თანდათანობით გამორთეთ წერტილის სინქრონული ინტეგრაცია, შეცვალეთ ისინი გამოწერით.
5. შეიყვანეთ Schema Registry და თავსებადობის პოლიტიკა.
6. გააფართოვეთ add-only ღონისძიებები ველებით; ხარვეზები - მხოლოდ ახალი ტიპების საშუალებით.

14) ანტი შაბლონები

მოვლენები = „DTO API“ (ძალიან ცხიმიანი, დამოკიდებულია შიდა მოდელზე) - არღვევს მომხმარებლებს.
Schema Registry- ის არარსებობა და თავსებადობა არის „მყიფე“ ინტეგრაცია.
კოდიდან გამოქვეყნება და მონაცემთა ბაზაში ჩაწერა არ არის ატომური (არა გარეთ) - კარგავთ მოვლენებს.
„Exactly-once ყველგან“ - მაღალი ფასი სარგებლის გარეშე; უკეთესია at-least-once + idempotence.
ერთი „უნივერსალური“ გარიგების გასაღები ცხელი მხარეა.
Replay პირდაპირ პროექციაში - არღვევს ონლაინ SLO.

15) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

დომენის მოვლენების და მათი გასაღებების დადგენა (წესრიგის გრანულები).
განათავსეთ Schema Registry და დაამტკიცეთ თავსებადობის სტრატეგია.
დაამატეთ outbox/inbox 1-2 სერვისში; მინიმალური CloudEvents-envelope.

11-25 დღე

შეიყვანეთ retry/DLQ, backoff, გამტარებლების იდემპოტენტურობა.
დაშბორდები: lag/age/end-to-end; burn-rate alerty.
მოვლენების დოკუმენტაცია (კატალოგი), owner 'y და სქემების გადახრის პროცესები.

26-45 დღე

პირველი პროექციის რეპლეი/რესტრუქტურიზაცია; runbook reple და backfill.
უსაფრთხოების პოლიტიკოსები (TLS, ACL, PII), რეტენინგი, GDPR პროცედურები.
რეგულარული ქაოსი და თამაშის დღეები ბროკერისა და მომხმარებლებისთვის.

16) სიმწიფის მეტრიკა

დომენის მოვლენების 100% აღწერილია სქემებით და რეგისტრირებულია.
Outbox/inbox მოიცავს ყველა მწარმოებელს/Tier-0/1 კონსუტერს.
SLO: p95 end-to-end latency და consumer lag მიზნების ფარგლებში 99% -ით.
Replay/Backfill შესაძლებელია downthim- ის გარეშე; არის დადასტურებული runbook '.
ვერსია: ახალი ველები - ხარვეზების გარეშე; ძველი მომხმარებლები არ ეცემა.
უსაფრთხოება: TLS + mTLS, ACL per topic, წვდომის ჟურნალები, პოლიტიკა PII/retenshn.

17) მინი snippets

Kafka Producter (საიმედო გამოცემა, იდეები):

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

Consumer დამუშავება (idempotence, ფსევდო კოდი):

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“; შემდეგი '5 მ/15 მ'.

18) დასკვნა

EDA ინტეგრაციას გადააქცევს ბიზნეს ფაქტების ნაკადს მკაფიო კონტრაქტებით და კონტროლირებადი კოორდინაციით. ააშენეთ საძირკველი: სქემები + რეესტრი, outbox/inbox, წესრიგის გასაღებები, idempotent დამუშავება, SLO და დაკვირვება, უსაფრთხო retenshing და raples. შემდეგ მოვლენები გახდება თქვენი „ჭეშმარიტების წყარო“ მასშტაბების, ანალიტიკისა და ახალი შეცდომების შესახებ - მყიფე კავშირებისა და ღამის მიგრაციის გარეშე.

ღონისძიების არქიტექტურა