نمط البنية القائم على الأحداث

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

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

يمكن للبنية المستندة إلى الحدث استخدام نموذج نشر/اشتراك (يسمى أيضا pub/sub) أو نموذج دفق الحدث.

• Pub/sub: تتعقب البنية الأساسية للمراسلة الاشتراكات. عند نشر حدث، فإنه يرسل الحدث إلى كل مشترك. بعد تلقي حدث، لا يمكن إعادة تشغيله، ولا يرى المشتركون الجدد الحدث.

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

على جانب المستهلك، هناك بعض الاختلافات الشائعة:

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

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

• معالجة الأحداث المعقدة. يعالج المستهلك سلسلة من الأحداث، ويبحث عن أنماط في بيانات الحدث، باستخدام تقنية مثل Azure Stream Analytics. على سبيل المثال، يمكنك تجميع القراءات من جهاز مضمن عبر نافذة زمنية، وإنشاء إعلام إذا تجاوز المتوسط المتحرك حداً معيناً.

• معالجة تيار الحدث. استخدم النظام الأساسي لتدفق البيانات، مثل Azure IoT Hub أو Apache Kafka، كبنية أساسية لاستيعاب الأحداث وتزويدها لدفق المعالجات. تعمل معالجات الدفق على معالجة الدفق أو تحويله. قد تكون هناك معالجات دفق متعددة للأنظمة الفرعية المختلفة للتطبيق. هذا النهج مناسب تماماً لأحمال عمل IoT.

قد يكون مصدر الأحداث خارجياً للنظام، مثل الأجهزة الفعلية في حل IoT. في هذه الحالة، يجب أن يكون النظام قادراً على استيعاب البيانات في وحدة التخزين ومعدل النقل المطلوبة من قبل مصدر البيانات.

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

هناك طبولوجيا أساسية داخل العديد من البنيات المستندة إلى الحدث:

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

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

متى تستخدم هذه البنية

• يجب أن تعالج الأنظمة الفرعية المتعددة نفس الأحداث.
• المعالجة في الوقت الحقيقي مع الحد الأدنى من التأخير الزمني.
• معالجة الأحداث المعقدة، مثل مطابقة النمط أو التجميع عبر النوافذ الزمنية.
• حجم عالٍ وسرعة عالية من البيانات، مثل إنترنت الأشياء.

المزايا

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

التحديات

• تسليم مضمون.

  في بعض الأنظمة، خاصة في سيناريوهات IoT، من الضروري ضمان تسليم الأحداث.

• معالجة الأحداث بالترتيب أو مرة واحدة بالضبط.

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

• تنسيق الرسائل عبر الخدمات.

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

• معالجة الأخطاء.

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

اعتبارات إضافية

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

الموارد ذات الصلة

• فيديو مناقشة المجتمع حول اعتبارات الاختيار بين الرقصات والتزامن.