هسته رویداد محور

هسته رویداد محور چیست ؟

هسته Event-Driven Core (EDC) «ستون فقرات» معماری است که در آن حقایق کسب و کار به عنوان رویدادهای غیر قابل تغییر ضبط و توزیع می شوند و بقیه قابلیت ها (خواندن، ادغام، تجزیه و تحلیل، ذخیره سازی، اطلاعیه ها) در بالای جریان این رویدادها ساخته شده است. هسته قرارداد رویداد، قوانین تحویل، و ناورداهای سفارش/idempotency را تنظیم می کند، اتصال ضعیف و مقیاس پذیری را فراهم می کند.

ایده کلیدی: ابتدا واقعیت (هسته) را بنویسید و سپس به طور مستقل غنی سازی کنید و آن را به مدل های مورد نظر بسپارید. این اتصال را کاهش می دهد و مقاومت در برابر شکست های جزئی را افزایش می دهد.

اهداف و ویژگی های EDC

حقیقت حقایق: هر رویداد یک رکورد تغییر ناپذیر از «آنچه اتفاق افتاده است» است.
اتصال ضعیف: تولید کنندگان مصرف کنندگان را نمی شناسند ؛ گسترش سیستم - با اضافه کردن مشترکین.
مقیاس بندی: رشد افقی توسط حزب/موضوع، مصرف کنندگان مستقل.
قابلیت مشاهده و حسابرسی: شناسه های پایان به پایان، تکرارپذیری، بازخورد و پخش.
تکامل مدیریت شده: نسخه های طرح، سازگاری، کاهش ارزش.

اجزای معماری

1. کارگزار اتوبوس/رویداد: Kafka/NATS/Pulsar/SNS + SQS - کانال ها، احزاب، retentions.
2. JSON Schema/Avro/Protobuf برای سازگاری و تکامل.
3. کانتور Outbox/CDC: تثبیت واقعیت اتمی + انتشار بدون «دوبار نوشتن».
4. پیش بینی ها/خواندن (CQRS): نمایش های تحقق یافته برای نمایش سریع.
5. Sagas/orchestration: هماهنگی فرآیندهای طولانی مدت از طریق رویدادها/تیم ها.
6. غنی سازی: موضوعات فردی '.enriched '/' .derived' بدون تاثیر بر مسیر بحرانی.
7. قابلیت مشاهده: ردیابی، ورود به سیستم، معیارهای رویدادها و عقب ماندگی ها.

مدل رویداد

انواع رویدادها

