كانت خدماتنا متشابكة ككرة صوف: كيف أنقذتنا ‘المعمارية الموجهة بالأحداث’ (EDA) من جحيم الاقتران الخانق؟

يا جماعة الخير، السلام عليكم ورحمة الله وبركاته.

خلوني أحكيلكم قصة صارت معي قبل كم سنة. كنا شغالين على منصة تجارة إلكترونية، وبدأت المنصة صغيرة وبسيطة، وكنا مبسوطين عليها. لكن مع الوقت، ومع زيادة عدد المستخدمين والخدمات، بلشت الأمور “تكركب”. كانت خدماتنا (الطلبات، المخزون، الدفع، الإشعارات، الشحن) مرتبطة ببعضها بطريقة غريبة، زي كرة الصوف اللي دخلت فيها قطة ولعبت فيها. إشي فايت بإشي، ومش عارفين راسنا من رجلينا.

أذكر مرة، كان لازم نعمل تعديل بسيط جداً في خدمة “الطلبات”، بس عشان نطلّع هالتعديل، كان لازم نعدّل ونختبر وننشر أربع خدمات ثانية مرتبطة فيها! أي تغيير كان زي اللي بيمشي في حقل ألغام، ما بتعرف متى وشو رح ينفجر. كنا عايشين في حالة “اقتران خانق” (Tight Coupling)، والمطورين عنا صاروا زي فريق طفاية الحريق، كل يوم بنطفي حريقة جديدة في مكان شكل. في هذاك الوقت، حسيت إنه لو ضلينا هيك، المشروع كله رح ينهار. لحد ما في يوم، بعد نقاش طويل وسهر لآخر الليل، واحد من الشباب حكى كلمة غيّرت كل إشي: “يا جماعة، شو رأيكم نفك هالتشابك ونخلي الخدمات تحكي مع بعض عن طريق الأحداث؟”. ومن هنا، بدأت رحلتنا مع المعمارية الموجهة بالأحداث (EDA).

ما هو جحيم “الاقتران الخانق” (Tight Coupling)؟

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

تقنياً، لما تكون خدمة (مثلاً، خدمة الطلبات) بتنادي خدمة ثانية (مثلاً، خدمة الإشعارات) بشكل مباشر (Synchronous API Call)، بصير عنا الآتي:

• سلسلة من نقاط الفشل: إذا خدمة الإشعارات وقعت أو بطيئة، خدمة الطلبات رح تتأثر مباشرة، ويمكن تفشل هي كمان. الفشل ينتشر زي النار في الهشيم.
• بطء في التطوير: زي ما حكيت في قصتي، أي تغيير صغير بيتطلب تعديلات وتنسيق بين فرق متعددة، وهذا بيقتل السرعة والرشاقة.
• صعوبة في التوسع (Scalability): ما بتقدر توسّع خدمة لحالها بسهولة، لأنها معتمدة على خدمات ثانية لازم تتوسع معها بنفس الوقت.

باختصار، الاقتران الخانق بحوّل نظامك من مجموعة خدمات مستقلة إلى كتلة واحدة هشة ومعقدة.

المنقذ: المعمارية الموجهة بالأحداث (Event-Driven Architecture)

طيب، شو الحل يا أبو عمر؟ الحل هو تغيير طريقة تفكيرنا في التواصل بين الخدمات. بدل ما الخدمات “تتصل” ببعضها البعض مباشرة، رح نخليها “تتفاعل” مع أحداث بتصير في النظام. هالحكي معناه إنه الخدمات بطلت تهتم “بمين” رح يستقبل المعلومة، وصارت بس تهتم بإنها “تعلن” عن اللي صار عندها.

فكر فيها زي “المنادي” في الحارة زمان. المنادي كان يطلع على الساحة ويعلن الخبر (مثلاً: “وصل قمح جديد يا أهل الحارة!”). المنادي ما بهمه مين بالزبط سمع الخبر، ما بروح بخبّط على باب الخباز والتاجر وربة البيت واحد واحد. هو بس بعلن الخبر، والمهتمين بالخبر (الخباز اللي بده قمح، التاجر اللي بده يبيع) بسمعوا وبتصرفوا بناءً على هالخبر. الخباز ما بيعرف مين كمان سمع، والتاجر ما بهمه إذا الخباز أخذ المعلومة أو لأ. هاد هو “فك الارتباط” (Decoupling) في أبهى صوره.

