قم بمعالجة مجموعة من الرسائل ذات الصلة بترتيب محدد، دون حظر معالجة مجموعات أخرى من الرسائل.
السياق والمشكلة
غالبًا ما تحتاج التطبيقات إلى معالجة سلسلة من الرسائل بالترتيب الذي تصل إليه، مع استمرار القدرة على التوسع للتعامل مع الحمل المتزايد. في الهندسة المعمارية الموزعة، فإن معالجة هذه الرسائل بالترتيب ليست مباشرة، لأن العمال يمكنهم التوسع بشكل مستقل وغالبًا ما يسحبون الرسائل بشكل مستقل، باستخدام نمط المستهلكين المتنافسين.
على سبيل المثال، يتلقى نظام تتبع الطلبات دفتر أستاذ يحتوي على الطلبات والعمليات ذات الصلة على تلك الطلبات. يمكن أن تتمثل هذه العمليات في إنشاء أمر أو إضافة معاملة إلى الأمر أو تعديل معاملة سابقة أو حذف أمر. في هذا النظام، يجب إجراء العمليات بطريقة الوارد أولاً يصرف أولاً (FIFO)، ولكن على مستوى الأمر فقط. ومع ذلك، تتلقى قائمة الانتظار الأولية دفتر أستاذ يحتوي على معاملات للعديد من الطلبات، والتي قد تكون متداخلة.
حل
ادفع الرسائل ذات الصلة إلى فئات داخل نظام الانتظار، واجعل مستمعي قائمة الانتظار يقفلون ويسحبون فقط من فئة واحدة، رسالة واحدة في كل مرة.
إليك ما يبدو عليه نمط القافلة التسلسلية العامة:
في قائمة الانتظار، قد تكون الرسائل الخاصة بالفئات المختلفة متداخلة، كما هو موضح في الرسم البياني التالي:
المسائل والاعتبارات
راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:
- وحدة الفئة/المقياس. ما خاصية الرسائل الواردة التي يمكنك توسيع نطاقها؟ في سيناريو تتبع الطلب، هذه الخاصية هي معرف الطلب.
- معدل النقل. ما هو معدل نقل الرسالة الهدف الخاص بك؟ إذا كانت عالية جدًا، فقد تحتاج إلى إعادة النظر في متطلبات ما يرد أولاً يصرف أولاً (FIFO). على سبيل المثال، هل يمكنك فرض رسالة البداية/النهاية، والفرز حسب الوقت، ثم إرسال دفعة للمعالجة؟
- قدرات الخدمة. هل يسمح اختيارك لناقل الرسائل بمعالجة الرسائل في وقت واحد ضمن قائمة انتظار أو فئة قائمة انتظار؟
- قابلية التطور. كيف ستضيف فئة جديدة من الرسائل إلى النظام؟ على سبيل المثال، افترض أن نظام دفتر الأستاذ الموضح أعلاه هو عميل واحد محدد. إذا كنت بحاجة إلى إعداد عميل جديد، فهل لديك مجموعة من معالجات دفتر الأستاذ التي توزع العمل حسب معرّف العميل؟
- من المحتمل أن يتلقى المستهلكون رسالة معطلة بسبب زمن انتقال الشبكة المتغير عند إرسال الرسائل. ضع في اعتبارك استخدام أرقام التسلسل للتحقق من الطلب. يمكنك أيضًا تضمين علامة خاصة "نهاية التسلسل" في الرسالة الأخيرة للمعاملة. يمكن لتقنيات معالجة الدفق مثل Spark أو Azure Stream Analytics معالجة الرسائل بالترتيب خلال نافذة زمنية.
موعد استخدام النمط
استخدم هذا النمط عندما:
- لديك رسائل تصل بالترتيب ويجب معالجتها بنفس الترتيب.
- يتم "تصنيف" الرسائل الواردة أو يمكن "تصنيفها" بحيث تصبح الفئة وحدة قياس للنظام.
قد لا يكون هذا النمط مناسبًا لـ:
- سيناريوهات الإنتاجية العالية للغاية (ملايين الرسائل/الدقيقة أو الثانية)، حيث يحد متطلب ما يرد أولاً يصرف أولاً (FIFO) القياس الذي يمكن أن يقوم به النظام.
تصميم حمل العمل
يجب على المهندس المعماري تقييم كيفية استخدام نمط القافلة التسلسلية في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:
| الركيزة | كيف يدعم هذا النمط أهداف الركيزة |
|---|---|
| تساعد قرارات تصميم الموثوقية حمل العمل الخاص بك على الصمود في وجه الخلل وضمان استرداده إلى حالة تعمل بشكل كامل بعد حدوث فشل. | يمكن لهذا النمط التخلص من حالات السباق التي يصعب استكشاف الأخطاء وإصلاحها أو معالجة الرسائل المثيرة للجدل أو الحلول البديلة الأخرى لمعالجة الرسائل التي تم ترتيبها بشكل غير صحيح والتي يمكن أن تؤدي إلى أعطال. - RE:02 التدفقات الهامة - وظائف الخلفية RE:07 |
كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.
مثال
في Azure، يمكن تنفيذ هذا النمط باستخدام جلسات رسائل ناقل خدمة Azure. بالنسبة للمستهلكين، يمكنك استخدام إما Logic Apps مع موصل تأمين التحرير سريعًا لناقل الخدمة أو Azure Functions مع مشغل ناقل الخدمة.
بالنسبة لمثال تتبع الطلب السابق، قم بمعالجة كل رسالة من رسائل دفتر الأستاذ بالترتيب الذي تم استلامه، وأرسل كل معاملة إلى قائمة انتظار أخرى حيث يتم تعيين الفئة على معرّف الطلب. لن تمتد المعاملة مطلقًا إلى طلبات متعددة في هذا السيناريو، لذلك يقوم المستهلكون بمعالجة كل فئة بشكل متوازٍ ولكن ما يرد أولاً يصرف أولاً ضمن الفئة.
يقوم معالج الحافة بإخراج الرسائل عن طريق إلغاء تجميع محتوى كل رسالة في قائمة الانتظار الأولى:
يعتني معالج دفتر الأستاذ بما يلي:
- التقدم في دفتر الأستاذ بمعدل معاملة واحدة في كل مرة.
- تعيين معرف الجلسة للرسالة لمطابقة معرف الطلب.
- إرسال كل معاملة دفتر الأستاذ إلى قائمة انتظار ثانوية مع تعيين معرف الجلسة على معرف الطلب.
يستمع المستهلكون إلى قائمة الانتظار الثانوية حيث يعالجون جميع الرسائل بمعرفات الطلبات المطابقة بالترتيب من قائمة الانتظار. يستخدم المستهلكون وضع تأمين التحرير سريعًا.
عند التفكير في قابلية التوسع، فإن قائمة انتظار دفتر الأستاذ هي عنق الزجاجة الأساسي. يمكن أن تشير المعاملات المختلفة التي تم ترحيلها إلى دفتر الأستاذ إلى نفس معرف الطلب. ومع ذلك، يمكن أن تنتشر الرسائل بعد دفتر الأستاذ لعدد الطلبات في بيئة بلا خادم.
الخطوات التالية
قد تكون المعلومات التالية ذات صلة عند تنفيذ هذا النمط: