CodeOX Logo
CodeOX Logo
Vol. I — No. 1
المقالة المميزة
Sep 30, 2026

البنية القائمة على الأحداث: من الأنظمة القائمة على الطلبات إلى منصات تفاعلية ضعيفة الترابط

تقرير من قبل

Nakhul Krishna

البنية القائمة على الأحداث: من الأنظمة القائمة على الطلبات إلى منصات تفاعلية ضعيفة الترابط
شكل 1. البنية القائمة على الأحداث: من الأنظمة القائمة على الطلبات إلى منصات تفاعلية ضعيفة الترابط · تصوير أصلي لـ The Chronicle

من الأنظمة القائمة على الطلبات إلى منصات تفاعلية ضعيفة الترابط

الصورة العامة

البنية القائمة على الأحداث (Event-Driven Architecture أو EDA) هي أسلوب لتصميم البرمجيات حول «الأحداث»—وهي سجلات تصف أمرًا حدث فعلًا. فبدلًا من إجبار كل عملية لاحقة على الانتهاء داخل طلب متزامن واحد، تستطيع الخدمة نشر حدث وترك مستهلكين مستقلين يتفاعلون معه. والفكرة الأساسية هي ضعف الترابط: فالمُنتِج ينشر حقيقة تجارية دون الحاجة إلى معرفة كل مستهلك.

كيف تعمل

التدفق المعتاد هو: المُنتِج (Producer) ← وسيط الأحداث / ناقل الأحداث (Event Broker / Event Bus) ← المستهلكون (Consumers). فعلى سبيل المثال، عندما تُنشئ خدمة الطلبات طلبًا، يمكنها نشر حدث OrderCreated. وتستطيع خدمات الدفع والمخزون والإشعارات والتحليلات وغيرها استهلاك هذا الحدث كلٌّ على حدة. ولا يحتاج الطلب الأصلي إلى انتظار انتهاء كل العمليات اللاحقة.

المكوّنات الأساسية

تمثّل الأحداث حقائق مثل OrderCreated وPaymentCompleted وAppointmentCancelled. ينشئ المُنتِجون هذه الأحداث وينشرونها. ويشترك المستهلكون فيها وينفّذون مسؤولياتهم الخاصة. أما وسيط الأحداث فينقل الرسائل ويوزّعها، بينما تحدّد مخططات الأحداث (Event Schemas) العقد المشترك بين المُنتِجين والمستهلكين. وتُعدّ الملكية الواضحة أمرًا مهمًا: إذ ينبغي أن تتحكم كل خدمة في قواعد عملها وبياناتها بنفسها، بدلًا من تعديل قاعدة بيانات خدمة أخرى مباشرةً.

لماذا نستخدم البنية القائمة على الأحداث؟

تفيد هذه البنية عندما يمكن تنفيذ العمل بشكل غير متزامن، أو عندما تحتاج عدة خدمات إلى التفاعل مع الحدث التجاري نفسه، أو عندما تحتاج أحمال العمل إلى التوسّع بشكل مستقل. ويمكنها تقليل الترابط المباشر بين الخدمات، والسماح بإضافة مستهلكين جدد دون تغيير المُنتِج الأصلي. وهي مفيدة بوجه خاص في الإشعارات والتحليلات ومعالجة التدقيق والتكاملات وسير العمل في الخلفية.

التحديات الهندسية

تُدخل الأنظمة غير المتزامنة مفهوم الاتساق النهائي (Eventual Consistency): فقد تعرض خدمات مختلفة حالات متباينة مؤقتًا أثناء معالجة الحدث. لذلك تحتاج الأنظمة الموثوقة إلى معالجة صريحة للرسائل المكرّرة وإعادة المحاولة وانتهاء المهلة والترتيب والمستهلكين الفاشلين. ويمنع المستهلكون عديمو الأثر عند التكرار (Idempotent Consumers) الأحداث المكرّرة من إنتاج آثار تجارية مكرّرة. أما معالجة الرسائل الميتة (Dead-Letter Handling) فتوفّر وجهة منضبطة للرسائل التي تفشل مرارًا.

صندوق الصادر المعاملاتي

تحدث مشكلة موثوقية شائعة عندما تُحدّث الخدمة قاعدة بياناتها بنجاح ثم تتعطل قبل نشر الحدث المقابل. ويحلّ نمط صندوق الصادر المعاملاتي (Transactional Outbox) هذه المشكلة بتخزين التغيير التجاري وسجل الحدث في المعاملة نفسها على قاعدة البيانات. ثم يرسل ناشر منفصل الحدث المخزَّن إلى الوسيط، مما يجعل التعافي ممكنًا إذا فشل النشر.

البنية القائمة على الأحداث مقابل الخدمات المصغّرة

ترتبط البنية القائمة على الأحداث والخدمات المصغّرة (Microservices) ببعضهما لكنهما ليستا الشيء نفسه. فالخدمات المصغّرة تحدّد قدرات تجارية مملوكة باستقلال وحدودًا للنشر؛ أما البنية القائمة على الأحداث فتحدّد أسلوب اتصال قائمًا على الأحداث. وقد تستخدم منصة الخدمات المصغّرة HTTP/gRPC المتزامن لبعض العمليات والأحداث غير المتزامنة لعمليات أخرى. كما يمكن أن يوجد الاتصال القائم على الأحداث دون خدمات مصغّرة.

الخلاصة

هدف البنية القائمة على الأحداث ليس مجرد إدخال Kafka أو RabbitMQ أو وسيط آخر. الهدف الحقيقي هو إرساء ملكية واضحة وإتاحة تفاعل المكوّنات باستقلال مع الحقائق التجارية. وتجمع البنية القوية بين عقود أحداث محددة جيدًا، وتسليم موثوق، وعدم تأثر النتيجة بالتكرار، وقواعد اتساق صريحة، ومعالجة للأعطال، والأمان، والاختبار، وقابلية المراقبة. وكما في الخدمات المصغّرة، ينبغي أن تتبع البنية المشكلةَ لا الموضة.