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

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

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

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

• تعذر إرسال الرسائل.
• تعذر استقبال الرسائل.
• تعذر إدارة الكيانات (إنشاء كيانات أو استردادها أو تحديثها أو حذفها).
• تعذر الاتصال بالخدمة.

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

الموثوقية في ناقل خدمة Microsoft Azure

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

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

ملاحظة

يمكن أن يعني مصطلح التخزين كلًا من SQL Azure وتخزين Azure.

يحتوي ناقل خدمة Microsoft Azure على عدد من عوامل التخفيف من المخاطر لهذه المشكلات. تناقش الأقسام التالية كل مشكلة وعوامل التخفيف من المخاطر الخاصة بها.

التحكم بالنطاق الترددي*

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

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

لمزيد من المعلومات حول كيفية معالجة التعليمات البرمجية للتطبيق لمخاوف التقييد، راجع الوثائق الخاصة بنمط التقييد.

مشكلة تبعية Azure

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

فشل ناقل خدمة Microsoft Azure على نظام فرعي واحد

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

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

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

الآن بعد أن تعلمت أساسيات المراسلة غير المتزامنة في ناقل خدمة Microsoft Azure، اقرأ المزيد من التفاصيل حول التعامل مع الانقطاعات والكوارث.