Event-Driven ბირთვი

რა არის Event-Driven ბირთვი

Event-Driven ბირთვი (EDC) არის არქიტექტურის „ხერხემალი“, რომელშიც ბიზნეს ფაქტები ფიქსირდება და ვრცელდება, როგორც უცვლელი მოვლენები, ხოლო დანარჩენი ფუნქციონირება (კითხვა, ინტეგრაცია, ანალიტიკა, ქეში, ნოტიფიკაცია) აგებულია ამ მოვლენების ნაკადის თავზე. ბირთვი ადგენს ღონისძიების კონტრაქტს, მიწოდების წესებს და წესრიგის/იდემპოტენტურობის ინვარიანტებს, რაც უზრუნველყოფს სუსტი კავშირს და მასშტაბურობას.

საკვანძო იდეა: ჯერ ჩაწერეთ ფაქტი (ბირთვი), შემდეგ დამოუკიდებლად გამდიდრება და დააყენეთ იგი სასურველ მოდელებში. ეს ამცირებს დაკავშირებას და ზრდის წინააღმდეგობას ნაწილობრივი ჩავარდნების მიმართ.

EDC მიზნები და თვისებები

ფაქტების ჭეშმარიტება: თითოეული მოვლენა არის უცვლელი ჩანაწერი „რა მოხდა“.
სუსტი კავშირი: მწარმოებლებმა არ იციან მომხმარებლები; სისტემის გაფართოება - აბონენტების დამატებით.
მასშტაბი: ჰორიზონტალური ზრდა წვეულებებზე/ტოპიკებში, დამოუკიდებელი მომხმარებლები.
დაკვირვება და აუდიტი: იდენტიფიკატორების გავლა, რეპროდუქცია, რეტენსია და განმეორება.
კონტროლირებადი ევოლუცია: სქემების ვერსიები, თავსებადობა, დეპრესია.

არქიტექტურული კომპონენტები

1. მოვლენების ავტობუსი/ბროკერი: Kafka/NATS/Pulsar/SNS + SQS - არხები, წვეულებები, რეტენციები.
2. სქემების რეესტრი: JSON Schema/Avro/Protobuf თავსებადობისა და ევოლუციისთვის.
3. Outbox/CDC კონტური: ფაქტის ატომური ფიქსაცია + პუბლიკაცია „ორმაგი ჩაწერის“ გარეშე.
4. პროექცია/კითხვა (CQRS): მატერიალიზებული წარმოდგენები სწრაფი მოთხოვნებისთვის.
5. საგა/ორკესტრი: გრძელი პროცესების კოორდინაცია მოვლენებისა/ბრძანებების საშუალებით.
6. გამდიდრება: ინდივიდუალური ტოპები '.enriched '/' .derived' კრიტიკულ გზაზე გავლენის გარეშე.
7. Observability: ტრეკერი, ლოგიკა, მეტრიკა მოვლენებსა და ლაგებში.

ღონისძიების მოდელი

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

დომენის მოვლენები: საქმიანი ფაქტები. 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: მიიღწევა ნაკადის და საცავის დონეზე გარიგების/idempotent კლავიშების/ტბების საშუალებით (უფრო ძვირი, საჭიროა კარგი მიზეზი).

მომხმარებლის idempotence შაბლონი

Dedup ცხრილი 'event _ id '/' (event _ id, consumer _ id)' s TTL - ტოპიკური რეტენციები.
უფსერტი ინსტალაციის ნაცვლად; პროექციის ვერსია 'sequence '/' occurred _ at'.
ოპერაციები, როგორც გარიგების ნაწილი: ნიშანი „დაინახა“ + მდგომარეობის ცვლილება.

შეკვეთა და განაწილება

გარანტირებული შეკვეთა პარტიაში.
შეარჩიეთ 'partition _ key' ისე, რომ ერთი აგრეგატის ყველა მოვლენა მოხვდეს ერთ ნაწილში ('user _ id', 'payment _ id').
თავიდან აიცილეთ „ცხელი გასაღებები“: ჰაში მარილით/კლავიშებით, თუ საჭიროა დატვირთვის განაწილება.

სქემები და ევოლუცია

Additive-first: ახალი სურვილისამებრ ველები, ტიპის/სემანტიკის შეცვლის აკრძალვა მაიორი ვერსიის გარეშე.
თავსებადობა: BACKWARD/FORWARD სქემების რეესტრში; CI ბლოკავს შეუთავსებელ ცვლილებებს.
სახელწოდება: 'domain. action. v{major}` (`payment. authorized. v1`).
მიგრაცია: გამოაქვეყნეთ წყვილი 'v1' და 'v2' პარალელურად, უზრუნველყეთ ორმაგი გამოსხივება (ორმაგი გამოსხივება გარე ბოქსის საშუალებით), წაშალეთ 'v1' გადასვლის შემდეგ.

