معماری رویداد

معماری رویداد (EDA)

1) رویداد چیست و چرا EDA

• اتصال ضعیف خدمات،
• افزایش مصرف کنندگان به طور مستقل
• پخش/تنظیم مجدد پیش بینی ها،
• حسابرسی شفاف

EDA API های همزمان را لغو نمی کند - آنها را با آوردن وابستگی های سرویس متقابل به لایه ناهمزمان تکمیل می کند.

2) انواع رویداد

دامنه: حقایق کسب و کار قابل توجه (OrderPosted، BonusGranted).
ادغام: «عکس های فوری «/تغییرات برای سیستم های خارجی (UserUpdated، WalletBalanceChanged).
فنی: چرخه زندگی و تله متری (ضربان قلب، PipelineFailed).
دستورات (نه رویدادها، بلکه در نزدیکی): دستورالعملهای «انجام X» (CapturePayment).

توصیه: رویدادهای دامنه اصلی هستند ؛ ادغام توسط پیش بینی برای مصرف کنندگان خاص تشکیل شده است.

3) قراردادهای رویداد و طرح

Схема: Avro/Protobuf/JSON طرح + طرح رجیستری ؛ استراتژی سازگاری: «BACKWARD» برای تکامل مصرف کننده، «FULL» در موضوعات مهم.
CloudEvents (شناسه، منبع، نوع، زمان، موضوع، نوع داده) - سرصفحه های یکنواخت.
فراداده مورد نیاز: 'event _ id' (ULID/UUID), 'رخ داد _ at', 'producer', 'schema _ version', 'correlation _ id '/' causion _ id', 'idempotency _ key'.
نسخه بندی: اضافه کردن فقط زمینه ها، ممنوعیت تغییر نام/شکست معنایی ؛ انواع جدید - تم های جدید/انواع.

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) تحویل، سفارش و سازگاری

حداقل یک بار به عنوان پیشفرض → عدم توانایی گرداننده مورد نیاز است.
سفارش: تضمین شده در یک حزب (کافکا) و یا صف (RabbitMQ), اما ممکن است توسط عقب نشینی شکسته; کلید رویداد باید یک گرانول دامنه سفارش (به عنوان مثال، 'player _ id') را منعکس کند.

سازگاری: برای پول/وام - فقط از طریق مجلات/ساگا/جبران خسارت ؛ اجتناب از LWW

مدل خواندن: پیش بینی ها و کش ها می توانند نهایی باشند - نشان می دهد «به روز رسانی در حال پیشرفت»... و از استراتژی های RNOT برای مسیرهای سخت استفاده کنید.

5) صندوق پستی/صندوق ورودی и CDC

Outbox: سرویس یک واقعیت را به پایگاه داده خود و جدول خروجی در یک معامله می نویسد - کارگر به اتوبوس ارسال می کند.
صندوق ورودی: فروشگاه های مصرف کننده "event _ id 'with نتیجه پردازش برای deduplication.
CDC (Change Data Capture): جریان تغییرات از پایگاه داده (binlog/WAL) به اتوبوس برای ایجاد یکپارچگی بدون تغییر برنامه.
Idempotency: پردازش توسط 'idempotency _ key '/' event _ id'، دنیای خارج را تغییر نمی دهد تا ثابت شود.

6) CQRS и منابع رویداد

CQRS: مدل نوشتن جداگانه و پیش بینی های خواندن ؛ پیش بینی ها از حوادث ساخته شده و می توانند عقب بمانند.
Event Sourcing: Aggregate state = rollup کردن رویدادها. مزایا: حسابرسی کامل/پخش ؛ معایب: پیچیدگی مهاجرت/طرح/عکس های فوری.
تمرین: ES - نه در همه جا، اما جایی که تاریخ و جبران خسارت مهم هستند ؛ CQRS - تقریبا همیشه در EDA.

7) ساگاس: ارکستراسیون و رقص

