نمط Web App موثوق به ل .NET

توفر هذه المقالة إرشادات حول تنفيذ نمط Reliable Web App. يوضح هذا النمط كيفية تعديل تطبيقات الويب (replatform) لترحيل السحابة. وهو يوفر تصميما إلزاميا، ورمزا، وإرشادات تكوين تتماشى مع مبادئ إطار العمل المصمم جيدا.

لماذا نمط Reliable Web App ل .NET؟

نمط Reliable Web App هو مجموعة من المبادئ وتقنيات التنفيذ التي تحدد كيفية تكرار تطبيقات الويب عند الترحيل إلى السحابة. وهو يركز على الحد الأدنى من تحديثات التعليمات البرمجية التي تحتاج إلى إجراءها لتكون ناجحا في السحابة. تستخدم الإرشادات التالية التنفيذ المرجعي كمثال خلال الرحلة المتكررة للشركة الخيالية Relecloud لتوفير سياق عمل لرحلتك. قبل تنفيذ نمط Reliable Web App ل .NET، كان لدى Relecloud تطبيق ويب لتذاكر محلية متجانس يستخدم إطار عمل ASP.NET.

كيفية تنفيذ نمط Reliable Web App

تتضمن هذه المقالة إرشادات البنية والرمز والتكوين لتنفيذ نمط Reliable Web App. استخدم الارتباطات التالية للانتقال إلى الإرشادات المحددة التي تحتاج إليها:

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

سياق العمل

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

على سبيل المثال، لدى Relecloud توقعات مبيعات إيجابية وتتوقع زيادة الطلب على تطبيق الويب الخاص ببطاقاتهم. لتلبية هذا الطلب، حددوا أهداف تطبيق الويب:

• تطبيق تغييرات التعليمات البرمجية منخفضة التكلفة وعالية القيمة
• الوصول إلى هدف مستوى الخدمة (SLO) بنسبة 99.9٪
• اعتماد ممارسات DevOps
• إنشاء بيئات محسنة للتكلفة
• تحسين الموثوقية والأمان

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

إرشادات البنية

يحتوي نمط Reliable Web App على بعض العناصر المعمارية الأساسية. تحتاج إلى DNS لإدارة دقة نقطة النهاية وجدار حماية تطبيق ويب لمنع حركة مرور HTTP الضارة وموازن تحميل لحماية طلبات المستخدم الواردة وتوجيهها. يستضيف النظام الأساسي للتطبيق التعليمات البرمجية لتطبيق الويب الخاص بك ويستدعي جميع خدمات الواجهة الخلفية من خلال نقاط النهاية الخاصة في شبكة ظاهرية. تلتقط أداة مراقبة أداء التطبيق المقاييس والسجلات لفهم تطبيق الويب الخاص بك.

الشكل 1. العناصر المعمارية الأساسية لنمط Reliable Web App.

تصميم البنية

تصميم البنية الأساسية لدعم مقاييس الاسترداد، مثل هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO). يؤثر RTO على التوفر ويجب أن يدعم SLO الخاص بك. حدد هدف نقطة الاسترداد (RPO) وقم بتكوين تكرار البيانات لتلبية هدف نقطة الاسترداد.

• اختر موثوقية البنية الأساسية. حدد عدد مناطق التوفر والمناطق التي تحتاج إليها لتلبية احتياجات التوفر الخاصة بك. أضف مناطق التوفر والمناطق حتى تفي اتفاقية مستوى الخدمة المركبة ب SLO الخاص بك. يدعم نمط Reliable Web App مناطق متعددة لتكوين نشط-نشط أو نشط-سلبي. على سبيل المثال، يستخدم التنفيذ المرجعي تكوين نشط-سلبي لتلبية SLO بنسبة 99.9٪.

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

  

  الشكل 2. نمط Reliable Web App مع منطقة ثانية وطوبولوجيا محورية.

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

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

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