Outbox и CDC

Outbox (რეკომენდებულია გარიგების მომსახურებისთვის)

1. ერთ DD გარიგებაში: ჩვენ ვრჩებით დომენის ჩანაწერს და მოვლენას გარედან.
2. ფონის პაბლიცერი კითხულობს outbox- ს, აქვეყნებს ბროკერს, აღნიშნავს „გაგზავნილ“.
3. გარანტიები: ვარდნის დროს ფაქტის „დაკარგვა“ არ არსებობს, არ არსებობს რასინქრონიზაცია.

CDC (Change Data Capture)

შესაფერისია არსებული სისტემებისთვის/მიგრაციისთვის; წყარო არის BD რეპლიკაციის ლოგი.
მოითხოვს ფილტრაციის/გადაკეთებას აფეთქების ღუმელის მოვლენებში (ნუ გადაიტანთ „ნედლეულ“ ცხრილებს გარეთ).

CQRS და პროექცია

ბრძანებები ცვლის მდგომარეობას (ხშირად სინქრონულად), მოვლენები ქმნის პროექციებს (ასინქრონულად).
პროგნოზები განკუთვნილია თხოვნებისთვის (ძებნა, სიები, მოხსენებები), განახლებულია აბონენტების მიერ.
დროებითი რასინქრონიზაცია ნორმაა: აჩვენეთ სტაბილური UX („მონაცემები განახლდება რამდენიმე წამში“).

საგები: პროცესების კოორდინაცია

ორკესტრი: ერთი კოორდინატორი აგზავნის ბრძანებებს და ელოდება მოვლენებს.
ქორეოგრაფია: მონაწილეები რეაგირებენ ერთმანეთის მოვლენებზე (უფრო მარტივი, მაგრამ მოითხოვს კონტრაქტებში დისციპლინას).
წესები: მკაფიო ანაზღაურება და დრო, განმეორებითი ნაბიჯები, imptent დამუშავება.

დაკვირვება

Trace/Span: გადაყარეთ 'trace _ id '/' spank _ id "სათაურების საშუალებით მოვლენების წარმოქმნისას.
მეტრიკა: მომხმარებელთა ლაქი, პუბლიკაციის/მოხმარების სიჩქარე, მკვდარი ლეტერი, დედოპლიკაციების წილი.
DLQ/parking lot: წარუმატებელი შეტყობინებები - ცალკეულ ტოპიკაში ალერტით; უზრუნველყეთ გადამუშავება.

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

მონაცემთა კლასიფიკაცია: ბირთვი შეიცავს მხოლოდ საჭირო მინიმუმს PII/findanes (საპირისპირო პირამიდის მოდელი), დეტალები გამდიდრებაში.
ხელმოწერა/მძიმე ატრიბუტები, მთლიანობის კონტროლი.
In-flight და at-rest დაშიფვრა, უფლებების თანმიმდევრობა თემებზე/კონსიუმებზე (IAM/ACL).
რეტენციის პოლიტიკა და დავიწყების უფლებები: მკაფიოდ არის განსაზღვრული თითოეული ტოპიკისთვის.

პროდუქტიულობა და სტაბილურობა

Backpressure: მომხმარებლებს აქვთ კონკურენციის შეზღუდვა, ბროკერს აქვს კვოტები/ლიმიტები.
Batch დამუშავება და შეკუმშვა: დაჯგუფეთ ჩანაწერები, რომ შემცირდეს გადახდილი ხარჯები.
Retrai ერთად jitter და DLQ, უსასრულო მცდელობების ნაცვლად.
Rebalance წინააღმდეგობა: შეინახეთ ოფსეტები გარიგების/გარეგნულად, დააჩქარეთ ცივი დაწყება Snapshots- ით.

ტიპიური მოვლენების შაბლონები

გადახდის ბირთვი

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

უარყოფა: 'payment. declined. v1`, `payment. refunded. v1`

განაწილება: 'payment _ id'

SLA: ბირთვის ლაგი 2s p95; მომხმარებელთა იდემპოტენტურობა სავალდებულოა.

KUS/გადამოწმება

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

PII - მინიმალური; დოკუმენტის დეტალები - 'kyc. enriched. v1 'შეზღუდული დაშვებით.

აუდიტი/უსაფრთხოება

