نمط الكوريغرافيا (تصميم الحركات)

اللامركزية في منطق سير العمل وتوزيع المسؤوليات على المكونات الأخرى داخل النظام.

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

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

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

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

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

حل

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

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

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

1. يتم وضع طلبات العميل في قائمة الانتظار كرسائل في وسيط الرسائل.

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

3. تقوم كل خدمة مشترك بتشغيلها كما هو موضح في الرسالة وتستجيب للوسيط بنجاح أو فشل العملية.

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

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

يمكن أن تتسبب اللامركزية في المنسق في حدوث مشكلات أثناء إدارة سير العمل.

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

  للتعامل مع حالات الفشل بأمان، قد يؤدي تنفيذ المعاملات التعويضية إلى تعقيد. منطق معالجة الفشل، مثل المعاملات التعويضية، هو أيضا عرضة للفشل.

  

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

  

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

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

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

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

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

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

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

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

• هناك ازدحام في الأداء يقدمه المنسق المركزي.

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

• التطبيق معقد ويتطلب مكونا مركزيا للتعامل مع المنطق المشترك للحفاظ على مكونات انتقال البيانات من الخادم خفيفة الوزن.

• هناك حالات يكون فيها الاتصال من نقطة إلى نقطة بين المكونات أمرا حتميا.

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

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

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

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

مثال

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

هذا المثال هو إعادة بناء التعليمات البرمجية لتنفيذ تسليم الطائرات بدون طيار الذي يستبدل نمط المنسق بنمط الكوريغرافيا.

تعالج خدمة الاستيعاب طلبات العميل وتحولها إلى رسائل بما في ذلك تفاصيل التسليم. يتم بدء المعاملات التجارية بعد استهلاك تلك الرسائل الجديدة.

تتطلب معاملة عمل عميل واحدة ثلاث عمليات تجارية مميزة:

1. إنشاء حزمة أو تحديثها
2. تعيين طائرة بدون طيار لتسليم الحزمة
3. التعامل مع التسليم الذي يتكون من فحص وزيادة الوعي في نهاية المطاف عند شحنها.

تقوم ثلاث خدمات مصغرة بمعالجة الأعمال: الحزمة، وجدولة الطائرات بدون طيار، وخدمات التسليم. بدلا من المنسق المركزي، تستخدم الخدمات المراسلة للتواصل فيما بينها. ستكون كل خدمة مسؤولة عن تنفيذ بروتوكول مسبقا ينسق بطريقة لامركزية سير عمل الأعمال.

التصميم

تتم معالجة حركة الأعمال في تسلسل عبر قفزات متعددة. تشارك كل قفزة ناقل رسائل واحد بين جميع خدمات الأعمال.

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

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

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

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

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

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

خدمات الأعمال غير فعالة للتأكد من أن عمليات إعادة المحاولة لا تؤدي إلى موارد مكررة. على سبيل المثال، تستخدم خدمة الحزمة عمليات upert لإضافة البيانات إلى مخزن البيانات.

الموارد ذات الصلة

ضع في اعتبارك هذه الأنماط في تصميمك لتصميم الكوريغرافيا (تصميم الحركات).

• اجعل خدمة الأعمال نمطية باستخدام نمط تصميم السفير.

• نفِّذ نمط تسوية الحِمل المستند إلى قائمة الانتظار للتعامل مع ارتفاع أحمال العمل.

• استخدم الرسائل الموزعة غير المتزامنة من خلال نمط المشترك بين الناشر.

• استخدم المعاملات التعويضية للتراجع عن سلسلة من العمليات الناجحة في حالة فشل عملية واحدة أو أكثر ذات صلة.

• للحصول على معلومات حول استخدام وسيط الرسائل في البنية الأساسية للمراسلة، راجع خيارات المراسلة غير المتزامنة في Azure.

• الاختيار بين خدمات مراسلة Azure