على سبيل المثال، قبل الانتقال إلى السحابة، كان تطبيق الويب الخاص بتذاكر Relecloud تطبيقا محليا ومتجانسا ASP.NET. تم تشغيله على جهازين ظاهريين وكان لديه قاعدة بيانات Microsoft SQL Server. عانى تطبيق الويب من التحديات الشائعة في قابلية التوسع ونشر الميزات. قادت نقطة البداية هذه وأهداف أعمالهم وSLO خيارات الخدمة الخاصة بهم.

• النظام الأساسي للتطبيق: استخدم Azure App Service كمنصة تطبيقك. اختار Relecloud Azure App Service كمنصة تطبيق للأسباب التالية:

  • اتفاقية مستوى الخدمة العالية (SLA): لديها اتفاقية مستوى خدمة عالية تفي ببيئة الإنتاج SLO بنسبة 99.9٪.
  • تقليل الحمل الإداري: إنه حل مدار بالكامل يعالج التحجيم والفحوصات الصحية وموازنة التحميل.
  • دعم .NET: يدعم إصدار .NET الذي تتم كتابة التطبيق فيه.
  • إمكانية التعبئة في حاويات: يمكن أن يتقارب تطبيق الويب على السحابة دون التعبئة في حاويات، ولكن النظام الأساسي للتطبيق يدعم أيضا التعبئة في حاويات دون تغيير خدمات Azure.
  • التحجيم التلقائي: يمكن لتطبيق الويب توسيع نطاق الدخول والخروج تلقائيا استنادا إلى حركة مرور المستخدم وإعدادات التكوين. كما يدعم النظام الأساسي التحجيم لأعلى أو لأسفل لاستيعاب متطلبات الاستضافة المختلفة.

• إدارة الهوية: استخدم معرف Microsoft Entra كحل لإدارة الهوية والوصول. اختار Relecloud معرف Microsoft Entra للأسباب التالية:

  • المصادقة والتخويل: يحتاج التطبيق إلى مصادقة وتخويل موظفي مركز الاتصال.
  • قابل للتطوير: يتوسع لدعم سيناريوهات أكبر.
  • التحكم في هوية المستخدم: يمكن لموظفي مركز الاتصال استخدام هويات المؤسسة الموجودة لديهم.
  • دعم بروتوكول التخويل: يدعم OAuth 2.0 للهويات المدارة.

• قاعدة البيانات: استخدم خدمة تسمح لك بالاحتفاظ بنفس محرك قاعدة البيانات. استخدم شجرة قرارات مخزن البيانات. استخدم تطبيق الويب الخاص ب Relecloud SQL Server محليا. لذلك أرادوا استخدام مخطط قاعدة البيانات الموجودة والإجراءات المخزنة والوظائف. تتوفر العديد من منتجات SQL على Azure، ولكن Relecloud اختار Azure SQL Database للأسباب التالية:

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

• مراقبة أداء التطبيق: استخدم Application Insights لتحليل القياس عن بعد على التطبيق الخاص بك. اختار Relecloud استخدام Application Insights للأسباب التالية:

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

• ذاكرة التخزين المؤقت: اختر ما إذا كنت تريد إضافة ذاكرة التخزين المؤقت إلى بنية تطبيق الويب الخاص بك. Azure Cache for Redis هو حل ذاكرة التخزين المؤقت الأساسي ل Azure. إنه مخزن بيانات مدار في الذاكرة استنادا إلى برنامج Redis. يتم انحراف تحميل تطبيق الويب الخاص ب Relecloud بشكل كبير نحو عرض الحفلات الموسيقية وتفاصيل المكان، وأضاف Azure Cache ل Redis للأسباب التالية:

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