`audit. recorded. v1 'ატრიბუტებით' actor ',' subject ',' action ',' occurred _ at ',' trace _ id '.
უწყვეტი გადაკეთება/არქივი; გაზრდილი მთლიანობა (WORM საცავი).

ანტიპატერები

Fat Event: გადატვირთული payload's საჭიროების გარეშე, გაჟონვა PII.
Hidden RPC მოვლენების საშუალებით: სინქრონიზებული პასუხების მოლოდინი „აქ და ახლა“.
ნედლეული CDC გარედან: მჭიდრო კავშირი BD სქემასთან.
მომხმარებლებს არ აქვთ იდემპოტენტურობა: დუბლები იწვევს ორმაგ გვერდითი მოვლენებს.
ერთი ზოგადი ტოპიკა „ყველაფრისთვის“: ინტერესთა კონფლიქტი, პრობლემური წესრიგი, რთული ევოლუცია.

EDC- ის ეტაპობრივი განხორციელება

1. დომენის დაქირავება: განასხვავეთ ძირითადი დანაყოფები და სასიცოცხლო ციკლები.
2. მოვლენების კატალოგი: სახელები, მნიშვნელობები, ინვარიანტები, სავალდებულო ველები.
3. სქემები და რეესტრი: შეარჩიეთ ფორმატი, ჩართეთ თავსებადობის წესები.
4. Outbox/CDC: თითოეული მწარმოებლისთვის დაადგინეთ ფაქტების გამოქვეყნების მექანიზმი.
5. განაწილება: შეარჩიეთ გასაღებები და შეაფასეთ ცხელი გასაღებები/ხელახალი დაშლა.
6. Idempotence: Deadup შაბლონი + მომხმარებელთა გარიგება.
7. პროგნოზები: შეამოწმეთ მატერიალიზებული მოდელები და SLA განახლებები.
8. ობსერვატორია: კვალი, ლაგები, DLQ, ალერტები.
9. უსაფრთხოება/PII: მონაცემთა კლასიფიკაცია, დაშიფვრა, ACL.
10. ჰიდი ევოლუციის მიხედვით: ვერსიის პოლიტიკა, დეპრესია, ორმაგი თავისუფალი მიგრაციისთვის.

წარმოების ჩეკის სია

• თითოეულ მოვლენას აქვს 'event _ id', 'trace _ id', 'occurred _ at', 'partition _ key'.
• სქემები რეესტრში შედის თავსებადობის შემოწმება.
• მომხმარებელთა Idempotence ხორციელდება და შემოწმებულია.
• DLQ/parking lot და ალერტები შედგენილია პუბლიკაციის/მოხმარების შეცდომების შესახებ.
• პროექციები გადაკეთებულია ლოგიდან (გამოსხივება) მისაღები დროით.
• PII- ზე წვდომა შეზღუდულია; ბირთვში მინიმალური payload.
• SLA lage/მიწოდებისთვის იზომება და ჩანს დაშბორდებზე.
• არსებობს გეგმა, რომ მიგრაცია მოახდინოს მოვლენების ვერსიებსა და დეპრესიის ფანჯრებს.

FAQ

რით განსხვავდება EDC მხოლოდ საბურავისგან?
ბირთვი არა მხოლოდ ბროკერია, არამედ მოვლენების ხელშეკრულებაც, წესრიგის/იდემპოტენტურობის წესები, ევოლუციის პროცესები და დაკვირვება.

შესაძლებელია მხოლოდ CDC- ზე აშენება?
CDC შესაფერისია ინტეგრაციისთვის/მიგრაციისთვის, მაგრამ აფეთქების ღუმელის მოვლენები უფრო ნათლად გამოხატავს მნიშვნელობას და უფრო სტაბილურად განიცდის DD- ს ცვლილებებს.

რა უნდა გავაკეთოთ, რომ შეთანხმებულები ვიყოთ?
ჩვენ ვიღებთ საღამოს კონცეფციას და ვქმნით UX/პროცესებს მის ქვეშ (განახლების ინდიკატორები, რეტრატორები, კომპენსაცია).

როდის გჭირდებათ exactly-once?
იშვიათად: როდესაც გაორმაგება მკაცრად მიუღებელია და კომპენსაცია შეუძლებელია. უფრო ხშირად საკმარისია at-least-once + idempotence.

შედეგი

Event-Driven ბირთვი ბიზნეს ფაქტების ნაკადს სისტემის საიმედო საძირკველად აქცევს. მოვლენების მკაფიო კონტრაქტები, მიწოდების დისციპლინა და დაკვირვება იძლევა ევოლუციის მასშტაბურობას, სტაბილურობას და სიჩქარეს - ცვლილებების დროს მყიფე სინქრონული კავშირების და რეგრესიების „ქარიშხლის“ გარეშე.