هندسة الحدث

هندسة الأحداث (EDA)

1) ما هو الحدث ولماذا EDA

• ضعف اتصال الخدمات،
• توسيع نطاق المستهلكين بشكل مستقل،
• إعادة/إعادة ترتيب الإسقاطات،
• المراجعة الشفافة للحسابات.

لا تلغي EDA واجهات برمجة التطبيقات المتزامنة - فهي تكملها من خلال إدخال التبعيات عبر الخدمة في الطبقة غير المتزامنة.

2) أنواع الأحداث

المجال: حقائق تجارية مهمة (OrderPlaced، BonusGended).
التكامل: «لقطات «/تغييرات للأنظمة الخارجية (UserUpdated، WalletBalanceChange).
تقنية: دورة الحياة والقياس عن بعد (Heartbeat، PipelineFailed).
الأوامر (ليست الأحداث، ولكن في مكان قريب): تعليمات «do X» (CapturePayment).

التوصية: تعتبر الأحداث المتعلقة بالنطاقات أساسية ؛ تتكون من إسقاطات لمستهلكين معينين.

3) عقود ومخططات الأحداث

Схема: Avro/Protobuf/JSON Schema + Schema Registry ؛ استراتيجية التوافق: «متخلفة» لتطور المستهلك، «كاملة» حول الموضوعات الحاسمة.
CloudEvents (معرف، مصدر، نوع، وقت، موضوع، نوع بيانات) - رؤوس موحدة.
البيانات الوصفية المطلوبة: 'event _ id' (ULID/UUID)، 'حدث _ at'،' منتج '،' مخطط _ نسخة '،' ارتباط _ id '/' السببية _ 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) Outbox/Inbox и CDC

Outbox: تكتب الخدمة حقيقة إلى قاعدة بياناتها وإلى جدول outbox في معاملة واحدة ينشرها العامل → الحافلة.
صندوق الوارد: «حدث _ معرف» المتاجر الاستهلاكية مع نتيجة المعالجة للتفريغ.
CDC (Change Data Capture): تدفق التغييرات من قاعدة البيانات (binlog/WAL) إلى الحافلة لبناء تكاملات دون تغييرات في التطبيق.
الخصوصية: المعالجة بواسطة «الخصوصية _ المفتاح »/« الحدث _ id»، لا تغير العالم الخارجي حتى يتم إصلاحه.

6) CQRS и مصادر الفعاليات

CQRS: نموذج كتابة منفصل وإسقاطات مقروءة ؛ يتم وضع الإسقاطات من الأحداث ويمكن أن تتخلف عن الركب.
Event Sourcing: Compregate state = rollup of its events. الإيجابيات: مراجعة الحسابات/إعادة التشغيل الكاملة ؛ السلبيات: تعقيد الهجرات/المخططات/اللقطات.
الممارسة: ES - ليس في كل مكان، ولكن حيث التاريخ والتعويض مهمان ؛ CQRS - دائمًا تقريبًا في EDA.

7) الملاحم: التنسيق وتصميم الرقصات

التنسيق: يرسل المنسق الأوامر وينتظر أحداث الاستجابة ؛ ملائمة للعمليات المعقدة (KYC→Deposit→Bonus).
تصميم الرقصات: تتفاعل الخدمات مع أحداث بعضها البعض ؛ أسهل ولكن من الصعب تتبعها.
حدد دائمًا التعويضات والمواعيد النهائية للخطوات.

8) تصميم الطوبولوجيا (كافكا/RabbitMQ)

كافكا

الموضوع لكل حدث مجال: 'المدفوعات. تم القبض عليه. v1 '،' اللاعبين. تم التحقق منها. v1 '.
مفتاح التقسيم: "player _ id "/" wallet _ id' - حيث يكون الطلب مهمًا.
الاسترداد. العامل = 3 '،' min. insync. النسخ المتماثلة = 2 '، المنتج "acks = all'.
الاحتفاظ: حسب الوقت (مثلاً) 7-90 يومًا) و/أو الضغط (الحالة الأخيرة حسب المفتاح).
موضوعات لإعادة التجربة و DLQ مع التراجع.

أرنب MQ

التبادلات: "الموضوع "/" المباشر"، توجيه المدفوعات الرئيسية ". تم القبض عليه. v1 '.
للحصول على مروحة واسعة - «موضوع» + عدة قوائم انتظار ؛ لـ RPC/الأوامر - قوائم انتظار منفصلة.
طوابير النصاب القانوني لـ HA ؛ TTL + تبادل الحروف الميتة لاسترجاع.

9) إمكانية الرصد و SLO EDA

• الكمون من البداية إلى النهاية (occurred_at → المعالجة): p50/p95/p99.
• التأخير/العمر: تأخر المستهلك (تأخر المستهلك في كافكا، عمر الأرنب المتراكم).
• النشر/التجهيز الإنتاجي.
• معدل DLQ ونسبة التكرارات.
• نجاح المعاملات التجارية (مثلاً) «تأكيد الإيداع ≤ 5c»).

• ارتباط الأحداث عبر 'trace _ id '/' correlation _ id' (OTel).
• أمثلة من المواءمة → المقاييس.
• لوحات القيادة «Producer→Broker→Consumer» مع تنبيهات معدل الحرق.

10) إعادة التشغيل والاحتفاظ به وملئه