• موازن التحميل: يجب أن تستخدم تطبيقات الويب التي تستخدم حلول PaaS Azure Front Door أو Azure Application Gateway أو كليهما استنادا إلى بنية تطبيق الويب ومتطلباته. استخدم شجرة قرار موازن التحميل لاختيار موازن التحميل الصحيح. احتاج Relecloud إلى موازن تحميل من الطبقة 7 يمكنه توجيه نسبة استخدام الشبكة عبر مناطق متعددة. احتاج Relecloud إلى تطبيق ويب متعدد المناطق لتلبية SLO بنسبة 99.9٪. اختار Relecloud Azure Front Door للأسباب التالية:

  • موازنة التحميل العمومية: إنه موازن تحميل من الطبقة 7 يمكنه توجيه نسبة استخدام الشبكة عبر مناطق متعددة.
  • جدار حماية تطبيق الويب: يتكامل أصلا مع Azure Web Application Firewall.
  • مرونة التوجيه: يسمح لفريق التطبيق بتكوين احتياجات الدخول لدعم التغييرات المستقبلية في التطبيق.
  • تسريع حركة المرور: يستخدم anycast للوصول إلى أقرب نقطة حضور Azure والعثور على أسرع مسار إلى تطبيق الويب.
  • المجالات المخصصة: يدعم أسماء المجالات المخصصة مع التحقق من صحة المجال المرن.
  • فحوصات السلامة: يحتاج التطبيق إلى مراقبة ذكية لفحص الصحة. يستخدم Azure Front Door استجابات من التحقيق لتحديد أفضل أصل لتوجيه طلبات العميل.
  • دعم المراقبة: يدعم التقارير المضمنة مع لوحة معلومات الكل في واحد لكل من Front Door وأنماط الأمان. يمكنك تكوين التنبيهات التي تتكامل مع Azure Monitor. يتيح للتطبيق تسجيل كل طلب وفحوصات السلامة الفاشلة.
  • حماية DDoS: تحتوي على حماية DDoS من الطبقة 3-4 المضمنة.
  • شبكة تسليم المحتوى: تقوم بوضع Relecloud لاستخدام شبكة تسليم المحتوى. توفر شبكة تسليم المحتوى تسريع الموقع.

• جدار حماية تطبيق الويب: استخدم Azure Web Application Firewall لتوفير حماية مركزية من عمليات استغلال الويب الشائعة ونقاط الضعف. استخدم Relecloud Azure Web Application Firewall للأسباب التالية:

  • الحماية العالمية: توفر حماية محسنة لتطبيق الويب العالمي دون التضحية بالأداء.
  • حماية Botnet: يمكن للفريق مراقبة الإعدادات وتكوينها لمعالجة المخاوف الأمنية المتعلقة بشبكات الروبوت.
  • التماثل مع الموقع المحلي: كان الحل المحلي يعمل خلف جدار حماية تطبيق ويب تديره تكنولوجيا المعلومات.
  • سهولة الاستخدام: يتكامل Web Application Firewall مع Azure Front Door.

• تخزين التكوين: اختر ما إذا كنت تريد إضافة تخزين تكوين التطبيق إلى تطبيق الويب الخاص بك. Azure App Configuration هي خدمة لإدارة إعدادات التطبيق وعلامات الميزات مركزيا. راجع أفضل ممارسات تكوين التطبيق لتحديد ما إذا كانت هذه الخدمة مناسبة لتطبيقك. أراد Relecloud استبدال التكوين المستند إلى الملف بمخزن تكوين مركزي يتكامل مع النظام الأساسي للتطبيق والرمز. لقد أضافوا App Configuration إلى البنية للأسباب التالية:

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