أركان المعمارية الموجهة بالأحداث

عشان نبني هالنظام، بنحتاج لكم قطعة أساسية:

1. الحدث (Event): هو سجل لشيء حصل في الماضي. مثلاً: OrderPlaced (تم وضع طلب جديد)، UserRegistered (تم تسجيل مستخدم جديد). الحدث هو حقيقة ثابتة لا تتغير.
2. منتج الحدث (Event Producer): هو الخدمة اللي بتنشئ الحدث وبتنشره. في مثالنا، خدمة “الطلبات” هي منتج لحدث OrderPlaced.
3. مستهلك الحدث (Event Consumer): هو أي خدمة مهتمة بنوع معين من الأحداث. لما تسمع بالحدث، بتقوم بعمل معين. مثلاً، خدمة “المخزون” وخدمة “الإشعارات” ممكن يكونوا مستهلكين لحدث OrderPlaced.
4. وسيط الأحداث (Event Broker): هاد هو “الساحة العامة” أو “الجهاز العصبي” للنظام. هو البنية التحتية اللي بتستقبل الأحداث من المنتجين وبتضمن وصولها للمستهلكين المهتمين. أشهر الأمثلة عليه: RabbitMQ, Apache Kafka, AWS SQS/SNS, Google Pub/Sub.

مثال عملي: من الاقتران إلى فك الارتباط

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

الطريقة القديمة (الاقتران الخانق)

في خدمة المستخدمين (User Service)، الكود ممكن يكون هيك (باستخدام Python كمثال):

# في خدمة المستخدمين (User Service)
def register_user(email, password):
  # 1. إنشاء المستخدم في قاعدة البيانات
  user = db.create_user(email, password)
  
  # 2. استدعاء خدمة الإيميلات بشكل مباشر!
  try:
    email_service_api.send_welcome_email(user.id)
  except Exception as e:
    # مشكلة! لو خدمة الإيميلات واقعة، شو نعمل؟
    # هل نلغي عملية التسجيل كلها؟ النظام صار هش.
    log.error("فشل إرسال إيميل الترحيب!")

  # 3. استدعاء خدمة التحليلات بشكل مباشر!
  try:
    analytics_service_api.track_signup(user.id)
  except Exception as e:
    # نقطة فشل أخرى!
    log.error("فشل تتبع عملية التسجيل!")

  return user

المشاكل واضحة: خدمة المستخدمين مرتبطة بشكل مباشر بخدمتين ثانيتين. أي مشكلة فيهم بتأثر عليها مباشرة.

الطريقة الجديدة (المعمارية الموجهة بالأحداث)

الآن، لنعيد كتابة نفس المنطق باستخدام EDA.

1. خدمة المستخدمين (منتج الحدث)

وظيفتها صارت أبسط بكثير. هي بس بتسجل المستخدم و”بتصرخ” في النظام إنه في مستخدم جديد سجل.

# في خدمة المستخدمين (User Service)
def register_user(email, password):
  # 1. إنشاء المستخدم في قاعدة البيانات
  user = db.create_user(email, password)
  
  # 2. تحضير ونشر الحدث. وانتهى!
  event_payload = {
      "user_id": user.id, 
      "email": user.email, 
      "registered_at": datetime.now().isoformat()
  }
  event_broker.publish(topic="user.registered", message=event_payload)
  
  # خدمة المستخدمين أنهت مهمتها بنجاح وبسرعة.
  return user

2. خدمة الإيميلات (مستهلك للحدث)

هاي الخدمة بتكون “بتسمع” على الأحداث من نوع user.registered. لما يوصلها حدث، بتبعث الإيميل.

# في خدمة الإيميلات (Email Service)
def on_user_registered(event_payload):
  user_email = event_payload["email"]
  send_actual_welcome_email_to(user_email)
  log.info(f"تم إرسال إيميل ترحيبي إلى {user_email}")

# الاشتراك في الموضوع المطلوب من وسيط الأحداث
event_broker.subscribe(topic="user.registered", handler=on_user_registered)