إعادة إعادة بناء التوقعات/إصلاح الأخطاء: القيادة إلى إسقاط/مساحة جديدة، ثم تبديل القراءة.
الاحتفاظ: المتطلبات القانونية/التجارية ؛ الحقول الحساسة - التشفير و/أو الترميز.
الردم: سمات/قوائم انتظار لمرة واحدة، تنظيف حدود RPS لتجنب خنق الحث.

11) السلامة والامتثال

TLS أثناء العبور، mTLS للعملاء الداخليين.
الإذن: لكل موضوع/لكل تبادل الرباط الصليبي الأمامي ؛ تعدد المهام عبر مساحة الاسم/vhost.
PII: تقليل الحقول في الحدث ؛ البيانات الوصفية للظروف بشكل منفصل، الحمولات المشفرة إذا لزم الأمر.
الوصول إلى التدقيق للأحداث، يحظر المفاتيح «القوية للغاية».
الاحتفاظ بسياسات (اللائحة العامة لحماية البيانات) والحق في حذفها: إما تخزين مراجع البيانات أو أحداث شاهد القبور والحذف في الإسقاطات.

12) الاختبار في EDA

اختبارات العقد: يتحقق المستهلكون من صحة توقعاتهم للمخططات (التي يحركها المستهلك).
اختبارات إعادة التشغيل: قم بتشغيل أخذ العينات التاريخية من خلال إصدار معالج/مخطط جديد.
سيناريوهات الفوضى: يظل تأخير/خسارة الوسيط، وانخفاض العقدة، وتأخر المستهلك → SLO في الداخل.
الدخان في CI: خط أنابيب قصير من طرف إلى طرف حول الموضوعات الزمنية.

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

1. حدد حقائق المجال.
2. تضمين صندوق خارجي في خدمات المصدر.
3. نشر الحد الأدنى من أحداث المجال وربط 1-2 الإسقاطات.
4. قم بتعطيل عمليات التكامل المتزامنة تدريجياً، واستبدالها بالاشتراكات.
5. نوع سجل المخطط وسياسة التوافق.
6. توسيع نطاق المناسبات الإضافية فقط مع الحقول ؛ الفواصل - فقط من خلال أنواع جديدة.

14) الأنماط المضادة

الأحداث = «DTO API» (سمينة جدًا، تعتمد على النموذج الداخلي) - كسر المستهلكين.
الافتقار إلى سجل المخطط والتوافق - التكامل «الهش».
النشر من الكود والكتابة إلى قاعدة البيانات ليس ذريًا (لا يوجد صندوق خارجي) - تفقد الأحداث.
«مرة واحدة بالضبط في كل مكان» - سعر مرتفع بدون فائدة ؛ أفضل مرة واحدة على الأقل + الخصوصية.
مفتاح تقسيم «عالمي» → تقسيم ساخن.
إعادة التشغيل مباشرة في توقعات الإنتاج - يكسر SLOs عبر الإنترنت.

15) قائمة التنفيذ المرجعية (0-45 يوما)

0-10 أيام

تحديد أحداث المجال ومفاتيحها (حبيبات النظام).
نشر سجل المخطط والموافقة على استراتيجية التوافق.
أضف صندوق الخروج/صندوق الوارد إلى 1-2 الخدمات ؛ الحد الأدنى من CloudEvents-develope.

11-25 يومًا

أدخل إعادة المحاولة/DLQ، التراجع، غباء المعالجين.
لوحات المعلومات: التأخير/العمر/من البداية إلى النهاية ؛ تنبيهات معدل الحرق.
توثيق الأحداث (فهرس)، وعمليات استعراض المالكين والمخططات.

26-45 يومًا

إعادة/إعادة ترتيب الإسقاط الأول ؛ إعادة تشغيل كتاب التشغيل وملئه.
السياسات الأمنية (TLS، ACL، PII)، الاحتفاظ، إجراءات اللائحة العامة لحماية البيانات.
الفوضى المنتظمة وأيام اللعب للوسيط والمستهلكين.

16) مقاييس النضج

100٪ من أحداث المجال موصوفة من قبل المخططات ومسجلة.
يغطي Outbox/inbox جميع المنتجين/المستهلكين Tier-0/1.
SLO: p95 زمن الوصول من طرف إلى طرف وتأخر المستهلك ضمن الأهداف ≥ 99٪.
إعادة التشغيل/التعبئة الخلفية ممكنة دون توقف ؛ هناك دفاتر تشغيل تم التحقق منها.
الإصدار: مجالات جديدة - دون كسر ؛ المستهلكون القدامى لا يسقطون.
الأمان: 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()

• "اختبار: المهام" → على nack → DLX "المهام. إعادة المحاولة. 1 م (TTL = 60) → العودة إلى «الأسئلة» ؛ «5 م/15 م».

18)

تحول EDA عمليات الدمج إلى تدفق لحقائق الأعمال بعقود واضحة واتساق مُدار. بناء الأساس: مخططات + سجل، صندوق الخروج/صندوق الوارد، مفاتيح الطلب، معالجات الخصوصية، SLO وقابلية الملاحظة، الاحتفاظ الآمن وإعادة التشغيل. ثم ستصبح الأحداث «مصدر الحقيقة» للتوسع والتحليلات والميزات الجديدة - دون اتصالات هشة وهجرات ليلية.