اكتشاف قوائم انتظار ناقل خدمة Azure والموضوعات والاشتراكات

مكتمل

كيانات المراسلة التي تشكل جوهر قدرات المراسلة في ناقل خدمة Azure هي قوائم الانتظار والمواضيع والاشتراكات والقواعد/الإجراءات.

الصفوف

توفر قوائم الانتظار تسليم رسالة First In، First Out (FIFO) إلى مستهلك منافس واحد أو أكثر. أي، تلقي أجهزة الاستقبال رسائل ومعالجتها في نفس الترتيب الذي أُضِيفت فيه إلى قائمة الانتظار. ويتلقى المستهلك رسالة واحدة فقط ويعالج كل رسالة. نظرا لتخزين الرسائل بشكل دائم في قائمة الانتظار، لا يتعين على المنتجين (المرسلين) والمستهلكين (المستلمين) معالجة الرسائل بشكل متزامن.

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

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

يمكنك إنشاء قوائم انتظار باستخدام مدخل Microsoft Azure أو PowerShell أو واجهة سطر الأوامر أو قوالب مدير الموارد. ثم قم بإرسال واستقبال الرسائل باستخدام العملاء مكتوبة في C#، وJava، وPython، وJavaScript.

تلقي الأوضاع

يمكنك تحديد وضعين مختلفين لتلقي ناقل خدمة Azure للرسائل: Receive and delete أو Peek lock.

تلقي وحذف

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

نظرة خاطفة ثم قفل

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

  1. البحث عن الرسالة التالية التي سيتم استهلاكها، أغلقها لمنع المستهلكين الآخرين من تلقيها، ومن ثم، أرجع الرسالة إلى التطبيق.

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

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

الموضوعات والاشتراكات

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

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

إنشاء موضوع مشابه لإنشاء قائمة انتظار، كما هو موضح في المقطع السابق. يمكنك إنشاء الموضوعات والاشتراكات باستخدام قوالب Azure المدخل أو PowerShell أو CLI أو Resource Manager. ثم قم بإرسال الرسائل إلى موضوع واستقبال الرسائل من الاشتراكات باستخدام العملاء مكتوبة في C#، وJava، وPython، وJavaScript.

القواعد والإجراءات

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