3. خدمة التحليلات (مستهلك آخر)

نفس الإشي، هاي الخدمة بتسمع لنفس الحدث وبتعمل شغلها بمعزل عن أي خدمة ثانية.

# في خدمة التحليلات (Analytics Service)
def on_user_registered(event_payload):
  user_id = event_payload["user_id"]
  track_signup_in_db(user_id)
  log.info(f"تم تسجيل حدث التسجيل للمستخدم {user_id}")

# الاشتراك في نفس الموضوع
event_broker.subscribe(topic="user.registered", handler=on_user_registered)

شوفوا الجمال! خدمة المستخدمين ما بتعرف أصلاً بوجود خدمة إيميلات أو خدمة تحليلات. ولو حبينا بكرة نضيف خدمة جديدة (مثلاً، خدمة بتعطي نقاط ولاء للمستخدم الجديد)، كل اللي علينا نعمله هو إنشاء “مستهلك” جديد يسمع لنفس الحدث، بدون ما نلمس أي سطر كود في الخدمات الموجودة. هاد هو معنى الرشاقة والقوة.

مش كل إشي وردي: تحديات لازم تعرفها

صحيح أنا متحمس جداً لهالمعمارية، بس من باب الأمانة العلمية، لازم أحكيلكم إنها مش حل سحري لكل المشاكل، وفيها تحدياتها الخاصة:

• التعقيد الجديد: صحيح حلينا تعقيد التشابك، بس أضفنا نوع جديد من التعقيد. تتبع مسار طلب معين عبر عدة خدمات صار أصعب. “وين راحت الرسالة؟”، “ليش ما تم استهلاك الحدث؟” هاي أسئلة رح تسألها كثير. لهيك، أنظمة المراقبة (Monitoring) والتعقب (Tracing) بتصير ضرورية جداً.
• الاتساق النهائي (Eventual Consistency): في المثال السابق، الإيميل مش رح يوصل للمستخدم في نفس اللحظة اللي بكبس فيها على زر التسجيل. رح يكون في تأخير بسيط (أجزاء من الثانية أو ثواني). النظام بصير “متسق في النهاية”، مش “متسق فورياً”. هاد إشي لازم تقبله وتصمم نظامك على أساسه.
• إدارة وسيط الأحداث: الـ Event Broker هو قلب النظام النابض. “إذا وقع الوسيط، بتوقع كل الدار”. لازم يكون عندك خطة لضمان استمراريته (High Availability) والتعامل مع أي مشاكل فيه.
• التعامل مع الأخطاء والتكرار: ماذا لو فشل مستهلك في معالجة رسالة؟ ماذا لو استلم نفس الرسالة مرتين؟ لازم تصمم المستهلكين تبعونك ليكونوا “Idempotent”، يعني لو استلموا نفس الرسالة ١٠٠ مرة، النتيجة النهائية تكون نفس نتيجة استلامها مرة واحدة.

نصائح من خبرة أبو عمر

• ابدأ صغير: لا تحاول تعيد كتابة نظامك كله مرة واحدة. اختار جزء صغير ومناسب من نظامك، وحاول تفك ارتباطه باستخدام EDA. تعلم من التجربة، وبعدين توسع.
• عرّف عقود الأحداث جيداً (Event Schema): اتفق على شكل ومحتوى كل حدث بشكل واضح. استخدم أدوات مثل JSON Schema أو Avro لتوثيق وفرض هذا الشكل. هذا هو “العقد” بين خدماتك.
• استثمر في الأدوات: لا تبخل على أدوات المراقبة والـ Logging والـ Tracing. بدونها، رح تكون زي اللي بسوق سيارة في ليلة ظلماء بدون أضواء.
• غيّر طريقة تفكيرك: أهم إشي هو التحول الذهني نحو التفكير غير المتزامن (Asynchronous). مش كل إشي لازم يصير “هلأ”. فهم هاي النقطة هو مفتاح النجاح في EDA.

الخلاصة النهائية 💡

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

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

فكّر فيها، يمكن هي الحل اللي بستنى فيك تفك فيه عقدة نظامك. 😉

والله ولي التوفيق.