• مدير الأسرار: استخدم Azure Key Vault إذا كانت لديك أسرار لإدارتها في Azure. يمكنك دمج Key Vault في تطبيقات .NET باستخدام كائن ConfigurationBuilder. يقوم تطبيق الويب المحلي من Relecloud بتخزين الأسرار في ملفات تكوين التعليمات البرمجية، ولكن من أفضل ممارسات الأمان تخزين الأسرار في موقع يدعم التحكم في الوصول استنادا إلى الدور وعناصر التحكم في التدقيق. في حين أن الهويات المدارة هي الحل المفضل للاتصال بموارد Azure، فإن Relecloud لديها أسرار التطبيق التي تحتاج إلى إدارتها. استخدمت Relecloud Key Vault للأسباب التالية:

  • التشفير: يدعم التشفير في حالة الثبات وفي أثناء النقل.
  • دعم الهوية المدارة: يمكن لخدمات التطبيق استخدام الهويات المدارة للوصول إلى المخزن السري.
  • المراقبة والتسجيل: يسهل الوصول إلى التدقيق وينشئ تنبيهات عند تغيير الأسرار المخزنة.
  • التكامل: يوفر التكامل الأصلي مع مخزن تكوين Azure (تكوين التطبيق) والنظام الأساسي لاستضافة الويب (App Service).

• حل التخزين: راجع خيارات تخزين Azure لاختيار حل التخزين الصحيح بناء على متطلباتك. يحتوي تطبيق الويب المحلي الخاص ب Relecloud على تخزين قرص مثبت على كل خادم ويب، ولكن الفريق أراد استخدام حل تخزين بيانات خارجي. اختار Relecloud Azure Blob Storage للأسباب التالية:

  • الوصول الآمن: يمكن لتطبيق الويب التخلص من نقاط النهاية للوصول إلى التخزين المكشوف للإنترنت العام مع وصول مجهول.
  • التشفير: يقوم بتشفير البيانات الثابتة والمتنقلة.
  • المرونة: يدعم التخزين المتكرر في المنطقة (ZRS). ينسخ التخزين المتكرر في المنطقة البيانات بشكل متزامن عبر ثلاث مناطق توفر Azure في المنطقة الأساسية. توجد كل منطقة توفر في موقع فعلي منفصل يحتوي على طاقة وتبريد وشبكة مستقلة. يجب أن يجعل هذا التكوين صور إصدار التذاكر مرنة ضد الخسارة.

• أمان نقطة النهاية: استخدم Azure Private Link للوصول إلى حلول النظام الأساسي كخدمة عبر نقطة نهاية خاصة في شبكتك الظاهرية. تنتقل نسبة استخدام الشبكة بين شبكتك الظاهرية والخدمة عبر شبكة Microsoft الأساسية. اختار Relecloud Private Link للأسباب التالية:

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

• أمان الشبكة: استخدم Azure Firewall للتحكم في نسبة استخدام الشبكة الواردة والصادرة على مستوى الشبكة. استخدم Azure Bastion للاتصال بالأجهزة الظاهرية بشكل آمن دون الكشف عن منافذ RDP/SSH. اعتمدت Relecloud طوبولوجيا الشبكة المحورية وأرادت وضع خدمات أمان الشبكة المشتركة في المركز. يحسن جدار حماية Azure الأمان عن طريق فحص جميع نسبة استخدام الشبكة الصادرة من المحاور لزيادة أمان الشبكة. احتاج Relecloud إلى Azure Bastion لعمليات النشر الآمنة من مضيف الانتقال السريع في الشبكة الفرعية DevOps.

إرشادات التعليمات البرمجية

لنقل تطبيق ويب بنجاح إلى السحابة، تحتاج إلى تحديث التعليمات البرمجية لتطبيق الويب الخاص بك بنمط إعادة المحاولة ونمط قاطع الدائرة ونمط تصميم Cache-Aside.

الشكل 3. دور أنماط التصميم.

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

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

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

3. نمط Cache-Aside: يضيف نمط Cache-Aside إلى ذاكرة التخزين المؤقت ويستردها بشكل متكرر أكثر من مخزن البيانات. تنفيذ هذا النمط على الطلبات إلى قاعدة البيانات.

تنفيذ نمط إعادة المحاولة

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

