توضح هذه المقالة كيفية نشر تطبيقات الويب ذات المهام الحرجة باستخدام Azure App Service. تستخدم البنية نمط تطبيق الويب الموثوق به كنقطة بداية. استخدم هذه البنية إذا كان لديك حمل عمل قديم وتريد اعتماد خدمات النظام الأساسي كخدمة (PaaS).
يوفر نمط تطبيق الويب الموثوق به ل .NET إرشادات لتحديث تطبيقات الويب التي تنتقل إليها إلى السحابة أو إعادة تنسيقها، وتقليل تغييرات التعليمات البرمجية المطلوبة، واستهداف هدف مستوى الخدمة (SLO) بنسبة 99.9٪. أحمال العمل الحرجة للمهام لها متطلبات عالية من الموثوقية والتوافر. للوصول إلى SLO بنسبة 99.95٪، أو 99.99٪، أو أعلى، تحتاج إلى تطبيق أنماط تصميم المهام الحرجة التكميلية والدقة التشغيلية. توضح هذه المقالة المجالات التقنية الرئيسية وكيفية تنفيذ ممارسات التصميم الحرجة للمهام وإدخالها.
إشعار
تستند الإرشادات الواردة في هذه المقالة إلى منهجية التصميم وأفضل الممارسات في سلسلة حمل العمل الحرجة لإطار العمل المصمم جيدا.
تصف الأقسام التالية كيفية:
- راجع حمل العمل الحالي لفهم مكوناته وتدفقات المستخدم والنظام ومتطلبات التوفر وقابلية التوسع.
- تطوير وتنفيذ بنية وحدة التحجيم لتحسين قابلية التوسع من طرف إلى طرف من خلال التجزئة وتوحيد عملية إضافة السعة وإزالتها.
- تنفيذ وحدات المقياس عديمة الحالة والزائلة أو طوابع التوزيع لتمكين قابلية التوسع وتوزيع وقت التعطل الصفري.
- حدد ما إذا كان يمكنك تقسيم حمل العمل إلى مكونات للتحضير لقابلية التوسع. المكونات الفردية مطلوبة لتدفقات قابلية التوسع وفصلها.
- استعد للتوزيع العالمي من خلال نشر حمل عمل عبر أكثر من منطقة Azure واحدة لتحسين القرب من العميل والاستعداد للانقطاعات الإقليمية المحتملة.
- فصل المكونات وتنفيذ بنية تستند إلى الحدث.
بناء الأنظمة
يطبق الرسم التخطيطي التالي الاعتبارات السابقة على نمط تطبيق الويب الموثوق به.
قم بتنزيل ملف Visio لهذه البنية.
يمثل المربع الأحمر وحدة مقياس مع خدمات تتوسع معا. لتوسيع نطاقها معا بشكل فعال، قم بتحسين حجم كل خدمة وSKU وعناوين IP المتوفرة. على سبيل المثال، يرتبط الحد الأقصى لعدد الطلبات التي يقدمها Azure App Configuration بعدد الطلبات في الثانية التي توفرها وحدة المقياس. عند إضافة المزيد من السعة في منطقة، يجب أيضا إضافة المزيد من وحدات المقياس الفردية.
لا تحتوي وحدات المقياس الفردية هذه على أي تبعيات مشتركة وتتواصل فقط مع الخدمات المشتركة خارج وحدة المقياس الفردية. يمكنك اختبار وحدات مقياس مستقلة مقدما. لتجنب التأثير على مجالات التوزيع الأخرى، قم بطرح وحدات مقياس مستقلة وأدخل خيار استبدال الخدمات في إصدار جديد.
بالنسبة لأحمال العمل ذات المهام الحرجة، تكون وحدات المقياس المستقلة مؤقتة، ما يحسن عمليات الإطلاق ويوفر قابلية التوسع داخل المناطق وعبرها. تجنب تخزين الحالة في وحدات مقياس مستقلة. ضع في اعتبارك استخدام Azure Cache for Redis للتخزين في وحدة المقياس، والتخزين فقط للحالة أو البيانات الهامة المخزنة أيضا في قاعدة البيانات. إذا كان هناك انقطاع في وحدة المقياس أو قمت بالتبديل إلى وحدة مقياس أخرى، فقد يكون هناك تباطؤ أو تسجيل دخول جديد مطلوب، ولكن لا يزال يتم تشغيل Azure Cache for Redis.
يتم استبعاد Application Insights من وحدة المقياس. استبعاد الخدمات التي تخزن البيانات أو تراقبها. افصلها إلى مجموعة الموارد الخاصة بها مع دورة حياتها الخاصة.
عند استبدال وحدة مقياس أو نشر وحدة جديدة، احتفظ بالبيانات التاريخية واستخدم مثيلا واحدا لكل منطقة.
لمزيد من المعلومات، راجع تصميم التطبيق لأحمال العمل الحرجة للمهام على Azure.
المكونات
تستخدم هذه البنية المكونات التالية.
- App Service هي النظام الأساسي لاستضافة التطبيقات.
- ذاكرة التخزين المؤقت Azure لطلبات التخزين المؤقت ل Redis .
- يخزن App Configuration إعدادات التكوين.
- Azure SQL هي قاعدة البيانات الخلفية.
- يحصل Application Insights على بيانات تتبع الاستخدام من التطبيق.
البدائل
في نمط تطبيق الويب الموثوق به، يمكنك:
- استخدم خدمة Azure Kubernetes (AKS) بدلا من خدمة التطبيقات. يعمل هذا الخيار بشكل جيد مع أحمال العمل المعقدة التي تحتوي على عدد كبير من الخدمات المصغرة. توفر AKS مزيدا من التحكم في البنية الأساسية وتسمح بالإعدادات المعقدة متعددة التلميحات.
- تعبئة حمل العمل في حاويات. تدعم App Service التعبئة في حاويات، ولكن في هذا المثال لا يتم تعبئة حمل العمل في حاويات. استخدم الحاويات لزيادة الموثوقية وقابلية النقل.
لمزيد من المعلومات، راجع اعتبارات النظام الأساسي للتطبيق لأحمال العمل ذات المهام الحرجة على Azure.
اختر النظام الأساسي للتطبيق
يعتمد مستوى التوفر على اختيارك وتكوين النظام الأساسي للتطبيق. ضع في اعتبارك التوجيهات المهمة التالية:
- استخدم مناطق التوفر عندما يكون ذلك ممكنا.
- حدد خدمة النظام الأساسي المناسبة لحمل العمل الخاص بك.
- تعبئة حمل العمل في حاويات.
تنشر مجموعات التوفر عمليات النشر عبر مجالات خطأ وتحديث متعددة داخل مركز بيانات. تنتشر مناطق التوفر عمليات النشر عبر مراكز البيانات الفردية داخل منطقة Azure. غالبا ما يتم إعطاء الأولوية لمناطق التوفر، ولكن الاستراتيجية التي تستخدمها تعتمد على حمل العمل الخاص بك. على سبيل المثال، قد تستفيد أحمال العمل الحساسة لزمن الانتقال أو الدردشة من تحديد أولويات مجموعات التوفر. إذا قمت بنشر حمل العمل عبر مناطق التوفر، فإنه يمكن أن يزيد من زمن الانتقال والتكلفة لنسبة استخدام الشبكة عبر المناطق. عند استخدام مناطق التوفر، تأكد من أن جميع الخدمات في وحدة المقياس تدعمها. تدعم جميع الخدمات في نمط تطبيق الويب الموثوق به مناطق التوفر.
اختر النظام الأساسي للبيانات
يؤثر النظام الأساسي لقاعدة البيانات الذي تختاره على بنية حمل العمل الإجمالية، خاصة دعم التكوين النشط-النشط أو النشط-السلبي للنظام الأساسي. يستخدم نمط تطبيق الويب الموثوق به Azure SQL، والذي لا يدعم في الأصل عمليات النشر النشطة-النشطة مع عمليات الكتابة في أكثر من مثيل واحد. لذلك يقتصر مستوى قاعدة البيانات على استراتيجية نشطة-سلبية. استراتيجية نشطة-نشطة على مستوى التطبيق ممكنة إذا كانت هناك نسخ متماثلة للقراءة فقط وكنت تكتب إلى منطقة واحدة فقط.
قم بتنزيل ملف Visio لهذه البنية.
قواعد البيانات المتعددة شائعة في البنيات المعقدة، مثل بنى الخدمات المصغرة التي تحتوي على قاعدة بيانات لكل خدمة. تسمح قواعد البيانات المتعددة باعتماد قاعدة بيانات كتابة متعددة الأساسيات مثل Azure Cosmos DB، ما يحسن التوفر العالي وزمن الانتقال المنخفض. يمكن أن يؤدي زمن الانتقال عبر المناطق إلى إنشاء قيود. من الضروري مراعاة المتطلبات والعوامل غير الوظيفية مثل التناسق وقابلية التشغيل والتكلفة والتعقيد. تمكين الخدمات الفردية من استخدام مخازن بيانات منفصلة وتقنيات بيانات متخصصة لتلبية متطلباتها الفريدة. لمزيد من المعلومات، راجع اعتبارات النظام الأساسي للبيانات لأحمال العمل ذات المهام الحرجة على Azure.
تعريف نموذج صحي
في أحمال العمل المعقدة متعددة المستويات التي تنتشر عبر مراكز بيانات متعددة ومناطق جغرافية، يجب عليك تحديد نموذج صحي. تحديد تدفقات المستخدم والنظام، وتحديد وفهم التبعيات بين الخدمات، وفهم التأثير الذي يمكن أن يحدثه الانقطاع أو تدهور الأداء على إحدى الخدمات على حمل العمل الكلي، ومراقبة تجربة العملاء وتصورها لتمكين المراقبة السليمة وتحسين الإجراءات اليدوية والآلية.
يوضح الرسم التخطيطي السابق كيف يمكن أن يتسبب انقطاع أو تدهور مكون واحد، مثل تكوين التطبيق، في تدهور الأداء المحتمل للعميل.
عند فصل المكونات إلى وحدات مقياس، فإنه يسمح لك بالتوقف عن إرسال نسبة استخدام الشبكة إلى الجزء المتأثر من التطبيق، مثل وحدة المقياس المتأثرة أو المنطقة الكاملة.
لمزيد من المعلومات، راجع نمذجة السلامة وإمكانية مراقبة أحمال العمل ذات المهام الحرجة على Azure.
الأمان والشبكات
هناك متطلبات صارمة للشبكات والأمان لأحمال العمل التي ترحل من نشر مؤسسة محلية. لا تترجم جميع العمليات المحلية المنشأة إلى بيئة سحابية. قم بتقييم هذه المتطلبات إذا كانت قابلة للتطبيق في بيئات السحابة.
غالبا ما تكون الهوية هي محيط الأمان الأساسي للأنماط الأصلية للسحابة. قد يحتاج عملاء المؤسسات إلى إجراءات أمنية أكثر جوهرية. لتلبية متطلبات أمان الشبكة الخاصة بهم، يمكن لمعظم خدمات Azure PaaS استخدام Azure Private Link لتنفيذ الشبكة كمحيط أمان. يمكن أن يضمن Private Link إمكانية الوصول إلى الخدمات فقط من داخل شبكة ظاهرية. يمكن الوصول إلى جميع الخدمات عبر نقاط النهاية الخاصة فقط. يوضح الرسم التخطيطي التالي كيف أن نقطة النهاية العامة الوحيدة التي تواجه الإنترنت هي Azure Front Door.
قم بتنزيل ملف Visio لهذه البنية.
لكي يقوم نمط تطبيق الويب الموثوق به بإعداد شبكة كمحيط أمان، يجب أن يستخدم:
- رابط خاص لجميع الخدمات التي تدعمه.
- Azure Front Door premium كنقطة النهاية العامة الوحيدة التي تواجه الإنترنت.
- Jumpboxes للوصول إلى الخدمات عبر Azure Bastion.
- عوامل البناء المستضافة ذاتيا التي يمكنها الوصول إلى الخدمات.
من متطلبات الشبكة الشائعة الأخرى للتطبيقات ذات المهام الحرجة تقييد نسبة استخدام الشبكة الخارجة لمنع تسرب البيانات. تقييد حركة الخروج عن طريق توجيه جدار حماية Azure من خلال جهاز جدار حماية مناسب وتصفيته باستخدام الجهاز. تستخدم بنية الأساس المهمة في Azure مع عناصر التحكم في الشبكة جدار حماية وارتباط خاص.
النشر والاختبار
يمكن أن يكون وقت التعطل الناجم عن الإصدارات الخاطئة أو الخطأ البشري مشكلة لحمل العمل الذي يجب أن يكون متاحا دائما. فيما يلي بعض المجالات الرئيسية التي يجب مراعاتها:
- عمليات نشر وقت التعطل الصفري
- عمليات نشر سريعة الزوال باللون الأزرق/الأخضر
- تحليل دورة حياة المكونات الفردية وتجميعها معا
- التحقق المستمر
تعد عمليات النشر بدون تعطل مفتاحا لأحمال العمل ذات المهام الحرجة. لا يمكن أن يحتوي حمل العمل الذي يجب أن يكون قيد التشغيل دائما على نافذة صيانة لنشر إصدارات أحدث. للتغلب على هذا القيد، تتبع البنية الحرجة لمهمة Azure نمط عمليات النشر بدون توقف. يتم طرح التغييرات كوحدات مقياس جديدة أو طوابع يتم اختبارها من طرف إلى طرف قبل توجيه نسبة استخدام الشبكة إليها بشكل متزايد. بعد توجيه كل حركة المرور إلى الطابع الجديد، يتم تعطيل الطوابع القديمة وإزالتها.
لمزيد من المعلومات، راجع النشر والاختبار لأحمال العمل ذات المهام الحرجة على Azure.
الخطوات التالية
- مسار التعلم: إنشاء أحمال العمل الحرجة للمهمة على Azure
- مشروع التحدي: تصميم تطبيق ويب مهم للمهمة
- وحدة التعلم: تصميم نموذج صحي لحمل العمل الحرج للمهمة