إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
إدارة واجهات برمجة تطبيقات Azure هي خدمة مدارة بالكامل تساعد المؤسسات على نشر وتأمين وتحويل وصيانة ومراقبة واجهات برمجة التطبيقات. كخدمة Azure، توفر إدارة واجهة برمجة التطبيقات مجموعة من الإمكانات لدعم متطلبات الموثوقية الخاصة بك.
عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.
توضح هذه المقالة كيفية جعل إدارة واجهة برمجة التطبيقات مرنة لمجموعة متنوعة من الانقطاعات والمشاكل المحتملة، بما في ذلك الأخطاء العابرة وانقطاع منطقة التوفر وانقطاع التيار الكهربائي في المنطقة وصيانة الخدمة. كما يصف كيفية استخدام النسخ الاحتياطية للتعافي من أنواع أخرى من المشكلات، ويسلط الضوء على بعض المعلومات الأساسية حول اتفاقية مستوى خدمة إدارة واجهة برمجة التطبيقات (SLA).
نظرة عامة على بنية الموثوقية
تستخدم إدارة واجهة برمجة التطبيقات بنية قائمة على وحدة المقياس لتوفير التكرار المدمج وقابلية التوسع. عند نشر مثيل إدارة واجهة برمجة التطبيقات، يمكنك تكوين وحدة أو وحدةقياس واحدة أو أكثر. كل وحدة هي تمثيل منطقي للسعة التي تحتوي على موارد الحوسبة الضرورية لمعالجة طلبات واجهة برمجة التطبيقات.
الوحدات
تتكون كل وحدة من موردين حسابيين (آلات افتراضية أو خوادم مشابهة، حسب مستوى الخدمة) يتعاملان مع طلبات واجهة برمجة التطبيقات معا. لا ترى هذه الأجهزة الافتراضية أو الخوادم الأخرى. تدير المنصة تلقائيا عملية إنشائها ومراقبتها الصحية. إذا تعطل مورد حسابي واحد، تستمر الوحدة في العمل ولكن بسعة أقل، مما يوفر بعض الحماية المدمجة للموثوقية.
عند تكوين مثيل بوحدتين أو أكثر، تعمل الوحدات المتوفرة معا لمعالجة الطلبات وتوفير موازنة التحميل التلقائية. إذا أصبحت إحدى الوحدات غير متوفرة، تستمر الوحدات المتبقية في التعامل مع حركة المرور، ولكن مع احتمال انخفاض السعة.
للحصول على مستويات أعلى من الموثوقية، تدعم APIM توزيع الوحدات عبر مناطق التوفر داخل منطقة وعبر مناطق متعددة.
ملحوظة
تستخدم إدارة API وحدات لمكونات البوابة. الوحدات غير مناسبة لبوابة المطور أو مستوى الإدارة.
مستويات الخدمة
توفر مستويات خدمة إدارة واجهة برمجة التطبيقات مستويات مختلفة من الموثوقية:
المستوى المتميز (الكلاسيكي): يدعم وحدات متعددة يمكنك توزيعها عبر مناطق التوفر والمناطق للحصول على أقصى قدر من المرونة.
مستويات Premium v2 وStandard v2: دعم وحدات متعددة يمكنك توزيعها عبر مناطق التوفر. لا يدعمون حاليا عمليات النشر متعددة المناطق.
المستويات الأساسية v2 والقياسية: تدعم جميعها وحدات متعددة داخل مركز بيانات واحد. لا تدعم مناطق التوفر أو عمليات النشر متعددة المناطق.
مستوى المطور: يدعم وحدة واحدة فقط ولا يوفر أي دعم لمنطقة التوفر أو متعدد المناطق. تم تصميم هذه الطبقة لسيناريوهات التطوير والاختبار. إنه غير مناسب لأحمال عمل الإنتاج.
فئة الاستهلاك: لديه إمكانات مرونة مضمنة ومرن لمجموعة من الأخطاء داخل مركز بيانات Azure واحد. ومع ذلك، لا يوفر مستوى الاستهلاك الدعم لمناطق التوفر أو عمليات النشر متعددة المناطق. لفهم وقت التشغيل المتوقع لمثيل إدارة واجهة برمجة تطبيقات طبقة الاستهلاك، راجع اتفاقية مستوى الخدمة (SLA).
ملحوظة
تدعم مستويات المطور والمتميزة لإدارة واجهة برمجة التطبيقات البوابات المستضافة ذاتيا، والتي يمكنك تشغيلها على البنية الأساسية الخاصة بك. عند استخدام البوابات المستضافة ذاتيا، فأنت مسؤول عن تكوينها لتلبية متطلبات الموثوقية الخاصة بك. البوابات المستضافة ذاتيا خارج نطاق هذه المقالة.
يلخص الجدول التالي ميزات الموثوقية القابلة للتكوين التي يدعمها كل مستوى. تشير علامة الاختيار الخضراء (
) إلى أن الطبقة تدعم الميزة.
| Tier | وحدات متعددة | المرونة في حالات فشل منطقة التوفر | المرونة في مواجهة حالات الفشل على مستوى المنطقة | النسخ الاحتياطي والاستعادة | المرونة في صيانة الخدمة |
|---|---|---|---|---|---|
| بريميوم (كلاسيكي) |
|
|
|
|
|
| الإصدار المميز v2 |
|
|
|
|
|
| قياسي v2 |
|
|
|
|
|
| الإصدار 2 الأساسي |
|
|
|
|
|
| المعيار |
|
|
|
|
|
| أساسي |
|
|
|
|
|
| المطور |
|
|
|
|
|
| Consumption |
|
|
|
|
|
توصيات نشر الإنتاج
يوفر Azure Well-Architected Framework توصيات عبر الموثوقية والأداء والأمان والتكلفة والعمليات. لفهم كيفية تأثير هذه المناطق على بعضها البعض والمساهمة في حل موثوق لإدارة واجهة برمجة التطبيقات، راجع أفضل ممارسات البنية لإدارة واجهة برمجة التطبيقات.
المرونة في مواجهة الأعطال العابرة
الأخطاء العابرة هي حالات فشل قصيرة متقطعة في المكونات. تحدث بشكل متكرر في بيئة موزعة مثل السحابة، وهي جزء طبيعي من العمليات. الأخطاء العابرة تصحح نفسها بعد فترة زمنية قصيرة. من المهم أن تتمكن تطبيقاتك من معالجة الأخطاء العابرة، عادة عن طريق إعادة محاولة الطلبات المتأثرة.
يجب أن تتبع جميع التطبيقات المستضافة على السحابة إرشادات معالجة الأخطاء العابرة ل Azure عند الاتصال بأي واجهات برمجة تطبيقات وقواعد بيانات ومكونات أخرى مستضافة على السحابة. لمزيد من المعلومات، راجع توصيات للتعامل مع الأخطاء العابرة.
عند استخدام إدارة واجهة برمجة التطبيقات أمام واجهة برمجة التطبيقات، قد تحتاج إلى إعادة محاولة الطلبات التي تفشل بسبب أخطاء عابرة. لحماية واجهة برمجة التطبيقات الخلفية من الارتباك بسبب عدد كبير جدا من الطلبات، توفر إدارة واجهة برمجة التطبيقات نهج إعادة المحاولة والحد من المعدل والحصص النسبية. يمكنك أيضا تكوين إمكانات موازنة الأحمال وقاطع الدائرة باستخدام موارد الواجهة الخلفية.
المرونة في مواجهة حالات فشل منطقة التوفر
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
لعرض معلومات حول دعم منطقة التوفر لمستويات Premium (الكلاسيكية) وPremium v2 وStandard v2، حدد مستوى الخدمة المناسب في بداية هذه المقالة.
توفر إدارة واجهة برمجة التطبيقات نوعين من دعم منطقة التوفر عند نشر مثيل إدارة واجهة برمجة التطبيقات المتميز (الكلاسيكي) في منطقة مدعومة:
تلقائي (موصى به): يوفر إدارة واجهات برمجة التطبيقات دعما تلقائيا لمنطقة التوفر عندما لا تحدد مناطق التوفر التي يجب استخدامها.
يدوي: توفر إدارة واجهة برمجة التطبيقات دعما يدويا لمنطقة التوفر عند تحديد مناطق التوفر المطلوب استخدامها بشكل صريح.
باستخدام دعم منطقة التوفر، تقوم APIM بنسخ مكونات الخدمة عبر المناطق للحصول على قابلية وصول عالية. في المنطقة الأساسية، تتضمن هذه المكونات البوابة (وحدات المقياس) و مستوى الإدارة ومدخل المطور. في المناطق الثانوية، يتم نسخ وحدات البوابة فقط. لمزيد من المعلومات حول المناطق الثانوية، راجع المرونة في مواجهة حالات الفشل على مستوى المنطقة.
دعم منطقة التوفر التلقائي
استخدم دعم منطقة التوفر التلقائي لاختيار إما تكوين مثيل أحادي الوحدة أو متعدد الوحدات لتحقيق تكرار المنطقة:
إعداد الوحدات المتعددة (موصى به): إذا كان جهازك يحتوي على وحدتين أو أكثر، تحاول إدارة API بأقصى جهد توزيع وحدات النسخة بين مناطق توفر المنطقة. لا يمكنك تحديد مناطق التوفر التي توضع فيها وحداتك. نشر وحدتين على الأقل، يمكن توزيعهما عبر منطقتين.
يوضح الرسم التخطيطي التالي مثيل إدارة واجهة برمجة التطبيقات بثلاث وحدات تم تكوينها لدعم منطقة التوفر التلقائي:
يوضح الرسم التخطيطي ثلاثة مربعات تسمى الوحدة 1 والوحدة 2 والوحدة 3 المنشورة في مثيل إدارة واجهة برمجة التطبيقات. يحتوي كل صندوق وحدة على أيقونين للآلة الافتراضية تمثل موارد الحوسبة. يتم تسمية ثلاثة مربعات أكبر باسم منطقة توافر الخدمات 1 ومنطقة توافر التوفر 2 ومنطقة توافر الخدمات 3. تحتوي المنطقة 1 على الوحدة 1 ، والمنطقة 2 تحتوي على الوحدة 2 ، والمنطقة 3 تحتوي على الوحدة 3.
تكوين الوحدة الواحدة: إذا كان لجهازك وحدة واحدة، فإن موارد الحوسبة الأساسية للوحدة توزع على منطقتين توافر. لا يمكنك تحديد مناطق التوفر التي توضع فيها موارد الحوسبة الخاصة بالوحدة.
يوضح الرسم التخطيطي مربعا واحدا يسمى الوحدة 1 المنشورة في مثيل إدارة واجهة برمجة التطبيقات. يحتوي صندوق الوحدة على أيقوتين للآلة الافتراضية تمثلان موارد الحوسبة. يتم تسمية ثلاثة مربعات أكبر باسم منطقة توافر الخدمات 1 ومنطقة توافر التوفر 2 ومنطقة توافر الخدمات 3. يمتد صندوق الوحدة 1 على المنطقتين 1 و 2. المنطقة 3 فارغة.
دعم منطقة التوفر اليدوي
إذا كنت ترغب في تحديد مناطق التوفر لاستخدامها بشكل صريح، يمكنك الاختيار بين تكوينات المنطقة المكررة والتقسيمية:
المنطقة الزائدة عن الحاجة: قم بتكوين تكرار المنطقة يدويا لمثيل إدارة واجهة برمجة التطبيقات في منطقة مدعومة لتوفير التكرار لمكونات الخدمة. عند تحديد منطقتين أو أكثر من مناطق التوفر لاستخدامها، يقوم Azure تلقائيا بنسخ مكونات الخدمة عبر المناطق المحددة.
يوضح الرسم التخطيطي ثلاثة مربعات تسمى الوحدة 1 والوحدة 2 والوحدة 3 المنشورة في مثيل إدارة واجهة برمجة التطبيقات. يحتوي كل صندوق وحدة على أيقونين للآلة الافتراضية تمثل موارد الحوسبة. يتم تسمية ثلاثة مربعات أكبر باسم منطقة توافر الخدمات 1 ومنطقة توافر التوفر 2 ومنطقة توافر الخدمات 3. تحتوي المنطقة 1 على الوحدة 1 ، والمنطقة 2 تحتوي على الوحدة 2 ، والمنطقة 3 تحتوي على الوحدة 3.
المناطق: يتم نشر مكونات خدمة إدارة واجهة برمجة التطبيقات في منطقة واحدة تحددها داخل منطقة Azure. يتم وضع جميع الوحدات في نفس منطقة التوفر.
يوضح الرسم التخطيطي مربعين بهما الوحدة 1 والوحدة 2 تم نشرهما في مثيل إدارة واجهة برمجة التطبيقات. يحتوي كل صندوق وحدة على أيقونين للآلة الافتراضية تمثل موارد الحوسبة. يتم تسمية ثلاثة مربعات أكبر باسم منطقة توافر الخدمات 1 ومنطقة توافر التوفر 2 ومنطقة توافر الخدمات 3. تحتوي المنطقة 1 على صندوقي الوحدة 1 والوحدة 2. لا تحتوي المنطقة 2 والمنطقة 3 على أي وحدات.
مهم
التثبيت في منطقة توفر واحدة فقط إذا كان زمن الانتقال عبر المناطق مرتفعا جدا بالنسبة لاحتياجاتك وبعد التحقق من أن زمن الانتقال لا يفي بمتطلباتك. في حد ذاته، لا يوفر مثيل المنطقة مرونة لانقطاع منطقة التوفر. لتحسين مرونة توزيع إدارة واجهة برمجة التطبيقات النطاقية، تحتاج إلى نشر مثيلات منفصلة بشكل صريح في مناطق توفر متعددة وتكوين توجيه نسبة استخدام الشبكة وتجاوز الفشل.
في مستويات Premium v2 وStandard v2، يمكنك تمكين تكرار المنطقة لمثيل APIM في منطقة مدعومة.
مع دعم منطقة التوافر، تقوم إدارة واجهة برمجة التطبيقات بمحاكاة البوابة (وحدات الحجم)، ومستوى الإدارة، وبوابة المطورين. يمكنك اختيار إما وحدة واحدة أو تكوين مثيل متعدد الوحدات لتحقيق تكرار المنطقة:
إعداد الوحدات المتعددة (موصى به): إذا كان جهازك يحتوي على وحدتين أو أكثر، تحاول إدارة API بأقصى جهد توزيع وحدات النسخة بين مناطق توفر المنطقة. لا يمكنك تحديد مناطق التوفر التي توضع فيها وحداتك. نشر وحدتين على الأقل، يمكن توزيعهما عبر منطقتين.
يوضح المخطط التالي مثيلا لإدارة واجهة برمجة التطبيقات يحتوي على ثلاث وحدات تم تكوينها لدعم مناطق التوفر:
يوضح الرسم التخطيطي ثلاثة مربعات تسمى الوحدة 1 والوحدة 2 والوحدة 3 المنشورة في مثيل إدارة واجهة برمجة التطبيقات. يحتوي كل صندوق وحدة على أيقونين للآلة الافتراضية تمثل موارد الحوسبة. يتم تسمية ثلاثة مربعات أكبر باسم منطقة توافر الخدمات 1 ومنطقة توافر التوفر 2 ومنطقة توافر الخدمات 3. تحتوي المنطقة 1 على الوحدة 1 ، والمنطقة 2 تحتوي على الوحدة 2 ، والمنطقة 3 تحتوي على الوحدة 3.
تكوين الوحدة الواحدة: إذا كان لجهازك وحدة واحدة، فإن موارد الحوسبة الأساسية للوحدة توزع على منطقتين توافر. لا يمكنك تحديد مناطق التوفر التي توضع فيها موارد الحوسبة الخاصة بالوحدة.
يوضح الرسم التخطيطي مربعا واحدا يسمى الوحدة 1 المنشورة في مثيل إدارة واجهة برمجة التطبيقات. يحتوي صندوق الوحدة على أيقوتين للآلة الافتراضية تمثلان موارد الحوسبة. يتم تسمية ثلاثة مربعات أكبر باسم منطقة توافر الخدمات 1 ومنطقة توافر التوفر 2 ومنطقة توافر الخدمات 3. يمتد صندوق الوحدة 1 على المنطقتين 1 و 2. المنطقة 3 فارغة.
متطلبات
دعم المنطقة: تدعم APIM مناطق التوفر لمستويات Premium (الكلاسيكية) وPremium v2 وStandard v2 في المناطق التي تتوفر فيها طبقة إدارة واجهة برمجة التطبيقات وتدعم المنطقة مناطق التوفر.
متطلبات المستوى: يجب استخدام المستويات Premium (الكلاسيكية) أو Premium v2 أو Standard v2 لتكوين دعم منطقة التوفر. لا تدعم APIM حاليا مناطق التوفر في مستويات الاستهلاك والمطور والأساسية والقياسية الكلاسيكية أو في المستوى Basic v2. لخيارات الترقية، راجع ترقية وتكبير نسخة إدارة واجهة برمجة التطبيقات (API).
الاعتبارات
عدد وحدات المثيلات المكررة في المنطقة: إذا قمت بتكوين تكرار المنطقة يدويا لمثيل ما، فستحتاج أيضا إلى تكوين عدد من وحدات APIM التي يمكن توزيعها بالتساوي عبر جميع مناطق التوفر المحددة. على سبيل المثال، إذا حددت منطقتين، يجب تكوين وحدتين على الأقل. يمكنك بدلا من ذلك تكوين أربع وحدات، أو مضاعف آخر من وحدتين. إذا حددت ثلاث مناطق توفر، فيجب عليك تكوين ثلاث وحدات أو ست وحدات أو مضاعف آخر لثلاث وحدات.
إذا كنت تستخدم دعم منطقة التوفر التلقائي، فلا يوجد شرط لاستخدام عدد محدد من الوحدات. يتم توزيع الوحدات التي تقوم بنشرها بين مناطق التوفر بأفضل طريقة من الجهود. للحصول على أقصى تكرار في المنطقة، استخدم وحدتين على الأقل حتى لا يؤثر انقطاع منطقة التوفر على أداء البوابة.
لتحديد عدد الوحدات التي توفر أداء البوابة المطلوب، استخدم مقاييس السعة والاختبار الخاص بك. لمزيد من المعلومات حول توسيع نطاق مثيل الخدمة الخاص بك وترقيته، راجع ترقية مثيل إدارة واجهة برمجة التطبيقات وتوسيع نطاقه.
التحجيم التلقائي: إذا قمت بتكوين مناطق التوفر يدويا على مثيل إدارة واجهة برمجة التطبيقات الذي تم تكوينه باستخدام التحجيم التلقائي، فقد تحتاج إلى ضبط إعدادات التحجيم التلقائي بعد التكوين. في هذه الحالة، يجب أن يكون عدد وحدات APIM في قواعد وحدود التحجيم التلقائي مضاعفا لعدد المناطق. إذا كنت تستخدم دعم منطقة التوفر التلقائي، فلن تحتاج إلى ضبط إعدادات التحجيم التلقائي.
متطلبات عنوان IP: عند تمكين دعم منطقة التوفر على مثيل إدارة واجهة برمجة التطبيقات الذي تم نشره في شبكة ظاهرية خارجية أو داخلية، يجب عليك تحديد مورد عنوان IP عام لاستخدام المثيل. في شبكة ظاهرية داخلية، يتم استخدام عنوان IP العام فقط لعمليات الإدارة، وليس لطلبات واجهة برمجة التطبيقات. لمزيد من المعلومات، راجع عناوين IP في إدارة واجهة برمجة التطبيقات.
الاعتبارات
عدد وحدات المثيلات المكررة في المنطقة: في مستويات Premium v2 أو Standard v2، لا تحتاج إلى استخدام عدد معين من الوحدات. يوزع التوزيع الوحدات بين مناطق التوفر بأفضل جهد. للحصول على أقصى تكرار في المنطقة، استخدم وحدتين على الأقل لتوفير سعة كافية حتى لا يؤثر انقطاع منطقة التوافر على أداء البوابة.
لتحديد عدد الوحدات التي توفر أداء البوابة المطلوب، استخدم مقاييس السعة والاختبار الخاص بك. لمزيد من المعلومات حول توسيع نطاق مثيل الخدمة الخاص بك وترقيته، راجع ترقية مثيل إدارة واجهة برمجة التطبيقات وتوسيع نطاقه.
التحجيم التلقائي: في مستويات Premium v2 أو Standard v2، لا تحتاج إلى ضبط إعدادات التحجيم التلقائي عند تمكين دعم منطقة التوفر.
Cost
بغض النظر عن تكوين منطقة التوفر الخاصة بك، إذا أضفت المزيد من الوحدات، فإنك تتحمل المزيد من التكاليف. للحصول على معلومات، راجع تسعير إدارة واجهة برمجة التطبيقات.
تكوين دعم منطقة التوفر
يشرح هذا القسم كيفية تكوين دعم منطقة التوفر لمثيل إدارة واجهة برمجة التطبيقات. لمزيد من المعلومات، راجع تمكين دعم مناطق التوفر في مثيلات إدارة واجهة برمجة التطبيقات.
قم بإنشاء مثيل إدارة واجهة برمجة التطبيقات الذي يدعم مناطق التوفر: عند إنشاء مثيل Premium (كلاسيكي) لإدارة واجهة برمجة التطبيقات في منطقة تدعم مناطق التوفر، يدعم المثيل مناطق التوفر افتراضيا. يمكنك تحديد دعم منطقة التوفر التلقائي أو تكوين الدعم المناطقي أو دعم المنطقة المكرر يدويا.
ملحوظة
عند تحديد مناطق التوفر التي يجب استخدامها، فإنك تحدد بالفعل منطقة التوفر المنطقية. إذا قمت بنشر مكونات حمل العمل الأخرى في اشتراك Azure مختلف، فقد تستخدم رقم منطقة توفر منطقية مختلفة للوصول إلى نفس منطقة التوفر الفعلية. لمزيد من المعلومات، راجع مناطق التوفر المادية والمنطقية.
تمكين دعم منطقة التوفر أو إعادة تكوينه: يمكنك تغيير تكوين منطقة التوفر لمثيل APIM، بما في ذلك إضافة مناطق التوفر ونقل مثيل نطاقي بين مناطق التوفر. لمعرفة كيفية تكوين دعم منطقة التوفر على مثيل إدارة واجهة برمجة التطبيقات، راجع تمكين دعم منطقة التوفر على مثيلات إدارة واجهة برمجة التطبيقات. لا تتطلب أي من خيارات التكوين وقتا للانتظار.
عند تغيير تكوين منطقة التوفر، قد يستغرق تطبيق التغييرات من 15 إلى 45 دقيقة أو أكثر. يمكن لبوابة API Management الاستمرار في معالجة طلبات واجهة برمجة التطبيقات خلال هذا الوقت.
يؤدي تغيير تكوين منطقة التوفر إلى تغيير عنوان IP عام وخاصة.
تكوين دعم منطقة التوفر
يشرح هذا القسم كيفية تكوين دعم منطقة التوفر لمثيل إدارة واجهة برمجة التطبيقات. لمزيد من المعلومات، راجع تمكين دعم مناطق التوفر في مثيلات إدارة واجهة برمجة التطبيقات.
إنشاء مثيل APIM يدعم مناطق التوفر: في مستويات Premium v2 أو Standard v2، قم بتمكين تكرار المنطقة اختياريا عند إنشاء مثيل APIM في منطقة تدعم مناطق التوفر. إذا لم يكن بالإمكان تفعيل تكرار المنطقة بسبب قيود السعة أو مشاكل أخرى، يفشل نشر الخدمة.
تمكين أو إعادة تكوين دعم منطقة التوافر: لا يمكنك تغيير تكوين منطقة التوفر بعد إنشاء النسخة.
تخطيط القدرات وإدارتها
في سيناريو خفض المناطق، لا يوجد ضمان لنجاح طلبات زيادة السعة في منطقة توفر أخرى. يتم ردم الوحدات المفقودة على أساس أفضل الجهود. إذا كنت بحاجة إلى سعة مضمونة عند فشل منطقة التوافر، أنشئ وقم بإعداد نسخة إدارة واجهة برمجة التطبيقات الخاصة بك لأخذ خسارة المنطقة في الاعتبار من خلال اتخاذ جميع الإجراءات التالية:
الإفراط في توفير وحدات مثيل إدارة واجهة برمجة التطبيقات.
استخدم التكوين التلقائي لمنطقة التوفر أو التكرار في المنطقة.
لمزيد من المعلومات، راجع إدارة السعة مع الإفراط في التوفير.
استخدم مقاييس السعة والاختبار الخاص بك لتحديد عدد الوحدات التي توفر أداء البوابة المطلوب. لمزيد من المعلومات حول كيفية توسيع نطاق مثيل الخدمة الخاص بك وترقيته، راجع ترقية مثيل إدارة واجهة برمجة التطبيقات وتوسيع نطاقه.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات إدارة واجهة برمجة التطبيقات مع دعم منطقة التوفر وتشغيل جميع مناطق التوفر.
توجيه نسبة استخدام الشبكة بين المناطق: أثناء العمليات العادية، توجه نسبة استخدام الشبكة بين جميع وحدات إدارة واجهة برمجة التطبيقات المتوفرة عبر جميع مناطق التوفر المحددة.
النسخ المتماثل للبيانات بين المناطق: تقوم إدارة واجهة برمجة التطبيقات بتخزين البيانات التالية وتكرارها.
تكوين البوابة، مثل واجهات برمجة التطبيقات وتعريفات السياسات، يتزامن بانتظام بين مناطق التوفر التي تختارها للمملة. عادة ما يستغرق نشر التحديثات بين مناطق التوفر أقل من 10 ثوان.
البيانات الموجودة في ذاكرة التخزين المؤقت الداخلية، إذا كنت تستخدم ذاكرة التخزين المؤقت الداخلية التي توفرها إدارة واجهة برمجة التطبيقات. يتم توزيع إدخالات ذاكرة التخزين المؤقت بين مناطق التوفر. ذاكرة التخزين المؤقت الداخلية متقلبة والبيانات غير مضمونة للاستمرار. ضع في اعتبارك استخدام ذاكرة تخزين مؤقت خارجية إذا كنت بحاجة إلى استمرار البيانات المخزنة مؤقتا.
عدادات حد المعدل، إذا كنت تستخدم إمكانات تحديد المعدل التي توفرها إدارة واجهة برمجة التطبيقات. يتم نسخ عدادات حد المعدل بشكل غير متزامن بين مناطق التوفر التي تحددها للمثيل.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات إدارة واجهة برمجة التطبيقات مع دعم منطقة التوفر وهناك انقطاع في منطقة التوفر.
الكشف والاستجابة: تعتمد مسؤولية الكشف والاستجابة على تكوين منطقة التوفر التي يستخدمها المثيل الخاص بك.
تلقائي ومتكرر في المنطقة: بالنسبة للمثيلات التي تم تكوينها لاستخدام دعم منطقة التوفر التلقائي أو التي تم تكوينها يدويا لاستخدام تكرار المنطقة، تكون منصة إدارة واجهة برمجة التطبيقات مسؤولة عن اكتشاف فشل في منطقة التوفر والاستجابة. لا تحتاج إلى القيام بأي شيء لبدء تجاوز فشل المنطقة.
المناطق: بالنسبة للمثيلات التي تم تكوينها لتكون منطقية، تحتاج إلى اكتشاف فقدان منطقة توفر وبدء تجاوز الفشل إلى مثيل ثانوي تقوم بإنشائه في منطقة توفر أخرى.
الطلبات النشطة: عندما تكون منطقة التوفر غير متوفرة، يتم إنهاء أي طلبات قيد التقدم متصلة بوحدة إدارة واجهة برمجة التطبيقات في منطقة التوفر المعيبة وتحتاج إلى إعادة المحاولة.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة مورد فردي، ويمكنك إعداد تنبيهات Resource Health لإعلامك بالمشاكل. يمكنك أيضا استخدام حالة خدمة Azure لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
فقدان البيانات المتوقع: تخزن إدارة واجهة برمجة التطبيقات البيانات التالية.
تغييرات تكوين البوابة، والتي يتم نسخها نسخا متماثلا إلى كل منطقة توفر محددة في غضون 10 ثوان تقريبا. في حالة حدوث انقطاع في منطقة توفر، قد تفقد تغييرات التكوين التي لم يتم نسخها نسخا.
البيانات في ذاكرة التخزين المؤقت الداخلية، إذا كنت تستخدم ميزة ذاكرة التخزين المؤقت الداخلية. ذاكرة التخزين المؤقت الداخلية متقلبة والبيانات غير مضمونة لاستمرارها. أثناء انقطاع منطقة التوفر ، قد تفقد بعض البيانات المخزنة مؤقتا أو جميعها. ضع في اعتبارك استخدام ذاكرة تخزين مؤقت خارجية إذا كنت بحاجة إلى استمرار البيانات المخزنة مؤقتا.
عدادات حد المعدل، إذا كنت تستخدم ميزة حد المعدل. أثناء انقطاع منطقة التوفر، قد لا تكون عدادات حد المعدل up-to-التاريخ في المناطق الباقية.
وقت التوقف المتوقع: يعتمد وقت التوقف المتوقع على تكوين منطقة التوفر التي يستخدمها المثيل الخاص بك.
تلقائي: يمكنك توقع عدم وجود وقت تعطل للمثيلات التي تستخدم دعم منطقة التوفر التلقائي أثناء انقطاع منطقة التوفر. تستمر الوحدات في المنطقة أو المناطق غير المتأثرة في العمل.
يمكنك أيضا توقع عدم وجود وقت تعطل للمثيلات التي تستخدم دعم منطقة التوفر التلقائي، ولكن لديها وحدة واحدة. في هذه الحالة، توزع إدارة API موارد الحوسبة الأساسية للوحدة إلى منطقتين. المورد في المنطقة غير المتأثرة لا يزال يعمل.
المنطقة الزائدة عن الحاجة: يمكنك توقع عدم وجود وقت تعطل للمثيلات الزائدة عن الحاجة في المنطقة أثناء انقطاع منطقة التوفر.
المناطق: بالنسبة للمثيلات المنطقية، عندما تكون المنطقة غير متوفرة، يكون المثيل الخاص بك غير متاح حتى يتم استرداد منطقة التوفر.
إعادة توجيه حركة المرور: يعتمد سلوك إعادة توجيه نسبة استخدام الشبكة على تكوين منطقة التوفر التي يستخدمها المثيل الخاص بك.
تلقائي ومتكرر في المنطقة: بالنسبة للمثيلات التي تم تكوينها لاستخدام دعم منطقة التوفر التلقائي أو التي تم تكوينها يدويا لاستخدام تكرار المنطقة، عندما تكون المنطقة غير متوفرة، تكون أي وحدات في المنطقة المتأثرة غير متوفرة أيضا. يمكنك اختيار تغيير حجم المثيل الخاص بك لإضافة المزيد من الوحدات.
المناطق: بالنسبة للمثيلات المنطقية، عندما تكون المنطقة غير متوفرة، يكون المثيل الخاص بك غير متاح. إذا كان لديك مثيل ثانوي في منطقة توفر أخرى، فأنت مسؤول عن إعادة توجيه نسبة استخدام الشبكة إلى هذا المثيل الثانوي.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات إدارة واجهة برمجة التطبيقات مع دعم منطقة التوفر وهناك انقطاع في منطقة التوفر.
الكشف والاستجابة: في مستويات Premium v2 أو Standard v2، يكون النظام الأساسي لإدارة واجهة برمجة التطبيقات مسؤولا عن الكشف عن فشل في منطقة توفر والاستجابة. لا تحتاج إلى القيام بأي شيء لبدء تجاوز فشل المنطقة.
الطلبات النشطة: عندما تكون منطقة التوفر غير متوفرة، يتم إنهاء أي طلبات قيد التقدم متصلة بوحدة إدارة واجهة برمجة التطبيقات في منطقة التوفر المعيبة وتحتاج إلى إعادة المحاولة.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة مورد فردي، ويمكنك إعداد تنبيهات Resource Health لإعلامك بالمشاكل. يمكنك أيضا استخدام حالة خدمة Azure لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
فقدان البيانات المتوقع: تخزن إدارة واجهة برمجة التطبيقات البيانات التالية.
تغييرات تكوين البوابة، والتي يتم نسخها نسخا متماثلا إلى كل منطقة توفر محددة في غضون 10 ثوان تقريبا. في حالة حدوث انقطاع في منطقة توفر، قد تفقد تغييرات التكوين التي لم يتم نسخها نسخا.
البيانات في ذاكرة التخزين المؤقت الداخلية، إذا كنت تستخدم ميزة ذاكرة التخزين المؤقت الداخلية. ذاكرة التخزين المؤقت الداخلية متقلبة والبيانات غير مضمونة لاستمرارها. أثناء انقطاع منطقة التوفر ، قد تفقد بعض البيانات المخزنة مؤقتا أو جميعها. ضع في اعتبارك استخدام ذاكرة تخزين مؤقت خارجية إذا كنت بحاجة إلى استمرار البيانات المخزنة مؤقتا.
عدادات حد المعدل، إذا كنت تستخدم ميزة حد المعدل. أثناء انقطاع منطقة التوفر، قد لا تكون عدادات حد المعدل up-to-التاريخ في المناطق الباقية.
توقعت فترة التوقف المتوقعة: يمكنك توقع أن الحالات لن يكون لديها أي وقت توقف أثناء انقطاع منطقة التوافر. تستمر الوحدات في المنطقة أو المناطق غير المتأثرة في العمل.
يمكنك أيضا توقع أن الحالات التي تحتوي على وحدة واحدة فقط لا تعاني من وقت توقف. في هذا التكوين، توزع إدارة API موارد الحوسبة الأساسية للوحدة إلى منطقتين. المورد في المنطقة غير المتأثرة لا يزال يعمل.
إعادة توجيه حركة المرور: عندما تكون المنطقة غير متاحة، تصبح أي وحدات في المنطقة المتأثرة غير متاحة أيضا. يمكنك توسيع جهازك لإضافة المزيد من الوحدات.
استعادة المنطقة
تلقائي ومتكرر في المنطقة: بالنسبة للمثيلات التي تم تكوينها لاستخدام دعم منطقة التوفر التلقائي أو التي تم تكوينها يدويا لاستخدام تكرار المنطقة، عند استرداد منطقة التوفر، تقوم إدارة واجهة برمجة التطبيقات تلقائيا باستعادة الوحدات في منطقة التوفر وإعادة توجيه حركة المرور بين وحداتك كالمعتاد.
المناطق: بالنسبة للمثيلات المنطقية، فأنت مسؤول عن إعادة توجيه نسبة استخدام الشبكة إلى المثيل في منطقة التوفر الأصلية بعد استرداد منطقة التوفر.
استعادة المنطقة
في مستويات Premium v2 أو Standard v2، عند استرداد منطقة التوفر، تقوم APIM تلقائيا باستعادة الوحدات في منطقة التوفر وإعادة توجيه نسبة استخدام الشبكة بين وحداتك كالمعتاد.
اختبار فشل المنطقة
تلقائي ومتكرر في المنطقة: بالنسبة للمثيلات التي تم تكوينها لاستخدام دعم منطقة التوفر التلقائي أو التي تم تكوينها يدويا لاستخدام تكرار المنطقة، يدير النظام الأساسي لإدارة واجهة برمجة التطبيقات توجيه نسبة استخدام الشبكة وتجاوز الفشل وإرجاع الفشل. تتم إدارة هذه الميزة بالكامل، لذلك لا تحتاج إلى بدء عمليات فشل منطقة التوفر أو التحقق من صحتها.
التصنيف: بالنسبة للحالات المناطقية، لا يمكنك محاكاة انقطاع في منطقة التوفر التي تحتوي على نسخة إدارة واجهة برمجة التطبيقات الخاصة بك. ومع ذلك، يمكنك تكوين بوابات المصدر أو موازنات التحميل يدويا لإعادة توجيه حركة المرور إلى مثيل مختلف في منطقة توفر مختلفة.
اختبار فشل المنطقة
في مستويات Premium v2 أو Standard v2، يدير النظام الأساسي لإدارة واجهة برمجة التطبيقات توجيه نسبة استخدام الشبكة وتجاوز الفشل وإرجاع الموارد. تتم إدارة هذه الميزة بالكامل، لذلك لا تحتاج إلى بدء عمليات فشل منطقة التوفر أو التحقق من صحتها.
القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة
باستخدام نشر متعدد المناطق، يمكنك إضافة بوابات API إقليمية إلى مثيل APIM موجود في منطقة واحدة أو أكثر من مناطق Azure المدعومة. يساعد التوزيع متعدد المناطق على تقليل أي زمن انتقال طلب يدركه مستهلكو واجهة برمجة التطبيقات الموزعون جغرافيا. يعمل التوزيع متعدد المناطق أيضا على تحسين توفر الخدمة إذا كانت إحدى المناطق غير متصلة بالإنترنت.
مهم
يتم دعم عمليات النشر متعددة المناطق فقط في المستوى المتميز (الكلاسيكي) من APIM.
لعرض معلومات حول دعم متعدد المناطق، حدد المستوى Premium (الكلاسيكي) في بداية هذه المقالة.
نشر متعدد المواقع المدارة Microsoft
عند إضافة منطقة، فإنك تقوم بتكوين:
عدد الوحدات التي تستضيفها المنطقة.
المرونة في فشل منطقة التوفر، إذا كانت المنطقة توفر مناطق توفر.
إعدادات الشبكة الظاهرية في المنطقة المضافة، إذا قمت بتكوين الشبكات في المنطقة أو المناطق الموجودة.
متطلبات
دعم المنطقة: يمكنك إنشاء عمليات نشر متعددة المناطق في المستوى Premium (الكلاسيكي) مع أي منطقة Azure تدعم APIM. لمعرفة المناطق التي تدعم عمليات التوزيع متعددة المناطق، راجع توفر المنتج حسب المنطقة.
متطلبات المستوى: يجب استخدام المستوى Premium (الكلاسيكي) لتكوين دعم متعدد المناطق. لترقية المثيل إلى المستوى Premium (الكلاسيكي)، راجع الترقية إلى المستوى المتميز.
الاعتبارات
البوابة فقط: يتم نسخ مكون البوابة لمثيل إدارة واجهة برمجة التطبيقات فقط إلى مناطق متعددة. تظل وحدة إدارة المثيل ومدخل المطور مستضافين فقط في المنطقة الأساسية حيث قمت بنشر الخدمة في الأصل.
متطلبات الشبكة: إذا كنت ترغب في تكوين موقع ثانوي لمثيل إدارة واجهة برمجة التطبيقات عند نشره (إدخاله) في شبكة ظاهرية، فيجب أن تتطابق الشبكة الظاهرية ومنطقة الشبكة الفرعية مع الموقع الثانوي الذي تقوم بتكوينه. إذا أضفت أو أزلت أو فعلت منطقة التوفر في المنطقة الأساسية، أو غيرت الشبكة الفرعية للمنطقة الأساسية، يتغير عنوان IP الافتراضي (VIP) لمثيل إدارة واجهة برمجة التطبيقات الخاصة بك. لمزيد من المعلومات، راجع التغييرات التي تم إجراؤها على عناوين IP. ومع ذلك، إذا أضفت منطقة ثانوية، فلن يتغير VIP للمنطقة الأساسية لأن كل منطقة لها VIP خاص بها.
أسماء نظام أسماء النطاقات (DNS): تحتوي البوابة في كل منطقة، بما في ذلك المنطقة الأساسية، على اسم DNS إقليمي يتبع نمط عنوان URL ل
https://<service-name>-<region>-01.regional.azure-api.net، على سبيل المثالhttps://contoso-westus2-01.regional.azure-api.net.
Cost
تؤدي إضافة المناطق إلى تكليف. للحصول على معلومات، راجع تسعير إدارة واجهة برمجة التطبيقات.
تكوين دعم متعدد المناطق
لتكوين دعم متعدد المناطق على مثيل APIM، راجع نشر مثيل APIM إلى مناطق Azure متعددة.
لإزالة منطقة من مثيل إدارة واجهة برمجة التطبيقات، راجع إزالة منطقة خدمة إدارة واجهة برمجة التطبيقات.
تخطيط القدرات وإدارتها
في سيناريو انخفاض المنطقة، لا يوجد ضمان لنجاح طلبات زيادة القدرة في منطقة أخرى. إذا كنت بحاجة إلى سعة مضمونة عند فشل المنطقة، فيجب عليك إنشاء مثيل إدارة واجهة برمجة التطبيقات وتكوينه لحساب فقدان منطقة. يمكنك القيام بذلك عن طريق الإفراط في توفير سعة مثيل إدارة واجهة برمجة التطبيقات الخاص بك. لمعرفة المزيد حول مبدأ الإفراط في التوفير، راجع إدارة السعة مع الإفراط في التوفير.
في عمليات النشر متعددة المناطق، ينطبق التحجيم التلقائي فقط على المنطقة الأساسية. تتطلب المناطق الثانوية تعديلات تحجيم يدوية أو أدوات مخصصة تتحكم فيها.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات APIM بدعم متعدد المناطق وتكون جميع المناطق قيد التشغيل.
توجيه حركة المرور بين المناطق: تقوم إدارة واجهة برمجة التطبيقات تلقائيا بتوجيه الطلبات الواردة إلى بوابة إقليمية. يتم توجيه طلب إلى البوابة الإقليمية بأقل زمن انتقال من العميل. إذا كنت بحاجة إلى استخدام نهج توجيه مختلف، يمكنك تكوين Traffic Manager الخاص بك باستخدام قواعد توجيه مخصصة. لمزيد من المعلومات، راجع استخدام التوجيه المخصص إلى البوابات الإقليمية لإدارة واجهة برمجة التطبيقات.
عندما يصل الطلب إلى بوابة إقليمية لإدارة واجهة برمجة التطبيقات، يتم توجيهه إلى واجهة برمجة التطبيقات الخلفية ما لم ترجع النهج استجابة مباشرة من البوابة، مثل استجابة مخزنة مؤقتا أو رمز خطأ. في حل متعدد المستويات، تحتاج إلى الحرص على التوجيه إلى مثيل واجهة برمجة التطبيقات الخلفية التي تفي بمتطلبات الأداء الخاصة بك. لمزيد من المعلومات، راجع توجيه استدعاءات واجهة برمجة التطبيقات إلى خدمات الواجهة الخلفية الإقليمية.
النسخ المتماثل للبيانات بين المناطق: تتم مزامنة تكوين البوابة، مثل واجهات برمجة التطبيقات وتعريفات النهج، بانتظام بين المناطق الأساسية والثانوية التي تضيفها. عادة ما يستغرق نشر التحديثات إلى البوابات الإقليمية أقل من 10 ثوان.
عدادات حدود المعدل والبيانات في الذاكرة المؤقتة الداخلية محددة للمنطقة، لذا لا يتم تكرارها بين المناطق.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات APIM بدعم متعدد المناطق وهناك انقطاع في إحدى المناطق التي تستخدمها.
الكشف والاستجابة: إدارة واجهة برمجة التطبيقات مسؤولة عن اكتشاف فشل في منطقة والفشل التلقائي في بوابة في إحدى المناطق الأخرى التي تقوم بتكوينها.
الطلبات النشطة: أي طلبات نشطة تتم معالجتها في المنطقة المعطوبة قد يتم إسقاطها ويجب على العميل إعادة تجربتها.
فقدان البيانات المتوقع: لا تخزن إدارة واجهة برمجة التطبيقات البيانات، باستثناء عدادات التكوين وذاكرة التخزين المؤقت وحد المعدل.
يتم نسخ تغييرات التكوين إلى كل منطقة في غضون 10 ثوان تقريبا. في حالة حدوث انقطاع في منطقتك الأساسية، قد تفقد تغييرات التكوين التي لم يتم نسخها نسخا.
عدادات حدود المعدل والبيانات في الذاكرة المؤقتة الداخلية محددة للمنطقة، لذا لا يتم تكرارها بين المناطق.
وقت التوقف المتوقع: لا يتوقع تعطل البوابة.
إذا توقفت المنطقة الأساسية عن الاتصال، تصبح طبقة إدارة واجهة برمجة التطبيقات وبوابة المطورين غير متاحة. ومع ذلك، تستمر المناطق الثانوية في خدمة طلبات واجهة برمجة التطبيقات باستخدام أحدث تكوين للبوابة.
إعادة توجيه حركة المرور: إذا أصبحت المنطقة غير متصلة بالإنترنت، يتم توجيه طلبات واجهة برمجة التطبيقات تلقائيا حول المنطقة الفاشلة إلى أقرب بوابة تالية.
انتعاش المنطقة
عند استرداد المنطقة الأساسية، تستعيد إدارة واجهة برمجة التطبيقات تلقائيا الوحدات في المنطقة وتعيد توجيه حركة المرور بين وحداتك.
اختبار حالات فشل المنطقة
للاستعداد لانقطاعات غير متوقعة في المناطق، اختبر استجاباتك لفشل المناطق بانتظام. يمكنك محاكاة بعض جوانب فشل المنطقة عن طريق تعطيل التوجيه إلى بوابة إقليمية.
النسخ الاحتياطي والاستعادة
لا تخزن إدارة واجهة برمجة التطبيقات معظم بيانات وقت التشغيل. ومع ذلك، يمكنك نسخ تكوين خدمة إدارة واجهة برمجة التطبيقات احتياطيا. يمكنك أيضا استخدام عمليات النسخ الاحتياطي والاستعادة لتكرار تكوينات خدمات إدارة واجهة برمجة التطبيقات بين البيئات التشغيلية، مثل التطوير والمرحلة.
مهم
يتضمن إجراء النسخ الاحتياطي بيانات وقت التشغيل مثل المستخدمين والاشتراكات، والتي قد لا تكون مرغوبة دائما.
يتم دعم النسخ الاحتياطي في مستويات المطور والأساسي والقياسي والمتميزة (الكلاسيكية).
لمزيد من المعلومات، راجع كيفية تنفيذ التعافي من الكوارث باستخدام النسخ الاحتياطي للخدمة واستعادتها في إدارة واجهة برمجة التطبيقات.
للنسخ الاحتياطي أو استعادة بعض مكونات الخدمة أو الموارد، يمكنك أيضا التفكير في الخيارات المدارة من قبل العميل مثل أدوات APIOps والبنية الأساسية كحلول التعليمات البرمجية (IaC).
المرونة في صيانة الخدمة
تقوم إدارة واجهة برمجة التطبيقات بإجراء ترقيات منتظمة للخدمة وأشكال الصيانة الأخرى.
في المستويات الأساسية والقياسية والمتميزة (الكلاسيكية) والمطور، يمكنك تخصيص عندما يتلقى المثيل تحديثا في عملية التحديث. إذا كنت بحاجة إلى التحقق من صحة تأثير الترقيات على حمل العمل الخاص بك، ففكر في تكوين مثيل اختبار لتلقي التحديثات في وقت مبكر من دورة التحديث، وتعيين مثيل الإنتاج لتلقي التحديثات في وقت متأخر من الدورة. يمكنك أيضا تحديد نافذة صيانة، وهو الوقت من اليوم الذي تريد أن يقوم فيه المثيل بتطبيق تحديثات الخدمة.
لمزيد من المعلومات، راجع تكوين إعدادات تحديث الخدمة لمثيلات إدارة واجهة برمجة التطبيقات.
اتفاقية مستوى الخدمة
تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.
عند نشر مثيل APIM في مناطق أو مناطق توفر متعددة، تزداد نسبة وقت التشغيل المحددة في اتفاقية مستوى الخدمة.
توفر الخدمة اتفاقية مستوى الخدمة الخاصة بها، ولكنك تحتاج أيضا إلى حساب الموثوقية المتوقعة لمكونات حمل العمل الأخرى، مثل الواجهات الخلفية لواجهة برمجة التطبيقات.