• استخدم آليات إعادة المحاولة المضمنة استخدم آلية إعادة المحاولة المضمنة التي يجب على معظم خدمات Azure تسريع التنفيذ. على سبيل المثال، يستخدم التنفيذ المرجعي مرونة الاتصال في Entity Framework Core لتطبيق نمط إعادة المحاولة في الطلبات على قاعدة بيانات Azure SQL (راجع التعليمات البرمجية التالية).

  services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
      sqlServerOptionsAction: sqlOptions =>
      {
          sqlOptions.EnableRetryOnFailure(
          maxRetryCount: 5,
          maxRetryDelay: TimeSpan.FromSeconds(3),
          errorNumbersToAdd: null);
      }));
  

• استخدم مكتبات برمجة إعادة المحاولة. لاتصالات HTTP، قم بدمج مكتبة مرونة قياسية مثل Polly أو Microsoft.Extensions.Http.Resilience. توفر هذه المكتبات آليات شاملة لإعادة المحاولة بالغة الأهمية لإدارة الاتصالات مع خدمات الويب الخارجية. على سبيل المثال، يستخدم التنفيذ المرجعي Polly لفرض نمط إعادة المحاولة في كل مرة تقوم فيها التعليمات البرمجية بإنشاء كائن يستدعي IConcertSearchService الكائن (راجع التعليمات البرمجية التالية).

  private void AddConcertSearchService(IServiceCollection services)
  {
      var baseUri = Configuration["App:RelecloudApi:BaseUri"];
      if (string.IsNullOrWhiteSpace(baseUri))
      {
          services.AddScoped<IConcertSearchService, MockConcertSearchService>();
      }
      else
      {
          services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
          {
              httpClient.BaseAddress = new Uri(baseUri);
              httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
              httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
          })
          .AddPolicyHandler(GetRetryPolicy())
          .AddPolicyHandler(GetCircuitBreakerPolicy());
      }
  }
  
  private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
  {
      var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
      return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .WaitAndRetryAsync(delay);
  }
  

تنفيذ نمط قاطع الدائرة

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

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

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

تنفيذ نمط Cache-Aside

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

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

  private void AddAzureCacheForRedis(IServiceCollection services)
  {
      if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
      {
          services.AddStackExchangeRedisCache(options =>
          {
              options.Configuration = Configuration["App:RedisCache:ConnectionString"];
          });
      }
      else
      {
          services.AddDistributedMemoryCache();
      }
  }
  

• تخزين البيانات عالية الحاجة مؤقتا. تطبيق نمط Cache-Aside على البيانات ذات الحاجة العالية لتضخيم فعاليتها. استخدم Azure Monitor لتعقب وحدة المعالجة المركزية والذاكرة وتخزين قاعدة البيانات. تساعدك هذه المقاييس على تحديد ما إذا كان يمكنك استخدام SKU قاعدة بيانات أصغر بعد تطبيق نمط Cache-Aside. على سبيل المثال، يقوم التنفيذ المرجعي بتخزين البيانات عالية الحاجة التي تدعم صفحة الحفلات القادمة. يسحب GetUpcomingConcertsAsync الأسلوب البيانات إلى ذاكرة التخزين المؤقت Redis من قاعدة بيانات SQL ويملأ ذاكرة التخزين المؤقت بأحدث بيانات الحفلات (راجع التعليمات البرمجية التالية).

  public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
  {
      IList<Concert>? concerts;
      var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
      if (concertsJson != null)
      {
          // There is cached data. Deserialize the JSON data.
          concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
      }
      else
      {
          // There's nothing in the cache. Retrieve data 
          // from the repository and cache it for one hour.
          concerts = await this.database.Concerts.AsNoTracking()
              .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
              .OrderBy(c => c.StartTime)
              .Take(count)
              .ToListAsync();
          concertsJson = JsonSerializer.Serialize(concerts);
          var cacheOptions = new DistributedCacheEntryOptions {
              AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
          };
          await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
      }
      return concerts ?? new List<Concert>();
  }
  

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

  public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
  {
      database.Add(newConcert);
      await this.database.SaveChangesAsync();
      this.cache.Remove(CacheKeys.UpcomingConcerts);
      return CreateResult.SuccessResult(newConcert.Id);
  }
  