ارکستراسیون: هماهنگ کننده دستورات را ارسال می کند و منتظر رویدادهای پاسخ است ؛ مناسب برای فرآیندهای پیچیده (KYC → سپرده → پاداش).
طراحی رقص: خدمات به رویدادهای یکدیگر واکنش نشان می دهند ؛ آسان تر اما سخت تر برای ردیابی.
همیشه پاداش ها و مهلت های مرحله را تعریف کنید.

8) طراحی توپولوژی (کافکا/RabbitMQ)

کافکا

موضوع در هر رویداد دامنه: "پرداخت. دستگیر شد. v1 '،' بازیکنان. تایید شده v1 '.
کلید پارتیشن بندی: 'player _ id '/' wallet _ id' - جایی که سفارش مهم است.
تکرار میکنم. factor = 3 ',' min. اینساینک. replicas = 2 ', producer' acks = all '.
نگهداری: توسط زمان (به عنوان مثال،. 7-90 روز) و/یا تراکم (آخرین حالت توسط کلید).
موضوعات برای تلاش مجدد و DLQ با عقب نشینی.

RabbitMQ

مبادلات: "موضوع "/" مستقیم"، مسیریابی کلید "پرداخت. دستگیر شد. v1 '.
برای یک طرفدار گسترده - «موضوع» + چندین صف ؛ برای RPC/دستورات - صف های جداگانه.
Quorum صف برای HA ؛ TTL + تبادل نامه مرده برای بازپرداخت.

9) قابلیت مشاهده و SLO EDA

• تاخیر پایان به پایان (occurred_at → پردازش شده): p50/p95/p99.
• تاخیر/سن: تاخیر مصرف کننده (تاخیر مصرف کننده کافکا، سن عقب ماندگی خرگوش).
• انتشار/پردازش توان.
• نرخ DLQ و نسبت تکرارها
• موفقیت معاملات تجاری (به عنوان مثال «سپرده تایید شده ≤ 5c»).

• همبستگی رویدادها از طریق 'trace _ id '/' correlation _ id' (OTel).
• نمونهها از همتراز کردن → معیارها.
• داشبورد «تولید کننده → کارگزار → مصرف کننده» با هشدار سوختگی نرخ.

10) پخش، نگهداری و پر کردن

پخش برای بازسازی پیش بینی ها/رفع اشکالات: رانندگی به طرح ریزی/فضای جدید، سپس خواندن را تغییر دهید.
نگهداری: الزامات قانونی/تجاری (GDPR/PCI) ؛ فیلدهای حساس - رمزگذاری و/یا نشانه گذاری.
Backfill: یکی کردن تم/صف، روشن محدودیت RPS برای جلوگیری از خفه کردن تولید.

11) ایمنی و انطباق

TLS در حمل و نقل، mTLS برای مشتریان داخلی.
مجوز: در هر موضوع/در هر مبادله ACL ؛ چند وظیفه از طریق فضای نام/vhost.
PII: به حداقل رساندن زمینه ها در این رویداد ؛ ابرداده پاکت به طور جداگانه، بارهای رمزگذاری شده در صورت لزوم.
دسترسی به رویدادها را بررسی کنید، کلیدهای «قدرتمند» را ممنوع کنید.
سیاست های حفظ و حق حذف (GDPR): یا منابع داده یا رویدادهای سنگ قبر را ذخیره کنید و در پیش بینی ها حذف کنید.

12) تست در EDA

آزمون قرارداد: مصرف کنندگان اعتبار انتظارات خود را از طرح (مصرف کننده محور).
تست های پخش: نمونه برداری تاریخی را از طریق یک نسخه جدید handler/schema اجرا کنید.
سناریوهای هرج و مرج: تاخیر کارگزار/از دست دادن، افت گره، تاخیر مصرف کننده → SLO در داخل باقی می ماند.
دود در CI: یک خط لوله کوتاه پایان به پایان در موضوعات زمان.