رویدادهای دامنه: حقایق کسب و کار ('پرداخت. 'مجاز،' KYC. تایید شده است.)

رویدادهای ادغام: تمرکز بر سیستم های خارجی (پایدار، به آرامی در حال تغییر).
Change Data Capture (CDC): تغییرات فنی در رکورد (استفاده برای مهاجرت/ادغام).
حسابرسی/تله متری: اقدامات بازیگر، امنیت، 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» همبستگی را فراهم می کند.

معانی تحویل و idemotency

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

الگوی مصرف کننده مصرف کننده

جدول Dedup توسط 'event _ id '/' (event_id، consumer_id)' با TTL ≥ حفظ موضوع.
Upsert به جای درج ؛ versioning projections by «sequence »/« incident _ at».
معاملات در معامله: علامت «دید» + تغییر حالت.

سفارش و پارتیشن بندی

تضمین نظم در حزب.
«partition _ key» را انتخاب کنید تا تمام رویدادهای یک نهاد جمع آوری شده در همان دسته («user _ id»، «payment _ id») قرار گیرند.
اجتناب از «کلید های داغ»: هش با نمک/زیر کلید اگر شما نیاز به توزیع بار.

طرح ها و تکامل

اولین افزودنی: زمینه های اختیاری جدید، ممنوعیت تغییر انواع/معانی بدون نسخه اصلی.
سازگاری: عقب/جلو در رجیستری طرح ؛ CI تغییرات ناسازگار را مسدود می کند.

نام گذاری: دامنه فعالیت. v {major} '(' پرداخت. مجاز است. v1 ')

مهاجرت: انتشار جفت 'v1' و 'v2' به صورت موازی، ارائه دوگانه از طریق صندوق پستی، شلیک 'v1' پس از انتقال.

صندوق پستی (توصیه می شود برای خدمات معاملاتی)

1. در یک معامله پایگاه داده: رکورد دامنه و رویداد را در صندوق خروجی ذخیره کنید.
2. ناشر پس زمینه صندوق پستی را می خواند، به کارگزار منتشر می کند، علامت «ارسال شده» را نشان می دهد.
3. تضمین: هیچ «از دست دادن» واقعیت در سقوط، بدون desynchronization.

CDC (تغییر داده ها ضبط)

مناسب برای سیستم های موجود/مهاجرت ؛ source - ورود به سیستم تکثیر DB.
نیاز به فیلتر کردن/transcoding به رویدادهای دامنه (جداول خام را در خارج ترجمه نکنید).

CQRS و پیش بینی ها

دستورات تغییر حالت (اغلب همزمان)، حوادث پیش بینی (ناهمزمان) را تشکیل می دهند.
پیش بینی ها برای نمایش داده شد (جستجو، لیست ها، گزارش ها)، به روز شده توسط مشترکین طراحی شده است.
Desynchronization موقت هنجار است: UX پایدار را نشان می دهد («داده ها در چند ثانیه به روز می شوند»).

ساگاس: هماهنگی فرآیند

ارکستراسیون: یک هماهنگ کننده دستورات را ارسال می کند و منتظر وقایع است.
رقص: شرکت کنندگان به وقایع یکدیگر واکنش نشان می دهند (ساده تر، اما نیاز به نظم و انضباط در قرارداد).
قوانین: جبران واضح و وقفه، مراحل قابل تکرار، کنترل کننده های بی نظیر.

قابلیت مشاهده

ردیابی/طول: ردیابی 'trace _ id '/' span _ id' از طریق هدر ها هنگام ایجاد رویدادها.
معیارها: تاخیر مصرف کننده، میزان انتشار/مصرف، نرخ مرده نامه، سهم deduplication.
DLQ/پارکینگ: پیام های ناموفق - به یک موضوع جداگانه با هشدار ؛ پردازش مجدد را فراهم کنید.

امنیت و انطباق

طبقه بندی داده ها: هسته شامل تنها حداقل مورد نیاز از PII/داده های مالی (مدل هرم معکوس)، جزئیات - در غنی سازی.
امضا/هش ویژگی های انتقادی، کنترل یکپارچگی.
رمزگذاری در پرواز و در حالت استراحت، حق پارتیشن بندی بر اساس موضوع/مصرف کننده (IAM/ACL).
سیاست های نگهداری و حقوق فراموش شده: به وضوح برای هر موضوع تعریف شده است.

عملکرد و ثبات

فشار پشتی: مصرف کنندگان رقابت محدودی دارند، کارگزار دارای سهمیه/محدودیت است.
سوابق دسته ای و فشرده سازی گروه برای کاهش سربار.
Retray با لرزش و DLQ به جای تلاش های بی پایان.
مقاومت در برابر تعادل: آفست فروشگاه به صورت transactional/خارجی، سرعت بخشیدن به شروع سرد با عکس های فوری.

قالب های رویداد معمولی

هسته پرداخت

حق الزحمه. آغاز شد. v1 → پرداخت. مجاز است. v1 → پرداخت. دستگیر شد. v1 → پرداخت. مستقر شد. 1 '

امتناع: "پرداخت. امتناع کرد. v1 '،' پرداخت. بازپرداخت شده 1 '

تقسیم بندی: «پرداخت _ ایده»

SLA: تاخیر هسته ≤ 2c p95 ؛ مصرف کننده idempotence اجباری است.

CCM/تأیید

خواهش میکنم. شروع کرد. v1 '→' kyc. سند. دریافت شد. v1 '→' kyc. تایید شده است. v1 '/' kyc. رد کرد. 1 '

PII - حداقل ؛ جزئیات سند - در 'kyc. غنی شده v1 'با دسترسی محدود.

حسابرسی/امنیت

بله، بله. ضبط شده v1 'with attributes' actor ',' subject ',' action ',' رخ داده در ',' trace _ id '.

نگهداری/بایگانی مداوم ؛ یکپارچگی پیشرفته (WORM)

ضد ضربه

رویداد چربی: بارهای بیش از حد بدون نیاز، نشت PII.
RPC پنهان از طریق رویدادها: انتظار برای پاسخ همزمان «اینجا و اکنون».
CDC های خام به خارج: اتصال نزدیک به طرح DB.
بدون idempotency در مصرف کنندگان: دو برابر منجر به عوارض جانبی دو برابر شود.
یک موضوع مشترک «برای همه چیز»: تضاد منافع، نظم مشکل ساز، تکامل پیچیده.

پیاده سازی گام به گام EDC

1. نقشه برداری دامنه: برجسته aggregates کلیدی و چرخه عمر.
2. کاتالوگ رویدادها: نام ها، معانی، متغیر ها، زمینه های مورد نیاز.
3. Schemas و Registry - یک فرمت را انتخاب کنید، قوانین سازگاری را فعال کنید.
4. Outbox/CDC: برای هر تولیدکننده، مکانیزمی برای انتشار حقایق تعریف کنید.
5. پارتیشن بندی: انتخاب کلید و ارزیابی کلید های داغ/تقسیم مجدد.
6. Idempotency: الگوی deduplication + transactionality مصرف کننده.
7. پیش بینی-تعریف مدل های تحقق یافته و SLA ها به روز رسانی.
8. قابلیت مشاهده: ردیابی، تاخیر، DLQ، هشدار.
9. امنیت/PII: طبقه بندی داده ها، رمزگذاری، ACL.
10. راهنمای تکامل: سیاست نسخه، استهلاک، نوشتن دوگانه برای مهاجرت.

چک لیست تولید

• هر رویداد دارای «event _ id»، «trace _ id»، «رخ داده»، «partition _ key» است.
• طرح ها در رجیستری، چک سازگاری را فعال کنید.
• هویت مصرف کننده اجرا و تست شده است.
• DLQ/پارکینگ و هشدارها برای انتشار/مصرف خطاها پیکربندی شده است.
• پیش بینی ها از log (replay) با زمان قابل قبول بازسازی می شوند.

دسترسی محدود به PII ؛ حداقل محموله در هسته است.

• SLA ها با تاخیر/تحویل بر روی داشبورد اندازه گیری و قابل مشاهده هستند.
• برنامهای برای مهاجرت نسخههای رویداد و مستهلک کردن پنجرهها وجود دارد.

سوالات متداول

چگونه EDC از «فقط یک اتوبوس» متفاوت است ؟

هسته نه تنها کارگزار است، بلکه قرارداد رویداد، قوانین سفارش/idempotency، فرآیندهای تکامل و قابلیت مشاهده است.

آیا ما فقط می توانیم از CDC استفاده کنیم ؟

CDC برای ادغام/مهاجرت مناسب است، اما رویدادهای دامنه معنی را واضح تر بیان می کنند و پایگاه داده تجربه پایدارتر می شود.

در مورد انسجام چطور ؟

ما سازگاری نهایی و طراحی UX/فرآیندهای آن را می پذیریم (شاخص های به روز رسانی، بازپرداخت، جبران خسارت).

چه زمانی دقیقا یک بار مورد نیاز است ؟

نادر: زمانی که دو برابر شدن به شدت غیر قابل قبول و غیر ممکن است برای جبران. اغلب، حداقل یک بار + idemotency کافی است.

مجموع

هسته Event-Driven جریان حقایق کسب و کار را به یک پایه قابل اعتماد برای سیستم تبدیل می کند. قراردادهای رویداد روشن، نظم تحویل و قابلیت مشاهده، مقیاس پذیری، انعطاف پذیری و سرعت تکامل را بدون اتصالات همزمان شکننده و «طوفان» رگرسیون تحت تغییر می دهد.