• تأكد من تناسق البيانات. تنفيذ آليات لتحديث ذاكرة التخزين المؤقت مباشرة بعد أي عملية كتابة قاعدة بيانات. استخدم التحديثات المستندة إلى الحدث أو فئات إدارة البيانات المخصصة لضمان اتساق ذاكرة التخزين المؤقت. تعد مزامنة ذاكرة التخزين المؤقت باستمرار مع تعديلات قاعدة البيانات أمرا أساسيا لنمط Cache-Aside. على سبيل المثال، يستخدم التنفيذ المرجعي UpdateConcertAsync الأسلوب للحفاظ على تناسق البيانات في ذاكرة التخزين المؤقت (راجع التعليمات البرمجية التالية).

  public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
  {
     database.Update(existingConcert);
     await database.SaveChangesAsync();
     this.cache.Remove(CacheKeys.UpcomingConcerts);
     return UpdateResult.SuccessResult();
  }
  

إرشادات التكوين

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

تكوين مصادقة المستخدم وتخويله

عند ترحيل تطبيقات الويب إلى Azure، قم بتكوين آليات مصادقة المستخدم والتخويل. اتبع هذه التوصيات:

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

• أنشئ تسجيل تطبيق يتطلب معرف Microsoft Entra تسجيل تطبيق في المستأجر الأساسي. يضمن تسجيل التطبيق أن المستخدمين الذين يمكنهم الوصول إلى تطبيق الويب لديهم هويات في المستأجر الأساسي.

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

• فرض التخويل في التطبيق. استخدم عناصر التحكم في الوصول المستندة إلى الدور (RBAC) لتعيين أقل الامتيازات لأدوار التطبيق. حدد أدوارا محددة لإجراءات المستخدم المختلفة لتجنب التداخل وضمان الوضوح. تعيين المستخدمين إلى الأدوار المناسبة والتأكد من أن لديهم حق الوصول فقط إلى الموارد والإجراءات الضرورية.

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

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

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

تنفيذ الهويات المدارة

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

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

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

• تأمين الأسرار المتبقية. تخزين أي أسرار متبقية في Azure Key Vault. تحميل البيانات السرية من Key Vault عند بدء تشغيل التطبيق بدلا من أثناء كل طلب HTTP. يمكن أن يتجاوز الوصول عالي التردد داخل طلبات HTTP حدود معاملات Key Vault. تخزين تكوينات التطبيق في Azure App Configuration.

على سبيل المثال، يستخدم التنفيذ المرجعي الوسيطة Authentication في قاعدة بيانات SQL سلسلة الاتصال بحيث يمكن ل App Service الاتصال بقاعدة بيانات SQL بهوية مدارة: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. ويستخدم DefaultAzureCredential للسماح لواجهة برمجة تطبيقات الويب بالاتصال ب Key Vault باستخدام هوية مدارة (راجع التعليمات البرمجية التالية).

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from Azure App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

بيئات الحجم الصحيح

استخدم مستويات الأداء (SKUs) لخدمات Azure التي تلبي احتياجات كل بيئة دون فائض. للتحجيم الصحيح للبيئات الخاصة بك، اتبع هذه التوصيات:

• تقدير التكاليف. استخدم حاسبة تسعير Azure لتقدير تكلفة كل بيئة.

• تكلفة تحسين بيئات الإنتاج. تحتاج بيئات الإنتاج إلى وحدات SKU تفي باتفاقيات مستوى الخدمة (SLA) والميزات والحجم اللازم للإنتاج. مراقبة استخدام الموارد باستمرار وضبط وحدات SKU للتوافق مع احتياجات الأداء الفعلية.

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

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

على سبيل المثال، يستخدم التنفيذ المرجعي معلمات Bicep لنشر مستويات أكثر تكلفة (وحدات SKU) إلى بيئة الإنتاج.

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

