قوائم الانتظار مقابل الموضوعات: اختيار نمط المراسلة المناسب في Azure Service Bus

By Mirko Peters · 2026-08-27

أهلاً بكم من جديد في المدونة المرافقة للبودكاست! في حلقتنا الأخيرة تعمّقنا في العناصر الأساسية لمراسلة السحابة. إذا لم تتح لكم الفرصة…

Automatically translated with AI from the original post. Read the English original

مرحباً بعودتكم إلى المدونة المصاحبة للبودكاست! في حلقتنا الأخيرة تعمّقنا في العناصر الأساسية لمراسلة السحابة. إن لم تتح لكم فرصة الاستماع بعد، فتأكدوا من الاطلاع على حلقة Azure Service Bus - Simply Explained. واليوم سنتوسع في أحد أهم القرارات المعمارية التي ستتخذونها عند بناء التطبيقات الموزّعة: الاختيار بين قوائم انتظار Azure Service Bus والموضوعات. إن فهم الفروق الدقيقة بين نمطي المراسلة هذين سيساعدكم على تصميم أنظمة أكثر مرونة وقابلية للتوسع والصيانة.

مقدمة إلى Azure Service Bus وأنماط المراسلة

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

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

ما هي Azure Service Bus؟

قبل الخوض في الفروق بين قوائم الانتظار والموضوعات، من المفيد أن نتعرف أولاً على ما تقدمه Azure Service Bus فعلياً. فهي في جوهرها وسيط رسائل يخزّن الرسائل بأمان ضمن مساحة اسم (Namespace) إلى أن يصبح تطبيق المستلم جاهزاً لمعالجتها. وتوفر ميزات قوية مثل ضمان التسليم مرة واحدة على الأقل، وإدارة الجلسات، والرسائل غير المسلَّمة (Dead-lettering)، وجدولة تسليم الرسائل.

في النظام البيئي السحابي، تسدّ Azure Service Bus الفجوة بين مكونات التطبيق المختلفة. سواء كنتم تعالجون طلبات التجارة الإلكترونية، أو تتعاملون مع بيانات القياس عن بُعد لإنترنت الأشياء (IoT)، أو تنسّقون عمليات التكامل مع تخطيط موارد المؤسسة (ERP)، توفر Service Bus المتانة وقدرة المعالجة غير المتزامنة اللازمة لإبقاء تدفق البيانات سلساً.

قوائم الانتظار مقابل الموضوعات: الخيار المعماري الجوهري

يعود التمييز الأساسي بين قوائم الانتظار والموضوعات إلى نمط المراسلة الذي تدعمه كلٌّ منهما: نقطة-إلى-نقطة مقابل النشر/الاشتراك. فاختيار النمط الخاطئ قد يؤدي إلى إعادة هيكلة معمارية، أو مشكلات في تكرار البيانات، أو اختناقات في القابلية للتوسع في المستقبل.

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

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

تعمّق في قوائم انتظار Service Bus

تُعد قوائم انتظار Service Bus العمود الفقري للمراسلة المؤسسية التقليدية. فهي مصممة للسيناريوهات التي يجب فيها تنفيذ مهمة واحدة مرة واحدة فقط بواسطة مجموعة من العمال.

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

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

إتقان الموضوعات والاشتراكات

بينما تتولى قوائم الانتظار التسليم البسيط من نقطة إلى نقطة، تتيح المواضيع (Topics) الاستفادة من قوة بنى النشر/الاشتراك (pub/sub). يعمل الموضوع كنقطة نهاية لإرسال الرسائل، لكنه لا يستطيع الاحتفاظ بالرسائل بمفرده دون وجود اشتراكات.

تخيّل الاشتراك كقائمة انتظار افتراضية مرتبطة بموضوع. عندما تُنشر رسالة إلى موضوع ما، تُسلَّم نسخة منها إلى كل اشتراك نشط. تُنشئ كل خدمة مستهلكة اشتراكها الخاص في الموضوع، ما يتيح لها معالجة الرسالة بشكل مستقل عن المستهلكين الآخرين.

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

تصفية الرسائل والمرونة

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

تتيح لك Azure Service Bus تحديد قواعد ومرشحات على الاشتراكات باستخدام صيغة شبيهة بلغة SQL أو باستخدام خصائص الارتباط. فعلى سبيل المثال، يمكنك ضبط اشتراك بحيث يستقبل فقط الرسائل التي تكون فيها الخاصية Region مساوية لـ NorthAmerica، أو التي تتجاوز فيها الخاصية OrderAmount حدًا معينًا.

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

معالجة الأخطاء باستخدام قوائم الرسائل المتعذّر تسليمها

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

تتعامل Azure Service Bus مع هذه الحالة بسلاسة عبر قوائم الرسائل المتعذّر تسليمها (Dead-Letter Queues). لكل قائمة انتظار واشتراك في موضوع قائمة فرعية مرتبطة تُسمى قائمة الرسائل المتعذّر تسليمها. إذا فشلت معالجة الرسالة عددًا كبيرًا من المرات (بتجاوز الحد الأقصى لعدد مرات التسليم) أو انتهت صلاحيتها، تنقل Service Bus الرسالة تلقائيًا إلى قائمة الرسائل المتعذّر تسليمها.

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

أفضل الممارسات لتصميم التطبيقات الموزعة

للاستفادة القصوى من تطبيق Azure Service Bus، من الضروري اتباع أفضل الممارسات المعمارية المعتمدة:

• عزل البيئات: استخدم مساحات أسماء Service Bus منفصلة لبيئات التطوير والتجهيز والإنتاج لمنع انتقال الأعطال بين البيئات.
• تطبيق البنية التحتية ككود: حدّد قوائم الانتظار والمواضيع والاشتراكات والمرشحات باستخدام قوالب ARM أو Bicep أو Terraform لضمان عمليات نشر متسقة.
• ضبط نهج الاستبقاء المناسبة: اضبط مدة بقاء الرسالة (TTL) ومدد القفل وفقًا لاحتياجات عملك الفعلية بدلًا من الاعتماد على القيم القصوى الافتراضية.
• المراقبة والتنبيه: استخدم Azure Monitor وApplication Insights لتتبع مقاييس مثل عدد الرسائل، والرسائل النشطة في قوائم الرسائل المتعذّر تسليمها، وزمن استجابة الخادم.

الخلاصة: اختيار النمط الصحيح لبنيتك المعمارية

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

لمزيد من النقاشات حول معمارية السحابة والأمن وأنماط التطوير الحديثة، لا تفوّت الاستماع إلى الحلقة كاملة: Azure Service Bus - Simply Explained. فتطبيق أنماط المراسلة هذه بشكل صحيح سيضمن أن تبقى تطبيقاتك السحابية قوية ومرنة وجاهزة للتوسع تحت أي حمل عمل.