13) مهاجرت «ادغام CRUD → EDA»

1. حقایق دامنه را شناسایی کنید.
2. قراردادن صندوق خروجی در خدمات منبع.
3. حداقل رویدادهای دامنه را منتشر کنید و 1-2 پیش بینی را متصل کنید.
4. به تدریج نقطه ادغام همزمان غیر فعال کردن، جایگزین کردن آنها با اشتراک.
5. نوع Schema Registry و یک سیاست سازگاری.
6. رویدادهای فقط افزودنی را با فیلدها گسترش دهید. شکاف - فقط از طریق انواع جدید.

14) ضد الگوهای

رویدادها = «API DTO» (بیش از حد چربی، به مدل داخلی بستگی دارد) - شکستن مصرف کنندگان.
فقدان رجیستری طرح و سازگاری - ادغام «شکننده».
انتشار از کد و نوشتن به پایگاه داده اتمی نیست (بدون خروجی) - شما رویدادها را از دست می دهید.
«دقیقا یک بار در همه جا» - قیمت بالا بدون سود ؛ بهتر حداقل یک بار + idemotency.
یک کلید پارتیشن «جهانی» → یک پارتیشن داغ.
پخش مستقیم به طرح تولید - SLO های آنلاین را می شکند.

15) چک لیست پیاده سازی (0-45 روز)

0-10 روز

شناسایی رویدادهای دامنه و کلید های آنها (گرانول سفارش).
از Schema Registry استفاده کنید و استراتژی سازگاری را تایید کنید.
اضافه کردن صندوق خروجی/صندوق ورودی به 1-2 خدمات ؛ حداقل CloudEvents پاکت.

11-25 روز

را وارد کنید سعی مجدد/DLQ, عقب نشینی, idemotency از handlers.

داشبورد: تاخیر/سن/پایان به پایان ؛ هشدار نرخ سوختگی

مستندات رویداد (کاتالوگ)، صاحبان و فرآیندهای بررسی طرح.

26-45 روز

پخش/تنظیم مجدد اولین طرح ؛ پخش مجدد runbook و پر کردن.
سیاست های امنیتی (TLS، ACL، PII)، حفظ، روش های GDPR.
هرج و مرج منظم و روزهای بازی برای کارگزار و مصرف کنندگان.

16) معیارهای بلوغ

100٪ از رویدادهای دامنه توسط طرح ها توصیف شده و ثبت شده است.
Outbox/inbox تمام تولید کنندگان/مصرف کنندگان Tier-0/1 را پوشش می دهد.
SLO: تاخیر پایان به پایان p95 و تاخیر مصرف کننده در اهداف ≥ 99٪.
Replay/Backfill بدون خرابی امکان پذیر است. کتاب های تایید شده وجود دارد و.
نسخه بندی: زمینه های جدید - بدون شکستن ؛ مصرف کنندگان قدیمی سقوط نمی کنند.
امنیت: TLS + mTLS، ACL در هر موضوع، سیاهههای مربوط به دسترسی، PII/سیاست حفظ.

17) قطعه های کوچک

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

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

• 'queue: tasks' → on nack → DLX 'tasks. تلاش مجدد 1m '(TTL = 60s) → بازگشت به' tasks '; بیشتر '5 متر/15 متر'.

18) نتیجه گیری

EDA ادغام را به یک جریان از حقایق کسب و کار با قراردادهای روشن و سازگاری مدیریت تبدیل می کند. ساخت پایه و اساس: طرح + رجیستری, صندوق خروجی/صندوق, کلید سفارش, گرداننده idempointent, SLO و مشاهده, حفظ امن و پخش. سپس رویدادها «منبع حقیقت» شما برای مقیاس بندی، تجزیه و تحلیل و ویژگی های جدید - بدون اتصالات شکننده و مهاجرت شبانه تبدیل خواهند شد.