تنفيذ التحجيم التلقائي

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

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

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

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

أتمتة توزيع الموارد

استخدم الأتمتة لنشر موارد Azure ورمزها وتحديثها عبر جميع البيئات. اتبع هذه التوصيات:

• استخدام البنية الأساسية كتعلم برمجي. نشر البنية الأساسية كتعلم برمجي من خلال التكامل المستمر والتسليم المستمر (CI/CD). يحتوي Azure على قوالب Bicep وARM (JSON) وTerraform مسبقة الصنع لكل مورد Azure.

• استخدم البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر/النشر المستمر (CI/CD). استخدم البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD لنشر التعليمات البرمجية من التحكم بالمصادر إلى بيئاتك المختلفة، مثل الاختبار والتقسيم المرحلي والإنتاج. استخدم Azure Pipelines إذا كنت تعمل مع Azure DevOps أو GitHub Actions لمشاريع GitHub.

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

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

• إجراء عمليات فحص الأمان. استخدم اختبار أمان التطبيق الثابت (SAST) للعثور على عيوب الأمان وأخطاء الترميز في التعليمات البرمجية المصدر. بالإضافة إلى ذلك، قم بإجراء تحليل تكوين البرامج (SCA) لفحص مكتبات ومكونات الجهات الخارجية للمخاطر الأمنية. يتم دمج أدوات هذه التحليلات بسهولة في كل من GitHub وAzure DevOps.

تنفيذ المراقبة

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

• جمع بيانات تتبع الاستخدام للتطبيق. استخدم البنية التلقائية في Azure Application Insights لجمع بيانات تتبع الاستخدام للتطبيق، مثل معدل نقل الطلب ومتوسط مدة الطلب والأخطاء ومراقبة التبعية، دون أي تغييرات في التعليمات البرمجية.

  يستخدم AddApplicationInsightsTelemetry التنفيذ المرجعي من حزمة Microsoft.ApplicationInsights.AspNetCore NuGet لتمكين مجموعة بيانات تتبع الاستخدام (راجع التعليمات البرمجية التالية).

  public void ConfigureServices(IServiceCollection services)
  {
     ...
     services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
     ...
  }
  

• إنشاء مقاييس تطبيق مخصصة. استخدم الأجهزة المستندة إلى التعليمات البرمجية للقياس عن بعد للتطبيق المخصص. أضف Application Insights SDK إلى التعليمات البرمجية الخاصة بك واستخدم واجهة برمجة تطبيقات Application Insights.

  يجمع التنفيذ المرجعي بيانات تتبع الاستخدام على الأحداث المتعلقة بنشاط عربة التسوق. this.telemetryClient.TrackEvent تحسب التذاكر المضافة إلى السلة. يوفر اسم الحدث (AddToCart) ويحدد قاموسا يحتوي على concertId و count (راجع التعليمات البرمجية التالية).

  this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
      { "ConcertId", concertId.ToString() },
      { "Count", count.ToString() }
  });
  

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

نشر التنفيذ المرجعي

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

• تنفيذ تغييرات التعليمات البرمجية منخفضة التكلفة وعالية القيمة
• تحقيق هدف مستوى الخدمة (SLO) بنسبة 99.9٪
• اعتماد ممارسات DevOps
• إنشاء بيئات محسنة للتكلفة
• تعزيز الموثوقية والأمان

قررت Relecloud أن بنيتها الأساسية المحلية لم تكن حلا فعالا من حيث التكلفة لتحقيق هذه الأهداف. لقد قرروا أن ترحيل تطبيق الويب CAMS الخاص بهم إلى Azure هو الطريقة الأكثر فعالية من حيث التكلفة لتحقيق أهدافهم الفورية والمستقبلية. تمثل البنية التالية الحالة النهائية لتنفيذ نمط تطبيق الويب الموثوق به من Relecloud.

الشكل 3. بنية التنفيذ المرجعي. قم بتنزيل ملف Visio لهذه البنية.