تحرير

مشاركة عبر

نمط الناشر-المشترك

Azure Event Grid
Azure Event Hubs
Azure Service Bus

تمكين تطبيق ما للإعلان عن الأحداث للعديد من المستهلكين المهتمين بشكل غير متزامن، دون إقران المرسلين بالمستقبلين.

يسمى أيضًا: المراسلة Pub/sub

السياق والمشكلة

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

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

حل

تقديم نظام فرعي للمراسلة غير المتزامنة يتضمن ما يلي:

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

    إشعار

    الرسالة عبارة عن حزمة بيانات. الحدث هو رسالة تعلم المكونات الأخرى بالتغيير أو الإجراء الذي حدث.

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

  • آلية لنسخ كل رسالة من قناة الإدخال إلى قنوات الإخراج لجميع المشتركين المهتمين بتلك الرسالة. عادة ما تتم معالجة هذه العملية من قبل وسيط مثل وسيط الرسائل أو ناقل الحدث.

يوضح الرسم التخطيطي التالي المكونات المنطقية لهذا النمط:

نمط النشر والاشتراك باستخدام وسيط رسائل

تتمتع المراسلة بين الحانة/الفرعية بالمزايا التالية:

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

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

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

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

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

  • يسهل سير العمل غير المتزامن عبر المؤسسة.

  • إنه يحسن قابلية الاختبار. يمكن مراقبة القنوات ويمكن فحص الرسائل أو تسجيلها كجزء من استراتيجية اختبار التكامل الشاملة.

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

المسائل والاعتبارات

راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:

  • التقنيات الحالية. يوصى بشدة باستخدام منتجات وخدمات المراسلة المتوفرة التي تدعم نموذج النشر والاشتراك، بدلًا من إنشاء نموذج خاص بك. في Azure، ضع في اعتبارك استخدام ناقل خدمة Microsoft Azure أو مراكز الأحداث أو شبكة الأحداث. تتضمن التقنيات الأخرى التي يمكن استخدامها للمراسلة بين الحانة/الفرعية Redis وRabbitMQ وApache Kafka.

  • معالجة الاشتراك. يجب أن توفر البنية الأساسية للمراسلة آليات يمكن للمستهلكين استخدامها للاشتراك في القنوات المتوفرة أو إلغاء الاشتراك فيها.

  • الأمان. يجب تقييد الاتصال بأي قناة رسالة بواسطة نهج الأمان لمنع التنصت من قبل المستخدمين أو التطبيقات غير المصرح بها.

  • مجموعات فرعية من الرسائل. عادة ما يكون المشتركون مهتمين فقط بالمجموعة الفرعية من الرسائل التي يوزعها الناشر. غالبًا ما تسمح خدمات المراسلة للمشتركين بتضييق نطاق مجموعة الرسائل التي يتلقاها:

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

  • مشتركو أحرف البدل. ضع في اعتبارك السماح للمشتركين بالاشتراك في مواضيع متعددة عبر أحرف البدل.

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

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

  • أولوية الرسالة. قد تتطلب بعض الحلول معالجة الرسائل بترتيب معين. يوفر نمط قائمة انتظار الأولوية آلية لضمان تسليم رسائل معينة قبل الآخرين.

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

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

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

  • جدولة الرسائل. قد يتم حظر الرسالة مؤقتًا ولا يجب معالجتها حتى تاريخ ووقت محددين. يجب ألا تكون الرسالة متوفرة لجهاز الاستقبال حتى هذه المرة.

  • توسيع نطاق المشتركين. إذا لم يتمكن مشترك معين من مواكبة معدل الرسائل التي يتلقاها، فاستخدم نمط المستهلكين المتنافسين لتوسيع نطاقه.

موعد استخدام النمط

استخدم هذا النمط عندما:

  • يحتاج التطبيق إلى بث المعلومات إلى عدد كبير من المستهلكين.

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

  • يمكن للتطبيق إرسال معلومات إلى المستهلكين دون الحاجة إلى استجابات في الوقت الحقيقي من المستهلكين.

  • تم تصميم الأنظمة التي يتم دمجها لدعم نموذج تناسق نهائي لبياناتها.

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

قد لا يكون هذا النمط مفيدًا في الحالات الآتية:

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

  • يتطلب التطبيق تفاعلا شبه فوري مع المستهلكين.

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط الناشر/المشترك في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

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

- RE:03 تحليل وضع الفشل
- وظائف الخلفية RE:07
تساعد قرارات تصميم الأمان على ضمان سرية بيانات وأنظمة حمل العمل وتكاملها وتوافرها. يقدم هذا النمط حدود تجزئة أمان مهمة تمكن مشتركي قائمة الانتظار من عزل الشبكة عن الناشر.

- تجزئة SE:04
يركز تحسين التكلفة على الحفاظ على عائد حمل العمل على الاستثمار وتحسينه. يمكن لهذا التصميم المنفصل تمكين نهج يستند إلى الحدث في تصميمك، والذي يقترن جيدا بالفوترة المستندة إلى الاستهلاك لتجنب الإفراط في التوفير.

- تحسين معدل CO:05
- تكاليف التحجيم ل CO:12
يساعد التميز التشغيلي على تقديم جودة حمل العمل من خلال العمليات الموحدة وتماسك الفريق. يمكن أن تمكنك هذه الطبقة من غير المباشر من تغيير التنفيذ بأمان على جانب الناشر أو المشترك دون الحاجة إلى تنسيق التغييرات على كلا المكونين.

- OE:06 تطوير حمل العمل
- OE:11 ممارسات النشر الآمنة
تساعد كفاءة الأداء حمل العمل الخاص بك على تلبية الطلبات بكفاءة من خلال التحسينات في التحجيم والبيانات والرمز. يمكنك فصل الناشرين عن المستهلكين من تحسين الحوسبة والرمز خصيصا للمهمة التي يحتاج المستهلك إلى تنفيذها للرسالة المحددة.

- PE:02 تخطيط السعة
- PE:05 التحجيم والتقسيم

كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.

مثال

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

بنية تكامل المؤسسة

الخطوات التالية

قد تكون الإرشادات التالية مناسبة عند تنفيذ هذا النمط:

قد تكون الأنماط التالية مناسبة عند تنفيذ هذا النمط:

  • نمط المراقب. يعتمد نمط Publish-Subscribe على نمط المراقب عن طريق فصل الموضوعات عن المراقبين عن طريق المراسلة غير المتزامنة.

  • نمط وسيط الرسائل. يتم تنفيذ العديد من الأنظمة الفرعية للمراسلة التي تدعم نموذج النشر والاشتراك عبر وسيط الرسائل.

يصف منشور المدونة هذا طرقا مختلفة للتعامل مع الرسائل التي تصل خارج الترتيب.