إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
دالات Azure هي خدمة حوسبة مستندة إلى الحدث تقوم بتشغيل كتل صغيرة من التعليمات البرمجية أو الوظائف، دون توفير البنية الأساسية أو إدارتها بشكل صريح. يمكن أن تستجيب الدالات لأحداث مثل طلبات HTTP والموقتات ورسائل قائمة الانتظار والتغييرات في خدمات Azure الأخرى. تجعل هذه الإمكانية الوظائف مناسبة تماما لمعالجة البيانات وتكامل النظام ومهام الخلفية.
عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.
توضح هذه المقالة كيفية جعل الوظائف مرنة في مواجهة حالات الانقطاع والمشاكل المحتملة المختلفة، بما في ذلك الأخطاء العابرة، وفشل منطقة التوفر، والفشل على مستوى المنطقة. كما يسلط الضوء على المعلومات الرئيسية حول اتفاقية مستوى خدمة الوظائف (SLA).
توصيات نشر الإنتاج
يوفر إطار عمل Azure Well-Architected توصيات عبر الموثوقية والأمان والتكلفة والعمليات والأداء. لمعرفة كيفية تأثير هذه المجالات على بعضها البعض والمساهمة في حل Functions موثوق به، راجع أفضل ممارسات البنية للوظائف.
نظرة عامة على بنية الموثوقية
عند نشر Functions، من المهم التعرف على هذه المفاهيم:
خطط الاستضافة: تمثل الخطط بيئة الاستضافة لتطبيقات الوظائف الخاصة بك. تحدد الخطة موارد الحوسبة المتاحة ونموذج التسعير وسلوك التحجيم.
حسابات التخزين: عند إنشاء تطبيق دالة، يجب تحديد حساب تخزين مضيف. يدير حساب التخزين جوانب العمليات الداخلية لتطبيق الوظائف، بما في ذلك تخزين التعليمات البرمجية للوظيفة والتسجيل وإدارة التزامن (مثل عقود إيجار كائن ثنائي كبير الحجم لأنواع مشغلات معينة).
يمكنك أيضا استخدام حساب تخزين للنشر. قد يكون حساب التخزين هذا هو نفس حساب تخزين المضيف أو حساب تخزين مختلف.
مهم
تعد حسابات التخزين جزءا مهما من بنية موثوقية الوظائف. قم بتكوينها لتلبية متطلبات مرونة تطبيق الوظائف.
المشغلات والروابط: تتيح المشغلات والروابط لدالتك الاستجابة للأحداث، وتلقي البيانات من خدمات أخرى، وكتابة البيانات إلى خدمات أخرى.
الدوال الدائمة: الدوال الدائمة هي ميزة من وظائف. يوفر وظائف ذات حالة مثل التنسيقات طويلة الأمد والكيانات ذات الحالة.
عند استخدام الدوال الدائمة، يمكنك تكوين موفر تخزين يخزن الحالة. تقييم خصائص الموثوقية لمخزن الحالة الذي تختاره وتكوينه لتلبية متطلبات المرونة الخاصة بك.
المرونة في مواجهة الأعطال العابرة
الأخطاء العابرة هي حالات فشل قصيرة متقطعة في المكونات. تحدث بشكل متكرر في بيئة موزعة مثل السحابة، وهي جزء طبيعي من العمليات. الأخطاء العابرة تصحح نفسها بعد فترة زمنية قصيرة. من المهم أن تتمكن تطبيقاتك من معالجة الأخطاء العابرة، عادة عن طريق إعادة محاولة الطلبات المتأثرة.
يجب أن تتبع جميع التطبيقات المستضافة على السحابة إرشادات معالجة الأخطاء العابرة ل Azure عند الاتصال بأي واجهات برمجة تطبيقات وقواعد بيانات ومكونات أخرى مستضافة على السحابة. لمزيد من المعلومات، راجع توصيات للتعامل مع الأخطاء العابرة.
ضع في اعتبارك التوصيات التالية لمعالجة الأخطاء العابرة في تطبيقات الوظائف:
المشغلات والروابط: يتضمن النظام الأساسي للوظائف معالجة الأخطاء العابرة المضمنة للمشغلات والروابط. عند حدوث خطأ عابر أثناء تشغيل مشغل مدعوم أو قراءة ربط مدعوم للبيانات أو كتابتها، يمكن للنظام الأساسي إعادة محاولة العملية تلقائيا. يضمن سلوك إعادة المحاولة المضمن هذا أن مشكلات الاتصال المؤقتة أو انقطاع الخدمة لا تمنع دالتك من التشغيل. لمزيد من المعلومات، راجع معالجة أخطاء الوظائف وإعادة المحاولة.
تغطي هذه الحماية الأخطاء العابرة فقط. لا يعيد النظام الأساسي محاولة الفشل المستمر، مثل سلسلة الاتصال تم تكوينه بشكل خاطئ أو مورد محذوف.
يتعامل النظام الأساسي مع حالات الفشل المستمرة والفشل العابر المتكرر كأخطاء. تكوين التسجيل لالتقاط معلومات حول أخطاء تنفيذ الدالة. لمزيد من المعلومات، راجع تكوين المراقبة للوظائف.
التعليمات البرمجية للدالة الخاصة بك: في التعليمات البرمجية للدالة الخاصة بك، أنت مسؤول عن معالجة الأخطاء العابرة عندما تستدعي وظيفتك الخدمات الخارجية. تنفيذ منطق إعادة المحاولة والمهلات وأنماط قاطع الدائرة حسب الاقتضاء لمكالمات الخدمة الخارجية التي تم إجراؤها في التعليمات البرمجية للدالة. صمم وظائفك لتكون مكررة حيثما أمكن ذلك بحيث لا تنشئ عمليات إعادة المحاولة تأثيرات جانبية مكررة.
العملاء: يجب أن تكون تطبيقات العميل التي تتصل بالوظائف بشكل متزامن، مثل من خلال اتصال HTTP، مرنة في مواجهة الأخطاء العابرة.
المرونة في مواجهة حالات فشل منطقة التوفر
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
لا تدعم خطط الاستهلاك مناطق التوفر. إذا كان التكرار في المنطقة أحد متطلبات حمل العمل الخاص بك، ففكر في استخدام خطط استهلاك Flex أو Premium أو Dedicated ("Azure App Service") بدلا من ذلك.
تدعم خطط Flex Consumption عمليات النشر المتكررة في المنطقة.
تدعم الخطط المتميزة عمليات النشر المتكررة في المنطقة.
عند تمكين تكرار المنطقة، ينشر النظام الأساسي مثيلات خطتك تلقائيا عبر جميع مناطق التوفر في المنطقة المحددة. إذا كانت هناك مشكلة في أي منطقة توفر في المنطقة، تستمر وظائفك في التشغيل باستخدام مثيلات في مناطق صحية.
يجب تمكين التخزين المتكرر للمنطقة (ZRS) على حساب تخزين المضيف، ما يضمن أنه مرن أيضا في مواجهة انقطاعات المنطقة.
يوضح الرسم التخطيطي ثلاث مناطق توفر. تحتوي كل منطقة على مثيل Functions. يمتد حساب ZRS على جميع مناطق التوفر الثلاث.
تدعم خطة Dedicated (App Service) عمليات النشر المتكررة في المنطقة. عند تمكين تكرار المنطقة، ينشر النظام الأساسي مثيلاتك تلقائيا عبر جميع مناطق التوفر في المنطقة المحددة. يمكنك تكوين تكرار المنطقة على الخطة. لمزيد من المعلومات حول كيفية معالجة "Azure App Service" لتكرار المنطقة، راجع الموثوقية في App Service.
خطتك غير منطقة أو إقليمية عندما لا تقوم بتمكين التكرار في المنطقة. يمكن للنظام الأساسي وضع مثيلات الخطة في أي منطقة توفر في المنطقة أو في نفس المنطقة. مثيلات الخطة غير مرنة في مواجهة حالات فشل منطقة التوفر. قد تواجه خطتك وقت تعطل أثناء انقطاع التيار الكهربائي في أي منطقة في المنطقة.
متطلبات
- دعم المنطقة: يمكنك نشر خطط استهلاك Flex المكررة في المنطقة في مجموعة معينة من المناطق. يمكنك استرداد القائمة الحالية للمناطق المدعومة باستخدام Azure CLI. لمزيد من المعلومات، راجع عرض المناطق التي تدعم مناطق التوفر.
دعم المنطقة: يمكنك نشر خطط Premium المكررة في المنطقة في المناطق التالية.
الأمريكتان أوروبا الشرق الأوسط أفريقيا آسيا/المحيط الهادئ جنوب البرازيل وسط فرنسا إسرائيل الوسطى شمال جنوب أفريقيا شرق أستراليا وسط كندا وسط غرب ألمانيا قطر الوسطى وسط الهند Central US منطقة شمال إيطاليا شمال الإمارات العربية المتحدة منطقة شمال الصين 3 شرق الولايات المتحدة شمال أوروبا شرق آسيا شرق الولايات المتحدة 2 Norway East شرق اليابان جنوب وسط الولايات المتحدة منطقة السويد الوسطى جنوب شرق آسيا غرب الولايات المتحدة 2 شمال سويسرا غرب US 3 جنوب المملكة المتحدة West Europe أنظمة التشغيل: يدعم النظام الأساسي نشر خطط Windows وLinux المكررة في المنطقة.
الحد الأدنى لعدد المثيلات: يتطلب التكرار في المنطقة لخطط Premium مثيلين جاهزين دائما كحد أدنى.
- حساب تخزين المضيف: يجب تكوين حساب تخزين المضيف الافتراضي لتطبيق الوظائف لاستخدام ZRS. إذا كنت تستخدم حساب تخزين مضيف لم يتم تكوينه ل ZRS، فقد يتصرف تطبيقك بشكل غير متوقع أثناء انقطاع المنطقة.
- حساب تخزين حاوية النشر: إذا كنت تستخدم حساب تخزين منفصل لحاوية نشر التطبيق، فقم أيضا بتحديثه ليكون زائدا عن الحاجة في المنطقة.
الاعتبارات
سلوكيات غير وقت التشغيل: يضمن التكرار في المنطقة فقط استمرار وقت التشغيل للتطبيقات المنشورة. قد يؤثر انقطاع منطقة التوفر على جوانب الوظائف، على الرغم من أن التطبيق يستمر في خدمة نسبة استخدام الشبكة. تتضمن هذه السلوكيات تحجيم الخطة وإنشاء التطبيق وتكوين التطبيق ونشر التطبيق.
توزيع المثيل عبر المناطق
عند تكوين تطبيقات خطة Flex Consumption كمنطقة زائدة عن الحاجة، ينشر النظام الأساسي تلقائيا مثيلات الخطة عبر مناطق متعددة في المنطقة المحددة، مع قواعد مختلفة للمثيلات الجاهزة دائما مقابل المثيلات عند الطلب:
يتم توزيع المثيلات الجاهزة دائما عبر منطقتين على الأقل باستخدام توزيع الترتيب الدوري.
لضمان مرونة المنطقة، يحتفظ النظام الأساسي تلقائيا بمثيلين جاهزين دائما على الأقل لكل وظيفة أو مجموعة تحجيم لكل وظيفة، بغض النظر عن التكوين الجاهز دائما للتطبيق. المثيلات التي ينشئها النظام الأساسي تتم إدارتها بواسطة النظام الأساسي، ويتم فوترتها كمثيلات جاهزة دائما، ولا تغير إعدادات التكوين الجاهزة دائما.
تنتج المثيلات عند الطلب من وحدات تخزين مصدر الحدث حيث يتجاوز التطبيق عدد المثيلات الجاهزة دائما. يتم توزيع المثيلات عند الطلب عبر مناطق التوفر على أساس أفضل جهد. يعطي النظام الأساسي الأولوية لتوسيع النطاق بشكل أسرع على التوزيع المتساوي عبر المناطق. يحاول النظام الأساسي حتى الخروج من التوزيع بمرور الوقت.
عند تكوين خطط تطبيق وظائف Elastic Premium كمنطقة زائدة عن الحاجة، ينشر النظام الأساسي مثيلات الخطة تلقائيا عبر مناطق متعددة في المنطقة المحددة. يتبع انتشار المثيل هذه القواعد، حتى مع تحجيم التطبيق وتحجيمه:
الحد الأدنى لعدد مثيلات تطبيق الوظائف هو اثنان.
عند تحديد سعة أكبر من عدد المناطق، يتم نشر المثيلات بالتساوي فقط عندما تكون السعة متعددة لعدد المناطق.
بالنسبة لقيمة السعة الأكبر من عدد المناطق مضروبة في عدد المثيلات، تنتشر مثيلات إضافية عبر المناطق المتبقية.
عندما تخصص الدالات مثيلات لخطة Premium زائدة عن الحاجة في المنطقة، فإنها تستخدم موازنة المنطقة بأفضل جهد، والتي توفرها مجموعات توسعة الأجهزة الظاهرية في Azure الأساسية. يعتبر Azure خطة Premium متوازنة عندما يكون لكل منطقة نفس عدد الأجهزة الظاهرية (VMs) مثل المناطق الأخرى في الخطة، بالإضافة إلى أو ناقص جهاز ظاهري واحد.
Cost
لا يضيف تمكين التكرار في المنطقة رسوما منفصلة. لا يوجد مقياس إضافي لميزة تكرار المنطقة نفسها، وسعر كل مثيل لخطة المنطقة المكررة هو نفس سعر خطة منطقة واحدة. ومع ذلك، يؤدي تمكين التكرار في المنطقة إلى زيادة الحد الأدنى لعدد المثيلات التي يجب أن تعمل بها خطتك، ما يمكن أن يزيد من الفاتورة. راجع التفاصيل الخاصة بالخطة التي تلي ذلك قبل تمكين تكرار المنطقة في الإنتاج.
عند تمكين مناطق التوفر في تطبيق بتكوين مثيل جاهز دائما لأقل من مثيلين لكل دالة أو مجموعة للتحجيم لكل وظيفة، يقوم النظام الأساسي تلقائيا بإنشاء مثيلين من النوع الجاهز دائما لكل وظيفة أو مجموعة تغيير الحجم لكل وظيفة. يتم أيضا فوترة هذه المثيلات الجديدة كمثيلات جاهزة دائما.
نظرا لأن هناك حاجة إلى مثيلين جاهزين دائما على الأقل لكل دالة أو مجموعة تغيير الحجم لكل وظيفة أثناء تمكين التكرار في المنطقة، فإن تطبيق Flex Consumption المكرر في المنطقة لا يتم تغيير حجمه إلى الصفر. يمكن أن ترى التطبيقات التي كانت راكدة في وقت سابق زيادة في التكلفة بعد تمكين تكرار المنطقة، لأن المثيلات المطلوبة تتحمل عداد الأساس الاسمي الجاهز دائما باستمرار (حتى عند الخمول)، وإضافة عداد وقت التنفيذ الجاهز دائما في الأعلى أثناء التنفيذ النشط. للحصول على تعريفات العدادات وأسعارها، راجع أسعار دالات Azure.
إذا قمت بتمكين مناطق التوفر على خطة تحتوي على أقل من مثيلين، يفرض النظام الأساسي حدا أدنى لعدد مثيلين لتلك الخطة، ويتم تحصيل رسوم منك لكلا المثيلين.
للحصول على تفاصيل التسعير الكاملة، راجع تسعير الوظائف.
تكوين دعم منطقة التوفر
إنشاء خطة وظائف جديدة مكررة للمنطقة. يمكنك تمكين تكرار المنطقة عند إنشاء خطة جديدة. لمزيد من المعلومات، راجع إنشاء تطبيق وظائف المنطقة المكررة.
تمكين تكرار المنطقة على خطة موجودة. يمكنك تشغيل مناطق التوفر أو إيقاف تشغيلها لخطط Elastic Premium الحالية. تحتوي خطط Elastic Premium على سلوك سعة محدد يختلف عن خطط Dedicated (App Service) ويتطلب خطوات تكوين إضافية. للحصول على خطوات مفصلة، راجع تمكين تكرار المنطقة على خطة موجودة.
إنشاء خطة وظائف جديدة مكررة للمنطقة. يمكنك تمكين تكرار المنطقة عند إنشاء خطة جديدة. لمزيد من المعلومات، راجع إنشاء تطبيق وظائف المنطقة المكررة.
تمكين تكرار المنطقة على خطة موجودة. بالنسبة لخطط Premium، يمكنك تمكين تكرار المنطقة فقط أثناء إنشاء الخطة. لا يمكنك تحويل خطة Premium موجودة لتكون زائدة عن الحاجة في المنطقة. بدلا من ذلك، قم بترحيل تطبيقك عن طريق إنشاء نشر جنبا إلى جنب على تطبيق خطة Premium جديد. لمزيد من المعلومات، راجع تمكين تكرار المنطقة على خطة موجودة.
تخطيط القدرات وإدارتها
تستمر تطبيقات الوظائف المكررة في المنطقة في العمل حتى عندما تواجه المناطق في المنطقة انقطاعا.
أثناء انقطاع المنطقة، تكتشف الدالات المثيلات المفقودة وتحاول تلقائيا تحديد موقع مثيلات الاستبدال أو إنشائها في المناطق السليمة. ينفذ النظام الأساسي هذه العملية على أساس أفضل جهد ولا يضمن النجاح. إذا كان حمل العمل يتطلب عددا محددا من المثيلات للحفاظ على مستوى الخدمة المتوقع، ففكر في الإفراط في توفير عدد المثيلات الجاهزة دائما. يتيح الإفراط في التوفير للحل تحمل فقدان السعة والاستمرار في العمل دون انخفاض الأداء. لمزيد من المعلومات، راجع إدارة السعة عن طريق الإفراط في التوفير.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عندما تكون الخطة زائدة عن الحاجة للمنطقة، ويستخدم حساب التخزين المضيف ZRS، وتكون جميع مناطق التوفر قيد التشغيل.
عملية عبر المناطق: عند تكوين تكرار المنطقة على Functions، يتم توزيع الطلبات تلقائيا عبر المثيلات في كل منطقة توفر. قد ينتقل الطلب إلى أي مثيل في أي منطقة توفر.
النسخ المتماثل للبيانات عبر المناطق: الدالات هي خدمة حوسبة عديمة الحالة، لذلك لا توجد بيانات للنسخ المتماثل بين المناطق. ينسخ النظام الأساسي التكوين عبر المناطق تلقائيا.
إذا كان حساب تخزين المضيف يستخدم ZRS، تخزين Azure نسخ بياناته بشكل متزامن عبر مناطق توفر متعددة.
للحصول على وظائف دائمة، راجع موفر التخزين لمعرفة كيفية نسخ البيانات عبر المناطق.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عندما تكون الخطة زائدة عن الحاجة للمنطقة، ويستخدم حساب التخزين المضيف ZRS، وهناك انقطاع في منطقة التوفر.
- الكشف والاستجابة: النظام الأساسي للوظائف مسؤول عن الكشف عن فشل في منطقة توفر. لا تحتاج إلى بدء تجاوز فشل المنطقة.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام حالة خدمة Azure لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
الطلبات النشطة: عندما تكون منطقة التوفر غير متوفرة، تنتهي الطلبات قيد التقدم التي تتصل بمثيل في منطقة التوفر المعيبة ويجب إعادة المحاولة. تأكد من إعداد تطبيقاتك باتباع إرشادات معالجة الأخطاء العابرة.
فقدان البيانات المتوقع: لا يتوقع أن تتسبب حالات فشل المنطقة في فقدان البيانات لأن Functions هي خدمة عديمة الحالة.
إذا كان حساب تخزين المضيف الخاص بك يستخدم ZRS، فإن التخزين يضمن عدم فقدان البيانات من فشل المنطقة.
بالنسبة للوظائف الدائمة، راجع موفر التخزين لمعرفة ما إذا كان فقدان البيانات ممكنا أثناء فشل المنطقة.
وقت التعطل المتوقع: أثناء انقطاع المنطقة، قد تواجه الاتصالات انقطاعات قصيرة تستمر عادة بضع ثوان مع إعادة توزيع حركة المرور. تأكد من إعداد تطبيقاتك باتباع إرشادات معالجة الأخطاء العابرة.
إعادة توجيه حركة المرور: تكتشف الوظائف المثيلات المفقودة من تلك المنطقة وتحاول العثور على مثيلات استبدال جديدة. بعد أن تعثر الدالات على الاستبدالات، فإنها توزع نسبة استخدام الشبكة عبر المثيلات الجديدة حسب الحاجة.
مهم
لا يضمن Azure نجاح طلبات المزيد من المثيلات في سيناريو تقسيم المنطقة. تحاول المنصة إعادة ملء الحالات المفقودة على أساس أفضل الجهود. إذا كنت بحاجة إلى سعة مضمونة أثناء فشل منطقة التوفر، قم بإنشاء وتكوين خططك لحساب فقدان المنطقة عن طريق الإفراط في توفير السعة.
سلوكيات غير وقت التشغيل: تستمر التطبيقات الموجودة في خطة تطبيق الوظائف المكررة في المنطقة في التشغيل وخدمة نسبة استخدام الشبكة حتى إذا واجهت منطقة التوفر انقطاعا. ومع ذلك، قد تتأثر السلوكيات غير وقت التشغيل أثناء انقطاع منطقة التوفر. تتضمن هذه السلوكيات تحجيم تطبيق الوظائف وإنشاء التطبيق وتكوين التطبيق ونشر التطبيق.
استعادة المنطقة
عند استرداد منطقة التوفر، تقوم Functions تلقائيا باستعادة المثيلات في منطقة التوفر، وإزالة المثيلات المؤقتة التي تم إنشاؤها في مناطق التوفر الأخرى، وإعادة توجيه نسبة استخدام الشبكة بين مثيلاتك كالمعتاد.
اختبار فشل المنطقة
يدير النظام الأساسي Functions توجيه نسبة استخدام الشبكة وتجاوز الفشل واسترداد المنطقة للموارد المكررة في المنطقة. لا تحتاج إلى بدء أي شيء. Azure إدارة هذه الميزة بشكل كامل، لذلك لا تحتاج إلى التحقق من صحة عمليات فشل منطقة التوفر.
القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة
الدالات هي خدمة من منطقة واحدة. إذا أصبحت المنطقة غير متوفرة، فإن مورد Functions غير متوفر أيضا.
حلول متعددة المستويات مخصصة للمرونة
لتجنب انقطاع الخدمة أثناء الانقطاعات على مستوى المنطقة، يمكنك نشر نفس الوظائف بشكل متكرر لتطبيقات الوظائف في مناطق متعددة.
أنت مسؤول عن:
نشر تطبيقات الوظائف في مناطق متعددة.
إدارة توزيع نسبة استخدام الشبكة بين المناطق.
تنفيذ آليات تجاوز الفشل.
ضمان تناسق البيانات عبر المناطق (إن أمكن).
مراقبة عمليات النشر عبر المناطق وإدارتها.
عند تشغيل نفس التعليمات البرمجية للدالة في مناطق متعددة، ضع في اعتبارك الأنماط النشطة-النشطةوالنشطة-السلبية . تقدم الأقسام التالية هذه الأنماط ولكنها لا توفر إرشادات مفصلة أو خطوات تكوين.
نمط نشط-نشط لوظائف مشغل HTTP
في نمط نشط-نشط، تعمل الدالات في كلتا المنطقتين على تشغيل الأحداث ومعالجتها بشكل نشط، إما بطريقة مكررة أو في التدوير. استخدم نمط نشط-نشط مع الواجهة الأمامية لـ Azure للدالات الهامة التي يتم تشغيلها بواسطة HTTP، والتي يمكنها توجيه طلبات HTTP وتقريبها بين الدالات التي تعمل في مناطق متعددة. يمكن الواجهة الأمامية لـ Azure أيضا التحقق بشكل دوري من صحة كل نقطة نهاية. إذا توقفت دالة في منطقة واحدة عن الاستجابة لعمليات التحقق من السلامة، الواجهة الأمامية لـ Azure إزالتها من التدوير وإعادة توجيه نسبة استخدام الشبكة فقط إلى الوظائف السليمة المتبقية.
يظهر الرسم التخطيطي الواجهة الأمامية لـ Azure في الأعلى. تظهر منطقتين أدناه: المنطقة الأساسية على اليسار والمنطقة الثانوية على اليمين. تحتوي كل منطقة على تطبيق Functions وقاعدة بيانات. تشير الأسهم من الواجهة الأمامية لـ Azure إلى كلا تطبيقي الوظائف. يشير السهم من كل تطبيق وظيفة إلى قاعدة البيانات الخاصة به.
نمط نشط-سلبي لوظائف مشغل غير HTTP
بالنسبة للوظائف التي تستند إلى الحدث وغير المشغلة ب HTTP (مثل ناقل خدمة Azure ومشغلات مراكز أحداث Azure)، استخدم نمطا نشطا-سلبي. في نمط نشط-سلبي، يتم تشغيل مثيلات الدالة في المنطقة التي تتلقى الأحداث، بينما تظل المثيلات في المنطقة الثانوية الخامة. يضمن هذا النمط أن تقوم دالة واحدة فقط بمعالجة كل رسالة، ما يساعد على الحفاظ على تناسق البيانات. كما يوفر طريقة للفشل في المنطقة الثانوية أثناء حدوث كارثة مثل انقطاع المنطقة.
ضع في اعتبارك تجاوز فشل تطبيق الوظائف مع سلوكيات تجاوز الفشل للخدمات الأخرى التي تستخدمها، مثل:
- Service Bus النسخ المتماثل الجغرافي والتعافي من الكوارث الجغرافية
- النسخ المتماثل الجغرافي لمراكز الأحداث والتعافي من الكوارث الجغرافية
ضع في اعتبارك مثال تخطيط الشبكة الذي يستخدم مشغل مراكز الأحداث، حيث يتم تكوين مساحة اسم مراكز الأحداث للتعافي من الكوارث الجغرافية. في هذه الحالة، يتطلب النمط النشط-السلبي المكونات التالية:
مساحات أسماء مراكز الأحداث المنشورة في كل من منطقة أساسية وثانوية.
تمكين التعافي من الكوارث الجغرافية لإقران مراكز الأحداث الأساسية والثانوية. ينشئ هذا التكوين أيضا اسما مستعارا يمكنك استخدامه للاتصال بمساحة اسم مراكز الأحداث وتبديل الاسم المستعار من الأساسي إلى الثانوي دون إجراء تغييرات على معلومات الاتصال.
تطبيقات الوظائف المنشورة في كل من المنطقة الأساسية والثانوية. يظل التطبيق في المنطقة الثانوية الخاما لأنه لا يتلقى الرسائل.
تستخدم مشغلات كل تطبيق دالة سلسلة الاتصال المباشر (غير الأساسي) لمساحة اسم Event Hubs الخاصة به.
ينشر الناشرون إلى مساحة اسم مراكز الأحداث إلى الاسم المستعار سلسلة الاتصال.
يظهر الرسم التخطيطي منطقة أساسية على اليسار ومنطقة ثانوية على اليمين. تحتوي المنطقة الأساسية على مساحة اسم نشطة لمراكز الأحداث، تطبيق دالة، وقاعدة بيانات. تحتوي المنطقة الثانوية على مساحة اسم Event Hubs سلبية، تطبيق دالة، وقاعدة بيانات. يشير السهم من الاسم المستعار إلى التعافي من الكوارث الجغرافية لمراكز الأحداث، والذي يربط مساحات أسماء مراكز الأحداث الأساسية والثانوية. تشير الأسهم من كل مركز أحداث إلى تطبيق الوظائف الخاص بها. يشير السهم من كل تطبيق وظيفة إلى قاعدة البيانات الخاصة به.
قبل تجاوز الفشل، يوجه الناشرون الذين يرسلون الأحداث إلى الاسم المستعار المشترك نسبة استخدام الشبكة إلى مركز الأحداث الأساسي. يستمع تطبيق الدالة الأساسي حصريا إلى مركز الأحداث الأساسي. يظل تطبيق الوظائف الثانوي سلبيا و الخامل.
عند بدء تجاوز الفشل، يتم توجيه الناشرين الذين يرسلون الأحداث إلى الاسم المستعار المشترك إلى مركز الأحداث الثانوي. يصبح تطبيق الوظائف الثانوية نشطا ويتم تشغيله تلقائيا. يمكن لمركز الأحداث دفع عملية تجاوز الفشل بأكملها، ويتم تشغيل كل تطبيق وظائف فقط عندما يكون مركز الأحداث المقابل نشطا.
دوال دائمة
للتعافي من الكوارث متعددة المناطق للوظائف الدائمة، راجع التعافي من الكوارث والتوزيع الجغرافي في Azure الوظائف الدائمة.
المرونة في صيانة الخدمة
تقوم الوظائف بإجراء ترقيات خدمة منتظمة ومهام صيانة أخرى.
- مرونة عابرة للخطأ: أثناء صيانة الخدمة، قد تتم إعادة تشغيل المثيلات التي تقوم بتشغيل تطبيق الوظائف أو تواجه انقطاعات مؤقتة. تأكد من أن تطبيقات العميل التي تتفاعل مع تطبيق الوظائف الخاص بك مرنة في مواجهة الأخطاء العابرة.
- تمكين تكرار المنطقة: عند تمكين تكرار المنطقة على خطتك، يمكنك أيضا تحسين المرونة أثناء تحديثات النظام الأساسي. يؤدي نشر مثيلات متعددة في خطتك وتمكين تكرار المنطقة لخطتك إلى إضافة طبقة إضافية من المرونة إذا أصبح مثيل أو منطقة غير سليمة أثناء الترقية.
مثيلات مؤقتة إضافية: للحفاظ على السعة المتوقعة أثناء الترقية، يضيف النظام الأساسي تلقائيا مثيلات إضافية للخطة أثناء عملية الترقية.
تمكين تكرار المنطقة: عند تمكين تكرار المنطقة على خطتك، يمكنك أيضا تحسين المرونة أثناء تحديثات النظام الأساسي. تتكون مجالات التحديث من مجموعات من الأجهزة الظاهرية التي توضع في وضع عدم الاتصال أثناء التحديث، ويتم تعيينها إلى مناطق التوفر. يؤدي نشر مثيلات متعددة في خطتك وتمكين تكرار المنطقة لخطتك إلى إضافة طبقة إضافية من المرونة إذا أصبح مثيل أو منطقة غير سليمة أثناء الترقية.
App Service Environment: إذا كنت تستضيف تطبيق الوظائف على App Service Environment، يمكنك تخصيص دورة الترقية. إذا كان عليك التحقق من صحة تأثير الترقيات على حمل العمل الخاص بك، فمكن الترقيات اليدوية. استخدم هذا الأسلوب للتحقق من صحة مثيل غير إنتاج واختباره قبل تطبيق الترقيات على مثيل الإنتاج الخاص بك.
لمزيد من المعلومات حول تفضيلات الصيانة، راجع تفضيلات الترقية للصيانة المخططة لبيئة خدمة التطبيقات.
المرونة في عمليات نشر التطبيقات
تقدم عمليات نشر التطبيقات مخاطر حدوث مشكلات في بيئة الإنتاج. كن مستعدا للعودة إلى الحالة السابقة للتحديث إذا تسبب في حدوث مشاكل. التحكم في كيفية نشر التحديثات لتقليل التعطيل الناتج عن إعادة تشغيل التطبيق.
تدعم خطط Flex Consumption استراتيجيات تحديث الموقع، والتي توفر طرقا متعددة لنشر تحديثات التطبيق. تتضمن هذه الاستراتيجيات تحديثات متجددة لتوزيع وقت التعطل الصفري.
تتيح فتحات توزيع الوظائف عمليات نشر بدون توقف لتطبيقات الوظائف الخاصة بك. استخدم فتحات التوزيع لتقليل تأثير عمليات النشر وتغييرات التكوين للمستخدمين. تقلل فتحات النشر أيضا من احتمال إعادة تشغيل التطبيق الخاص بك. تتسبب إعادة تشغيل التطبيق في حدوث أخطاء عابرة.
اتفاقية مستوى الخدمة
تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.
توفر الوظائف اتفاقيات مستوى الخدمة لقابلية الوصول المميزة لخطة الاستهلاك وأنواع الخطط الأخرى.