الهندسة الموجهة بالأحداث: بناء الأنظمة التي React في الوقت الحقيقي

TL;DR

• الهندسة الموجهة بالأحداث (EDA) تمكن الأنظمة من React للتغيرات في الوقت الفعلي من خلال اتصال غير مترابط وغير متزامن.
• هي مثالية للأنظمة الكبيرة والموزعة وذات الإنتاجية العالية حيث الاستجابة والقابلية للتوسع مهمة.
• تشمل المكونات الأساسية منتجي الأحداث، المستهلكين، الوسطاء، ومستودعات الأحداث.
• تُستخدم أدوات مثل Apache Kafka و AWS EventBridge و RabbitMQ على نطاق واسع لتنفيذ EDA.
• EDA تحسن القابلية للتوسع والمرونة لكنها تزيد التعقيد في استكشاف الأخطاء واختبارها وضمان اتساق الأحداث.

---

ما ستتعلمه

• المبادئ والمكونات الأساسية للهندسة الموجهة بالأحداث.
• كيف تقارن EDA بأنظمة الطلب-الاستجابة التقليدية.
• متى تستخدم (ومتى لا تستخدم) EDA.
• كيفية بناء نظام موجه بالأحداث بسيط باستخدام بايثون وكافكا.
• المزالق الشائعة واستراتيجيات الاختبار والاعتبارات الأمنية.
• أمثلة واقعية من أنظمة الإنتاج الكبيرة.

---

المتطلبات المسبقة

ستستفيد أكثر من هذه المقالة إذا كنت مرتاحًا بالفعل مع:

• مفاهيم أساسية لأنظمة موزعة (مثل الميكروخدمات، طوابير الرسائل).
• الاطلاع على بايثون أو JavaScript.
• فهم أنماط الاتصال غير المتزامن.

---

تُتوقع من التطبيقات الحديثة أن تكون سريعة وقابلة للتفاعل ومرونة. سواء كانت منصة دفع تعالج آلاف المعاملات في الثانية أو خدمة بث توصي بالمحتوى في الوقت الفعلي، فإن الاستجابة هي المفتاح.

يمكن أن تواجه هياكل الطلب-الاستجابة التقليدية (مثل REST APIs) صعوبة في مواجهة هذه المتطلبات — فهي غالبًا متزامنة، مترابطة بشدة، وصعبة التوسع بشكل مستقل. هنا تبرز الهندسة الموجهة بالأحداث (EDA).

تم بناء EDA حول فكرة أن الأنظمة يجب أن React للأحداث — تغييرات في الحالة — بدلاً من الاستطلاع المستمر أو الانتظار للطلبات. بدلًا من أن تطلب خدمة واحدة من أخرى مباشرة، تقوم الخدمات بنشر أحداث يمكن للخدمات الأخرى الاشتراك فيها والتفاعل معها.

---

المفاهيم الأساسية للهندسة الموجهة بالأحداث

تعتمد EDA على عدد قليل من المكونات الرئيسية:

1. منتجي الأحداث

تولد هذه الأحداث عند حدوث شيء ما — على سبيل المثال، قيام المستخدم بوضع طلب أو إرسال مستشعر لقراءة.

2. المستهلكين

تستمع هذه للأحداث المحددة وReact وفقًا لذلك — على سبيل المثال، إرسال تأكيد البريد الإلكتروني أو تحديث المخزون.

3. الوسطاء

الوسيط (مثل Kafka أو RabbitMQ) يوجه الأحداث من المنتجين إلى المستهلكين. يضمن التسليم والثبات والقابلية للتوسع.

4. مستودع الأحداث

مكون اختياري يحافظ على سجل دائم لجميع الأحداث لإعادة التشغيل أو التحليل أو استكشاف الأخطاء.

هنا رسم تخطيطي بسيط لكيفية ارتباط هذه المكونات:

flowchart LR
    A[Event Producer] -->|Publishes Event| B[(Event Broker)]
    B -->|Delivers Event| C[Event Consumer 1]
    B -->|Delivers Event| D[Event Consumer 2]

---

EDA مقابل هندسة الطلب-الاستجابة التقليدية

الجانب	الهندسة الموجهة بالأحداث	هندسة الطلب-الاستجابة
الاتصال	غير متزامن	متزامن
الترابط	مترابط بشكل ضعيف	مترابط بشدة
القابلية للتوسع	عالية (توسع مستقل)	محدودة بالاعتماد على المتزامن
التحمل للعطل	عالية (يمكن إعادة المحاولة للأحداث)	منخفضة (الأخطاء تنتشر)
التأخير	منخفض لمعالجة الأحداث	أعلى بسبب المكالمات المحظورة
التعقيد	أعلى (يتطلب وسطاء الرسائل، التماثل)	أبسط في التنفيذ

---

متى تستخدم مقابل متى لا تستخدم

✅ متى تستخدم

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

❌ متى لا تستخدم

• تطبيقات CRUD بسيطة: حيث واجهات برمجة التطبيقات المتزامنة كافية.
• تتطلب اتساقًا قويًا: معاملات بنكية يجب أن تُنفذ بشكل ذري.
• حجم حدث منخفض: قد لا تبرر تكاليف الوسطاء التعقيد.

---

أمثلة واقعية

