تصميم تطبيق أحمال العمل الحرجة للمهام على Azure

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

هام

تعد هذه المقالة جزءا من سلسلة حمل العمل الحرجة لمهمة Azure Well-Architected Framework . إذا لم تكن على دراية بهذه السلسلة، نوصي بالبدء بما هو حمل العمل الحرج للمهمة؟.

بنية وحدة المقياس

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

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

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

مثال على وحدات المقياس

تعرض الصورة التالية النطاقات المحتملة لوحدات المقياس. تتراوح النطاقات من حجيرات الخدمات المصغرة إلى عقد نظام المجموعة وطوابع التوزيع الإقليمية.

اعتبارات التصميم

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

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

• الحمل المتوقع. استخدم عدد الطلبات لكل تدفق مستخدم، ومعدل ذروة الطلب المتوقع (الطلبات في الثانية)، وأنماط نسبة استخدام الشبكة اليومية/الأسبوعية/الموسمية للإبلاغ بمتطلبات المقياس الأساسية. عامل أيضا في أنماط النمو المتوقعة لكل من نسبة استخدام الشبكة وحجم البيانات.

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

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

توصيات التصميم

• حدد نطاق وحدة المقياس والحدود التي ستشغل الوحدة للتحجيم.

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

• حدد العلاقة بين وحدات المقياس، استنادا إلى نموذج السعة والمتطلبات غير الوظيفية.

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

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

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

• قم بقياس الوقت المطلوب للقيام بعمليات التوسيع والتوسيع للتأكد من أن الاختلافات الطبيعية في نسبة استخدام الشبكة لا تنشئ مستوى غير مقبول من تدهور الخدمة. تعقب مدد عملية المقياس كمقياس تشغيلي.

ملاحظة

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

التوزيع العالمي

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

شاهد هذا الفيديو للحصول على نظرة عامة حول كيفية التخطيط لحالات الفشل في التطبيقات الحرجة للمهام وزيادة المرونة إلى أقصى حد:

اعتبارات التصميم

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

• نموذج نشط/نشط. يوصى باستراتيجية نشر نشطة/نشطة لأنها تزيد من التوفر وتوفر اتفاقية مستوى خدمة مركبة أعلى (SLA). ومع ذلك، يمكن أن يقدم تحديات حول مزامنة البيانات واتساقها للعديد من سيناريوهات التطبيق. معالجة التحديات على مستوى النظام الأساسي للبيانات مع النظر في مفاضلات زيادة التكلفة والجهد الهندسي.

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

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

• طلب الأصل. يجب أن يكون التقارب الجغرافي وكثافة المستخدمين أو الأنظمة التابعة مستنيرا بقرارات التصميم بشأن التوزيع العالمي.

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

للحصول على توصيات التصميم وخيارات التكوين على مستوى النظام الأساسي، راجع النظام الأساسي للتطبيق: التوزيع العالمي.

بنية مستندة إلى الحدث مقترنة بشكل غير محكم

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

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

في بعض السيناريوهات، يمكن للتطبيقات الجمع بين اقتران فضفاض وضيق، اعتمادا على أهداف العمل.

اعتبارات التصميم

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

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

• التسامح مع الخطأ. يجب التعامل مع حالات الفشل بشكل منفصل ويجب ألا تؤثر على معاملات العميل.

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

• التتبع الموزع. قد يتطلب التتبع الشامل تنسيقا معقدا.

توصيات التصميم

• محاذاة حدود الخدمات المصغرة مع تدفقات المستخدم الهامة.

• استخدم الاتصال غير المتزامن المستند إلى الحدث حيثما أمكن لدعم النطاق المستدام والأداء الأمثل.

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

مثال: نهج يستند إلى الحدث

يستخدم التنفيذ المرجعي Mission-Critical Online خدمات مصغرة لمعالجة معاملة تجارية واحدة. يطبق عمليات الكتابة بشكل غير متزامن مع وسيط الرسائل والعامل. عمليات القراءة متزامنة، مع إرجاع النتيجة مباشرة إلى المتصل.

أنماط المرونة ومعالجة الأخطاء في التعليمات البرمجية للتطبيق

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

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

يمكن أن تساعدك أدوات مثل Application Insights في الاستعلام عن آثار التطبيق وربطها وتصورها.

اعتبارات التصميم

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

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

توصيات التصميم

فيما يلي بعض أنماط هندسة البرامج الشائعة للتطبيقات المرنة:

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

فيما يلي بعض التوصيات الإضافية:

• استخدم SDKs التي يوفرها المورد، مثل Azure SDKs، للاتصال بالخدمات التابعة. استخدم قدرات المرونة المضمنة بدلا من تنفيذ وظائف مخصصة.

• تطبيق استراتيجية تراجع مناسبة عند إعادة محاولة استدعاءات التبعية الفاشلة لتجنب سيناريو DDoS الذي تم إلحاقه ذاتيا.

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

• تنفيذ أنماط المرونة باستخدام حزم قياسية مثبتة، مثل Polly ل C# أو Sentinel ل Java.

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

• استخدم التسجيل المنظم لجميع رسائل السجل. حدد متلقي بيانات تشغيلي موحد لتتبعات التطبيق والمقاييس والسجلات لتمكين المشغلين من تصحيح المشكلات بسهولة. لمزيد من المعلومات، راجع جمع بيانات المراقبة وتجميعها وتخزينها للتطبيقات السحابية.

• تأكد من استخدام البيانات التشغيلية مع متطلبات العمل لإبلاغ نموذج صحة التطبيق.

تحديد لغة البرمجة

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

اعتبارات التصميم

• قدرات مجموعة أدوات التطوير. هناك اختلافات في القدرات التي تقدمها حزم SDK لخدمة Azure بلغات مختلفة. قد تؤثر هذه الاختلافات على اختيارك لخدمة Azure أو لغة البرمجة. على سبيل المثال، إذا كان Azure Cosmos DB خيارا ممكنا، فقد لا تكون Go لغة تطوير مناسبة لأنه لا يوجد SDK تابع لجهة أولى.

• تحديثات الميزات. ضع في اعتبارك عدد المرات التي يتم فيها تحديث SDK بميزات جديدة للغة المحددة. يتم تحديث SDKs شائعة الاستخدام، مثل مكتبات .NET وJava، بشكل متكرر. قد يتم تحديث SDKs أو SDKs الأخرى للغات الأخرى بشكل أقل تكرارا.

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

• خيار الحساب. قد لا يتم تشغيل البرامج القديمة أو الخاصة في خدمات PaaS. أيضا، قد لا تتمكن من تضمين برامج قديمة أو خاصة في حاويات.

توصيات التصميم

• قم بتقييم جميع Azure SDKs ذات الصلة للقدرات التي تحتاجها ولغات البرمجة التي اخترتها. تحقق من المحاذاة مع المتطلبات غير الوظيفية.

• تحسين اختيار لغات البرمجة وأطر العمل على مستوى الخدمات المصغرة. استخدم تقنيات متعددة حسب الاقتضاء.

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

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

راجع اعتبارات النظام الأساسي للتطبيق.

النظام الأساسي للتطبيق