تطبيقات السحابة القابلة للتطوير وهندسة موثوقية الموقع (SRE)
يعتمد نجاح الحل السحابي على موثوقيته. يمكن تعريف الموثوقية على نطاق واسع بأنها احتمال أن يعمل النظام كما هو متوقع، في ظل الظروف البيئية المحددة، خلال فترة زمنية محددة. هندسة موثوقية الموقع (SRE) هي مجموعة من الكيانات والممارسات لإنشاء أنظمة برمجية قابلة لتغيير الحجم وموثوقة للغاية. على نحو متزايد، يتم استخدام SRE أثناء تصميم الخدمات الرقمية لضمان موثوقية أكبر.
لمزيد من المعلومات بشأن إستراتيجيات SRE، راجع AZ-400: تطوير إستراتيجية Site Reliability Engineering (SRE).
حالات الاستخدام المحتملة
تنطبق المفاهيم الواردة في هذه المقالة على:
- الخدمات السحابية القائمة على API.
- تطبيقات الويب ذات الواجهة العامة.
- أحمال العمل المستندة إلى إنترنت الأشياء أو المستندة إلى الحدث.
بناء الأنظمة
قم بتنزيل ملف PowerPoint لهذا التصميم.
البنية التي يتم أخذها في الاعتبار هنا هي نظام أساسي قابل لتغيير الحجم لواجهة برمجة التطبيقات. يشتمل الحل على العديد من الخدمات الصغيرة التي تستخدم مجموعة متنوعة من قواعد البيانات وخدمات التخزين، بما في ذلك حلول البرمجيات كخدمة (SaaS) مثل Dynamics 365 وMicrosoft 365.
تأخذ هذه المقالة في الاعتبار حلا يعالج حالات استخدام السوق والتجارة الإلكترونية عالية المستوى لإظهار الكتل الموضحة في الرسم التخطيطي. حالات الاستخدام هي:
- تصفح المنتج.
- التسجيل والدخول.
- عرض المحتوى مثل المقالات الإخبارية.
- إدارة الطلبات والاشتراكات.
تستهلك تطبيقات العميل مثل تطبيقات الويب وتطبيقات الأجهزة المحمولة وحتى تطبيقات الخدمة خدمات النظام الأساسي لواجهة برمجة التطبيقات من خلال مسار وصول موحد، https://api.contoso.com.
المكونات
- يوفر Azure Front Door نقطة دخول آمنة وموحدة لجميع الطلبات إلى الحل. لمزيد من المعلومات، راجع نظرة عامة على هندسة التوجيه.
- توفر Azure APIM طبقة إدارة فوق كل واجهات برمجة التطبيقات المنشورة. يمكنك استخدام نُهج Azure APIM Management لتطبيق إمكانات إضافية على طبقة API، مثل قيود الوصول والتخزين المؤقت وتحويل البيانات. تدعم إدارة واجهة برمجة التطبيقات التحجيم التلقائي في المستويات القياسية والمتميزة.
- تعد Azure Kubernetes Service (AKS) تطبيق Azure لنظم مجموعات Kubernetes مفتوحة المصدر. كخدمة مستضافة من Kubernetes، يعالج Azure المهام المهمة مثل المراقبة الصحية والصيانة. نظراً لأن برامج Kubernetes الرئيسية تُدار من Azure، فإنك تدير فقط عقد الوكيل وتحافظ عليها. في هذه البنية، يتم توزيع جميع الخدمات المصغرة في AKS.
- تعد Azure Application Gateway خدمة تحكم في تسليم التطبيق. يعمل في الطبقة 7، وهي طبقة التطبيق، وله إمكانيات مختلفة لموازنة التحميل. وحدة تحكم دخول بوابة التطبيق (AGIC) هو تطبيق Kubernetes الذي يجعل من الممكن لعملاء خدمة Azure Kubernetes (AKS) استخدام موازن تحميل Azure Application Gateway L7 الأصلي لعرض برامج السحابة على الإنترنت. التحجيم التلقائي وتكرار المنطقة مدعومان في v2 SKU.
- يمكن لكل من Azure Storage وAzure Data Lake Storage وAzure Cosmos DB وAzure SQL تخزين كلٍ من المحتوى المنظم وغير المنظم. يمكن إنشاء حاويات وقواعد بيانات Azure Cosmos DB بمعدل نقل التحجيم التلقائي.
- Microsoft Dynamics 365 هو برنامج كخدمة (SaaS) يقدم من Microsoft والذي يوفر العديد من تطبيقات الأعمال لخدمة العملاء والمبيعات والتسويق والتمويل. في هذه البنية، يستخدم Dynamics 365 بشكل أساسي لإدارة كتالوجات المنتجات وإدارة خدمة العملاء. توفر وحدات القياس مرونة لتطبيقات Dynamics 365.
- يستخدم Microsoft 365 (المعروف سابقا باسم Office 365) كنظام لإدارة محتوى المؤسسة تم إنشاؤه على Microsoft 365 SharePoint في Microsoft 365. يتم استخدامه لإنشاء محتوى وإدارته ونشره مثل أصول الوسائط والمستندات.
البدائل
نظراً لأن هذا الحل يستخدم بنية قائمة على الخدمات المصغرة قابلة للتوسع بدرجة كبيرة، فضع في اعتبارك هذه البدائل لمستوى الحساب:
- Azure Functions لخدمات واجهة برمجة التطبيقات بلا خادم
- تطبيقات Azure Spring للخدمات المصغرة المستندة إلى Java
الموثوقية المناسبة
تعتمد درجة الموثوقية المطلوبة للحل على سياق العمل. متجر البيع بالتجزئة الذي يفتح لمدة 14 ساعة، والذي بلغ ذروته في استخدام النظام خلال تلك الفترة، لديه متطلبات مختلفة عن الأعمال التجارية عبر الإنترنت التي تقبل الطلبات في جميع الساعات. يمكن تصميم ممارسات SRE لتحقيق المستوى المناسب من الموثوقية.
يتم تحديد الموثوقية وقياسها باستخدام أهداف مستوى الخدمة (أهداف مستوى الخدمة (SLOs)) التي تحدد المستوى المستهدف للموثوقية للخدمة. يضمن تحقيق المستوى المستهدف رضا المستهلكين. يمكن أن تتطور أهداف SLO أو تتغير وفقاً لمتطلبات العمل. ومع ذلك، يجب على مالكي الخدمة قياس الموثوقية باستمرار مقابل SLO للكشف عن المشكلات واتخاذ الإجراءات التصحيحية. يتم تعريف SLOs عادة على أنها نسبة الإنجاز على مدى فترة.
مصطلح مهم آخر يجب ملاحظته هو مؤشر مستوى الخدمة (مؤشر مستوى الخدمة (SLI)، وهو المقياس المستخدم لحساب SLO. تستند SLIs إلى الرؤى المشتقة من البيانات التي يتم التقاطها أثناء استهلاك العميل للخدمة. يتم دائماً قياس SLIs من وجهة نظر العميل.
دائماً ما تسير SLO وSLI جنباً إلى جنب، وعادة ما يتم تعريفها بطريقة تكرارية. تعتمد SLO على أهداف العمل الرئيسية، في حين أن SLIs مدفوعة بما يمكن قياسه أثناء تنفيذ الخدمة.
العلاقة بين المقياس المرصود وSLI وSLO موضحة أدناه:
تم شرح ذلك بمزيد من التفصيل في تحديد قياسات SLI لحساب SLO.
مقياس النمذجة وتوقعات الأداء
بالنسبة لنظام البرمجيات، يشير الأداء عموماً إلى الاستجابة العامة للنظام عند تنفيذ إجراء خلال وقت محدد، بينما قابلية التوسع هي قدرة النظام على التعامل مع أحمال المستخدم المتزايدة دون الإضرار بالأداء.
يعتبر النظام قابلاً للتطوير إذا تم توفير الموارد الأساسية بشكل ديناميكي لدعم زيادة الحمل. يجب تصميم التطبيقات السحابية لتناسب تغيّر الحجم، ويصعب التنبؤ بوحدة تخزين نسبة استخدام الشبكة في بعض الأحيان. يمكن أن تؤدي الارتفاعات الحالات التي تتكرر كل حين إلى زيادة متطلبات الحجم، خاصةً عندما تتعامل خدمة ما مع طلبات مستأجرين متعددين.
من الممارسات الجيدة تصميم التطبيقات حتى تتوسع موارد السحابة تلقائياً حسب الحاجة لمواجهة الحمل. بشكل أساسي، يجب أن يتكيف النظام مع زيادة حمل العمل من خلال توفير الموارد أو تخصيصها بطريقة تدريجية لتلبية الطلب. لا تتعلق قابلية التوسع بحساب الطبعات فحسب، بل تتعلق أيضاً بالعناصر الأخرى مثل تخزين البيانات والبنية الأساسية للرسائل.
توضح هذه المقالة كيف يمكنك ضمان الموثوقية المناسبة لتطبيق السحابة من خلال إجراء نمذجة مقياس وأداء لسيناريوهات حمل العمل، واستخدام النتائج لتحديد الشاشات، وSLIs، وSLO.
الاعتبارات
راجع ركيزتي Reliability وPerformance Efficiency في Azure Well Architected Framework للحصول على إرشادات بشأن إنشاء تطبيقات موثوقة وقابلة لتغيير الحجم.
تستكشف هذه المقالة كيفية تطبيق قابلية التوسع وتقنيات نمذجة الأداء لضبط بنية الحل وتصميمه. تحدد هذه التقنيات التغييرات التي تطرأ على تدفقات العمليات من أجل تجربة المستخدم المثلى. ضع قراراتك الفنية على أساس المتطلبات غير الوظيفية للحل. العملية هي:
- حدد متطلبات قابلية التوسع.
- أنشئ نموذجاً للحمولة المتوقعة.
- حدد SLIs وSLO لسيناريوهات المستخدم.
إشعار
تُعد Azure Application Insights، جزءاً من Azure Monitor، وهو أداة قوية لإدارة أداء التطبيقات (APM) يمكنك دمجها بسهولة مع تطبيقاتك لإرسال القياس عن بُعد وتحليل القياسات الخاصة بالتطبيقات. كما يوفر أيضاً لوحات معلومات جاهزة للاستخدام ومستكشف قياسات يمكنك استخدامه لتحليل البيانات لاستكشاف احتياجات العمل.
الحصول على متطلبات قابلية التوسع
افترض هذه القياسات لذروة الحمل:
- عدد المستهلكين الذين يستخدمون API Platform: 1.5 مليون
- المستهلكون النشطون كل ساعة (30 بالمائة من 1.5 مليون): 450.000
- النسبة المئوية للتحميل لكل نشاط:
- تصفح المنتج: 75 بالمائة
- التسجيل بما في ذلك إنشاء ملف التعريف وتسجيل الدخول: 10 بالمائة
- إدارة الطلبات والاشتراكات: 10 بالمائة
- مشاهدة المحتوى: 5 بالمائة
ينتج الحمل متطلبات تغيير الحجم التالية، في ظل حمل الذروة العادي، لواجهات برمجة التطبيقات التي يستضيفها النظام الأساسي:
- الخدمة المصغرة للمنتج: حوالي 500 طلب في الثانية (RPS)
- الخدمة المصغرة للملف الشخصي: حوالي 100 RPS
- الطلبات والخدمات المصغرة للدفع: حوالي 100 RPS
- الخدمة المصغرة للمحتوى: حوالي 50 RPS
لا تأخذ هذه المتطلبات لتغيير الحجم في الاعتبار الذروات الحالات التي تتكرر كل حين والعشوائية، والقمم خلال الأحداث الخاصة مثل العروض الترويجية للتسويق. خلال فترات الذروة، فإن متطلبات الحجم لبعض أنشطة المستخدم تصل إلى 10 أضعاف حمل الذروة العادي. ضع هذه القيود والتوقعات في الاعتبار عند تحديد اختيارات التصميم للخدمات المصغرة.
تحديد قياسات SLI لحساب SLO
تشير قياسات SLI إلى الدرجة التي توفر بها الخدمة تجربة مرضية، ويمكن التعبير عنها كنسبة الأحداث الجيدة إلى إجمالي الأحداث.
بالنسبة إلى خدمة واجهة برمجة التطبيقات، تشير الأحداث إلى القياسات الخاصة بالتطبيق التي يتم التقاطها أثناء التنفيذ باعتبارها بيانات عن بُعد أو بيانات مُعالجة. يحتوي هذا المثال على قياسات SLI التالية:
| مقياس | الوصف |
|---|---|
| التوافر | ما إذا كان الطلب قد تم تقديمه بواسطة API |
| زمن الانتقال | حان الوقت لواجهة برمجة التطبيقات لمعالجة الطلب وإعادة الرد |
| الإنتاجية | عدد الطلبات التي عالجتها واجهة برمجة التطبيقات |
| معدل النجاح | عدد الطلبات التي عالجتها واجهة برمجة التطبيقات بنجاح |
| معدل الخطأ | عدد الأخطاء للطلبات التي عالجتها واجهة برمجة التطبيقات |
| التجدد | عدد المرات التي تلقى فيها المستخدم أحدث البيانات لعمليات القراءة على واجهة برمجة التطبيقات، على الرغم من تحديث مخزن البيانات الأساسي بزمن انتقال معين للكتابة |
إشعار
تأكد من تحديد أي SLIs إضافية مهمة للحل الخاص بك.
فيما يلي أمثلة على SLIs:
- (عدد الطلبات التي تم إكمالها بنجاح في أقل من 1000 ملّي ثانية) / (عدد الطلبات)
- (عدد نتائج البحث التي تُرجع، خلال ثلاث ثوانٍ، أي منتجات تم نشرها في الكتالوج) / (عدد عمليات البحث)
بعد تحديد SLIs، حدد الأحداث أو القياس عن بُعد لالتقاطه لقياسها. على سبيل المثال، لقياس مدى التوفر، يمكنك التقاط الأحداث للإشارة إلى ما إذا كانت خدمة API قد عالجت طلباً بنجاح. بالنسبة للخدمات المستندة إلى HTTP، تتم الإشارة إلى النجاح أو الفشل من خلال رموز حالة HTTP. يجب أن يوفر تصميم وتنفيذ واجهة برمجة التطبيقات (API) الرموز المناسبة. بشكل عام، تعد قياسات SLI مدخلاً مهماً لتطبيق API.
بالنسبة للأنظمة المستندة إلى مجموعة النظراء، يمكنك الحصول على بعض القياسات باستخدام دعم التشخيص والمراقبة المتاح للموارد. يعد Azure Monitor حلاً شاملاً لجمع البيانات عن بُعد وتحليلها والعمل على أساسها من خدمات السحابة الخاصة بك. اعتماداً على متطلبات SLI الخاصة بك، يمكن التقاط المزيد من بيانات المراقبة لحساب القياسات.
استخدم التوزيعات المئوية
يتم حساب بعض SLIs باستخدام تقنية التوزيع المئوي. هذا يعطي نتائج أفضل إذا كانت هناك قيم متطرفة يمكن أن تحرف تقنيات أخرى مثل التوزيعات المتوسطة أو المتوسطة.
على سبيل المثال، ضع في اعتبارك أن المقياس هو زمن الانتقال لطلبات واجهة برمجة التطبيقات وأن ثلاث ثوانٍ هي الحد الأدنى للأداء الأمثل. تُظهر أوقات الاستجابة المصنفة لمدة ساعة لطلبات واجهة برمجة التطبيقات أن عدداً قليلاً من الطلبات يستغرق أكثر من ثلاث ثوانٍ، ويتلقى معظمها ردوداً في حدود الحد الأدنى. هذا هو السلوك المتوقع للنظام.
يهدف التوزيع المئوي إلى استبعاد القيم المتطرفة التي تسببها المشكلات المتقطعة. على سبيل المثال، إذا كانت استجابات الخدمة المناسبة في النسبة المئوية 90 أو 95، فسيتم استيفاء SLO.
اختيار فترات القياس المناسبة
فترة القياس لتحديد SLO مهمة للغاية. يجب أن تلتقط النشاط، وليس الخمول، حتى تكون النتائج ذات مغزى لتجربة المستخدم. يمكن أن تتراوح هذه النافذة من خمس دقائق إلى 24 ساعة اعتماداً على الطريقة التي تريد بها مراقبة وحساب مقياس SLI.
إنشاء عملية إدارة الأداء
يجب إدارة أداء واجهة برمجة التطبيقات من بدايتها حتى يتم تعطيلها أو إيقافها. يجب أن تكون هناك عملية إدارة قوية لضمان الكشف عن مشكلات الأداء وإصلاحها في وقت مبكر، قبل أن تتسبب في انقطاع كبير يؤثر على الأعمال.
فيما يلي عناصر إدارة الأداء:
- Performance Objectives: حدد SLO للأداء الطموح لسيناريوهات الأعمال.
- Performance Modeling: حدد سير العمل والعمليات التجارية الحيوية، وقم بإجراء النمذجة لفهم الآثار المرتبطة بالأداء. التقط هذه المعلومات بمستوى دقيق للحصول على تنبؤات أكثر دقة.
- Design Guidelines: قم بإعداد إرشادات تصميم الأداء والتوصية بالتعديلات المناسبة على سير عمل الأعمال. تأكد من أن الفرق تفهم هذه الإرشادات.
- Implement Guidelines: نفذ إرشادات تصميم الأداء لمكونات الحل، بما في ذلك الأجهزة اللازمة لتسجيل القياسات. قم بإجراء مراجعات تصميم الأداء. من الأهمية بمكان تتبع كل هذه العناصر باستخدام عناصر تراكم البنية للفرق المختلفة.
- Performance Testing: أجرِ اختبار الحمل والتحمل وفقاً لتوزيع ملف تعريف الحمل لتسجيل القياسات ذات الصلة بسلامة النظام الأساسي. يمكنك أيضاً إجراء هذه الاختبارات لحمولة محدودة لقياس متطلبات البنية الأساسية للحل.
- Bottleneck Analysis: استخدم فحص التعليمة البرمجية ومراجعات التعليمة البرمجية لتحديد وتحليل وإزالة معوقات الأداء في المكونات المختلفة. حدد تحسينات القياس الأفقية أو الرأسية المطلوبة لدعم أحمال الذروة.
- Continuous Monitoring: أنشئ بنية أساسية مستمرة للمراقبة والتنبيه كجزء من عمليات DevOps. تأكد من إخطار الفرق المعنية عندما تقل أوقات الاستجابة بشكل ملحوظ مقارنة بالمعايير.
- Performance Governance: أنشئ إدارة أداء تتألف من عمليات وفرق محددة جيداً للحفاظ على مستوى الأداء SLOs. تتبع الامتثال بعد كل إصدار لتجنب أي تدهور بسبب ترقيات البناء. قم بإجراء مراجعات دورية لتقييم أي حمل زائد لتحديد ترقيات الحل.
تأكد من تكرار الخطوات خلال مسار تطوير الحل الخاص بك كجزء من عملية التطوير التدريجي.
تتبُّع أهداف الأداء والتوقعات في الأعمال المتراكمة الخاصة بك
تتبع أهداف أدائك للمساعدة في ضمان تحقيقها. التقط قصص المستخدم الدقيقة والمفصلة لتتبعها. سيساعد ذلك على ضمان أن تجعل فرق التطوير أنشطة إدارة الأداء أولوية قصوى.
إنشاء SLOs الطموحة للحل المستهدف
في ما يلي عينة من SLO الطموحة لحل النظام الأساسي لواجهة برمجة التطبيقات قيد الدراسة:
- يستجيب لـ 95 بالمائة من جميع طلبات READ خلال يوم واحد في غضون ثانية واحدة.
- يستجيب لـ 95 بالمائة من جميع طلبات CREATE وUPDATE خلال يوم واحد في غضون ثلاث ثوانٍ.
- يستجيب لـ 99 بالمائة من جميع الطلبات خلال يوم واحد في غضون خمس ثوانٍ دون إخفاقات.
- يستجيب لـ 99.9 بالمائة من جميع الطلبات خلال يوم واحد بنجاح في غضون خمس دقائق.
- أقل من واحد بالمائة من الطلبات خلال ذروة خطأ النافذة لمدة ساعة واحدة.
يمكن تصميم SLO لتلائم متطلبات التطبيق المحددة. ومع ذلك، من الأهمية بمكان أن تكون دقيقاً بدرجة كافية للحصول على الوضوح لضمان الموثوقية.
قياس SLO الأولية التي تستند إلى البيانات من السجلات
يتم إنشاء سجلات المراقبة تلقائياً عندما تكون خدمة API قيد الاستخدام. افترض أن أسبوعاً من البيانات يظهر ما يلي:
- الطلبات: 123204
- عدد الطلبات الناجحة: 123204
- زمن الانتقال الذي أحرز 90 نقطة مئوية: 497 ملّي ثانية
- زمن الانتقال الذي أحرز 95 نقطة مئوية: 870 ملّي ثانية
- زمن الانتقال الذي أحرز 99 نقطة مئوية: 1024 ملّي ثانية
تنتج هذه البيانات SLIs الأولية التالية:
- التوفر = (123204 / 123456) = 99.8 بالمائة
- زمن الانتقال = تم تقديم ما لا يقل عن 90 بالمائة من الطلبات في غضون 500 ملّي ثانية
- زمن الانتقال = تم تقديم حوالي 98 بالمائة من الطلبات في غضون 1000 ملّي ثانية
افترض أنه، أثناء التخطيط، فإن هدف SLO الطموح لوقت الاستجابة هو أن تتم معالجة 90 بالمائة من الطلبات في غضون 500 ملّي ثانية بمعدل نجاح 99 بالمائة خلال فترة أسبوع واحد. باستخدام بيانات السجل، يمكنك بسهولة تحديد ما إذا كان قد تم تحقيق هدف SLO أم لا. إذا قمت بإجراء هذا النوع من التحليل لبضعة أسابيع، يمكنك البدء في رؤية الاتجاهات بشأن توافق SLO.
إرشادات لتقليل المخاطر الفنية
استخدم قائمة التحقق التالية للممارسات الموصى بها للتخفيف من مخاطر قابلية التوسع والأداء:
- تصميم للمقياس والأداء.
- تأكد من حصولك على متطلبات النطاق لكل سيناريو وحمل عمل مستخدم، بما في ذلك الحالات التي تتكرر كل حين والذروات.
- إجراء نمذجة الأداء لتحديد قيود النظام والازدحام
- قم بإدارة الديون الفنية.
- قم بتتبع مكثف لقياسات الأداء.
- ضع في اعتبارك استخدام البرامج النصية لتشغيل أدوات مثل K6.io وKarate وJMeter في بيئة مرحلة التطوير الخاصة بك مع مجموعة من أحمال المستخدم - 50 إلى 100 RPS، على سبيل المثال. سيوفر هذا معلومات في السجلات لاكتشاف مشكلات التصميم والتنفيذ.
- ادمج البرامج النصية للاختبار الآلي كجزء من عمليات التوزيع المستمر (CD) لاكتشاف فواصل البناء.
- امتلك عقلية إنتاج.
- اضبط حدود التحجيم التلقائي كما هو مبين في إحصاءات الحالة.
- فضِّل تقنيات القياس الأفقي على الرأسية.
- كن استباقياً مع التحجيم للتعامل مع الحالات التي تتكرر كل حين.
- أفضِّل التوزيع المستند إلى الحلقات.
- استخدم ميزانيات الخطأ للتجربة.
التسعير
تسير كل من الموثوقية وكفاءة الأداء وتحسين التكلفة جنباً إلى جنب. تساعد خدمات Azure المستخدمة في البنية على تقليل التكاليف، لأنها تتسع تلقائياً لتلائم أحمال المستخدم المتغيرة.
بالنسبة لـ AKS، يمكنك البدء مبدئياً باستخدام أجهزة VM ذات الحجم القياسي لتجمع العقدة. يمكنك بعد ذلك مراقبة متطلبات الموارد أثناء التطوير أو استخدام الإنتاج، وضبطها وفقاً لذلك.
يعد تحسين التكلفة أحد ركائز Microsoft Azure Well-Architected Framework. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة. لتقدير تكلفة منتجات وتكوينات Azure، استخدم حاسبة الأسعار.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- Subhajit Chatterjee | مهندس البرامج الرئيسي
الخطوات التالية
- وثائق Azure
- Microsoft Azure Well-Architected Framework
- نمط البنية للخدمات المصغرة
- تصميم لتوسيع النطاق
- اختر خدمة حوسبة Azure لتطبيقك
- أنماط التصميم والتنفيذ
- بنية الخدمات المصغرة في خدمة Azure Kubernetes
- ماذا يُقصد بـ Azure Front Door؟
- نبذة عن APIM
- ما هي وحدة تحكم دخول بوابة التطبيق؟
- Azure Kubernetes Service
- التحجيم التلقائي وApplication Gateway المكررة في المنطقة الإصدار 2
- Automatically scale a cluster to meet application demands on Azure Kubernetes Service (AKS)
- إنشاء حاويات وقواعد بيانات Azure Cosmos DB مع معدل نقل التحجيم التلقائي
- مستندات Microsoft Dynamics 365
- وثائق Microsoft 365
- وثائق هندسة موثوقية الموقع
- AZ-400: تطوير استراتيجية هندسة موثوقية الموقع (SRE)
- تطبيق ويب الأساس مع تكرار المنطقة