• Netflix: تستخدم أنماط موجهة بالأحداث للمراقبة والتنبيه في الوقت الفعلي¹.
• Uber: تعتمد على تدفقات الأحداث لتنسيق السائقين والركاب وتحديثات الأسعار².
• Airbnb: تستخدم خطوط أنابيب قائمة على Kafka للتحليل ومزامنة البيانات³.

تستفيد هذه الشركات من EDA للتوسع عالميًا، وضمان انخفاض التأخير، والحفاظ على المرونة حتى عند فشل خدمات فردية.

---

خطوة بخطوة: بناء نظام موجه بالأحداث باستخدام كافكا وبايثون

لنقم ببناء نظام موجه بالأحداث بسيط حيث تنشر خدمة الطلبات حدثًا، وتستهلكه خدمة البريد الإلكتروني.

1. إعداد كافكا

يمكنك تشغيل كافكا محليًا باستخدام Docker:

Docker run -d --name zookeeper -p 2181:2181 zookeeper:3.9
Docker run -d --name kafka -p 9092:9092 --link zookeeper:zookeeper -e KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 wurstmeister/kafka

2. المنتج: نشر حدث

from kafka import KafkaProducer
import json

producer = KafkaProducer(
    bootstrap_servers=['localhost:9092'],
    value_serializer=lambda v: json.dumps(v).encode('utf-8')
)

event = {
    'event_type': 'ORDER_CREATED',
    'order_id': '12345',
    'user_email': 'user@example.com'
}

producer.send('orders', event)
producer.flush()
print("Event published: ORDER_CREATED")

3. المستهلك: React إلى الحدث

from kafka import KafkaConsumer
import json

consumer = KafkaConsumer(
    'orders',
    bootstrap_servers=['localhost:9092'],
    value_deserializer=lambda m: json.loads(m.decode('utf-8'))
)

for message in consumer:
    event = message.value
    if event['event_type'] == 'ORDER_CREATED':
        print(f"Sending confirmation email to {event['user_email']}")

مثال الإخراج

Event published: ORDER_CREATED
Sending confirmation email to user@example.com

هذا العرض التوضيحي البسيط يوضح الفصل بين المنتج والمستهلك — خدمة الطلبات لا تحتاج إلى معرفة أي شيء عن خدمة البريد الإلكتروني.

---

المزالق الشائعة & الحلول

المزالق	السبب	الحل
معالجة الأحداث المكررة	إعادة المحاولات الشبكية أو إعادة تشغيل المستهلك	تنفيذ اللا تكرارية في المستهلكين
مشكلات ترتيب الأحداث	أقسام متعددة أو بروكرز	استخدام مفاتيح التقسيم للبيانات ذات الصلة
رسائل مفقودة	تهيئة خاطئة للبروكير أو تعطل	تمكين التأكيدات والنسخ المكرر
التدفقات الصعبة في الاستكشاف	الطبيعة غير المتزامنة	استخدام التسجيل المركزي والتتبع

---

آثار الأداء

أنظمة موجهة بالأحداث تتفوق في أحمال العمل المقيدة بالـI/O لأنها تفصل المنتجين عن المستهلكين، مما يسمح بالمعالجة المتوازية⁴. ومع ذلك، يتطلب ضبط الأداء الانتباه إلى:

• معالجة الدُفعات: استهلاك عدة أحداث في وقت واحد لتقليل التكاليف الإضافية.
• إدارة الضغط العكسي: منع المستهلكين من التحميل الزائد.
• الضغط: استخدام ضغط Kafka المدمج (مثل LZ4) لتقليل عرض النطاق.

تظهر المقاييس من الوثائق الرسمية لـKafka أن بروكيرًا واحدًا يمكنه التعامل مع ملايين الرسائل في الثانية تحت ظروف مثالية⁵.

---

اعتبارات الأمان

الأمان في EDA يتطلب نهجًا متعدد الطبقات:

• المصادقة والترخيص: استخدام SASL أو OAuth2 لـKafka⁶.
• تشفير البيانات: تمكين TLS لنقل الأحداث.
• التحقق من الإدخال: تحقق دائمًا من حمولات الأحداث لمنع هجمات الحقن.
• أقل صلاحيات: يجب أن يشترك المستهلكون فقط في المواضيع الضرورية.
• المراجعة: الحفاظ على سجلات الأحداث للامتثال والتتبع.

---

قابلية التوسع وتحمل الأعطال

EDA تدعم بشكل طبيعي التوسع الأفقي:

• المنتجون يمكنهم التوسع بشكل مستقل للتعامل مع أحجام أحداث أعلى.
• المستهلكون يمكنهم تشكيل مجموعات مستهلكين للمعالجة المتوازية.

Airbnb Engineering – البنية التحتية للبيانات على نطاق واسع https://medium.com/airbnb-engineering/data-infrastructure-at-airbnb-8adfb34f169c ↩

Python AsyncIO التوثيق – التزامن وأحمال محدودة بـ I/O https://docs.python.org/3/library/asyncio.html ↩

Apache Kafka التوثيق الرسمي – الأداء وقابلية التوسع https://kafka.apache.org/documentation/ ↩

Apache Kafka نظرة عامة على الأمان https://kafka.apache.org/documentation/#security ↩

OpenTelemetry التوثيق – المقاييس والتتبع https://opentelemetry.io/docs/ ↩