إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
إدارة واجهة برمجة تطبيقات Azure. هي خدمة مدارة بالكامل تساعد المؤسسات على نشر واجهات برمجة التطبيقات وتأمينها وتحويلها وصيانتها ومراقبتها. كخدمة Azure، توفر إدارة واجهة برمجة التطبيقات مجموعة من الإمكانات لدعم متطلبات الموثوقية الخاصة بك.
عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.
توضح هذه المقالة كيفية جعل إدارة واجهة برمجة التطبيقات مرنة لمجموعة متنوعة من الانقطاعات والمشاكل المحتملة، بما في ذلك الأخطاء العابرة وانقطاع منطقة التوفر وانقطاع التيار الكهربائي في المنطقة وصيانة الخدمة. كما يصف كيفية استخدام النسخ الاحتياطية للتعافي من أنواع أخرى من المشكلات، ويسلط الضوء على بعض المعلومات الأساسية حول اتفاقية مستوى خدمة إدارة واجهة برمجة التطبيقات (SLA).
نظرة عامة على بنية الموثوقية
تستخدم إدارة واجهة برمجة التطبيقات بنية قائمة على وحدة المقياس لتوفير التكرار المدمج وقابلية التوسع. عند نشر مثيل إدارة واجهة برمجة التطبيقات، يمكنك تكوين وحدة أو وحدةقياس واحدة أو أكثر. كل وحدة هي تمثيل منطقي للسعة التي تحتوي على موارد الحوسبة الضرورية لمعالجة طلبات واجهة برمجة التطبيقات.
عند تكوين مثيل بوحدتين أو أكثر، تعمل الوحدات المتوفرة معا لمعالجة الطلبات وتوفير موازنة التحميل التلقائية. إذا أصبحت إحدى الوحدات غير متوفرة، تستمر الوحدات المتبقية في التعامل مع حركة المرور، ولكن مع احتمال انخفاض السعة.
للحصول على مستويات أعلى من الموثوقية، تدعم APIM توزيع الوحدات عبر مناطق التوفر داخل منطقة وعبر مناطق متعددة.
توفر مستويات خدمة إدارة واجهة برمجة التطبيقات مستويات مختلفة من الموثوقية:
الفئة المميزة (الكلاسيكية): يدعم وحدات متعددة يمكن توزيعها عبر مناطق التوفر والمناطق لتحقيق أقصى قدر من المرونة. في المستوى Premium، تتكون كل وحدة من جهازين ظاهريين (VMs) يوفران موارد الحوسبة لمعالجة طلبات واجهة برمجة التطبيقات.
المستويات الأساسية v2 وStandard وStandard v2 وPremium v2 (معاينة): جميعها تدعم وحدات متعددة داخل مركز بيانات واحد. لا تدعم مناطق التوفر أو عمليات النشر متعددة المناطق.
فئة المطور: يدعم وحدة واحدة فقط ولا يوفر أي منطقة توفر أو دعم متعدد المناطق. تم تصميم هذه الطبقة لسيناريوهات التطوير والاختبار. إنه غير مناسب لأحمال عمل الإنتاج.
فئة الاستهلاك: لديه إمكانات مرونة مضمنة ومرن لمجموعة من الأخطاء داخل مركز بيانات Azure واحد. ومع ذلك، لا يوفر مستوى الاستهلاك الدعم لمناطق التوفر أو عمليات النشر متعددة المناطق. لفهم وقت التشغيل المتوقع لمثيل إدارة واجهة برمجة تطبيقات طبقة الاستهلاك، راجع اتفاقية مستوى الخدمة (SLA).
تعمل الوحدات داخل المثيل معا لمعالجة الطلبات وتحميل التوازن تلقائيا بين الوحدات المتاحة. إذا أصبحت الوحدة غير متوفرة، تستمر الوحدات المتبقية في التعامل مع حركة المرور، ولكن مع احتمال انخفاض السعة.
Note
تدعم مستويات المطور والمتميزة لإدارة واجهة برمجة التطبيقات البوابات المستضافة ذاتيا، والتي يمكنك تشغيلها على البنية الأساسية الخاصة بك. عند استخدام البوابات المستضافة ذاتيا، فأنت مسؤول عن تكوينها لتلبية متطلبات الموثوقية الخاصة بك. البوابات المستضافة ذاتيا خارج نطاق هذه المقالة.
توصيات نشر الإنتاج
يوفر Azure Well-Architected Framework توصيات عبر الموثوقية والأداء والأمان والتكلفة والعمليات. لفهم كيفية تأثير هذه المناطق على بعضها البعض والمساهمة في حل موثوق لإدارة واجهة برمجة التطبيقات، راجع أفضل ممارسات البنية لإدارة واجهة برمجة التطبيقات.
المرونة في مواجهة الأعطال العابرة
الأخطاء العابرة هي حالات فشل قصيرة متقطعة في المكونات. تحدث بشكل متكرر في بيئة موزعة مثل السحابة، وهي جزء طبيعي من العمليات. الأخطاء العابرة تصحح نفسها بعد فترة زمنية قصيرة. من المهم أن تتمكن تطبيقاتك من معالجة الأخطاء العابرة، عادة عن طريق إعادة محاولة الطلبات المتأثرة.
يجب أن تتبع جميع التطبيقات المستضافة على السحابة إرشادات معالجة الأخطاء العابرة ل Azure عند الاتصال بأي واجهات برمجة تطبيقات وقواعد بيانات ومكونات أخرى مستضافة على السحابة. لمزيد من المعلومات، راجع توصيات للتعامل مع الأخطاء العابرة.
عند استخدام إدارة واجهة برمجة التطبيقات أمام واجهة برمجة التطبيقات، قد تحتاج إلى إعادة محاولة الطلبات التي تفشل بسبب أخطاء عابرة. لحماية واجهة برمجة التطبيقات الخلفية من الارتباك بسبب عدد كبير جدا من الطلبات، توفر إدارة واجهة برمجة التطبيقات نهج إعادة المحاولة والحد من المعدل والحصص النسبية. يمكنك أيضا تكوين إمكانات موازنة الأحمال وقاطع الدائرة باستخدام موارد الواجهة الخلفية.
المرونة في مواجهة حالات فشل منطقة التوفر
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
توفر إدارة واجهة برمجة التطبيقات نوعين من دعم منطقة التوفر عند نشر مثيل إدارة واجهة برمجة التطبيقات المتميز (الكلاسيكي) في منطقة مدعومة:
تلقائي: توفر إدارة واجهة برمجة التطبيقات دعما تلقائيا لمنطقة التوفر عندما لا تحدد مناطق التوفر التي تريد استخدامها.
يدوي: توفر إدارة واجهة برمجة التطبيقات دعما يدويا لمنطقة التوفر عند تحديد مناطق التوفر المطلوب استخدامها بشكل صريح.
مع دعم منطقة التوفر، تقوم إدارة واجهة برمجة التطبيقات بنسخ مكونات الخدمة عبر المناطق للحصول على قابلية وصول عالية. في المنطقة الأساسية، تتضمن هذه المكونات البوابة (وحدات المقياس) و مستوى الإدارة ومدخل المطور. في المناطق الثانوية، يتم نسخ وحدات البوابة فقط. لمزيد من المعلومات حول المناطق الثانوية، راجع المرونة في مواجهة حالات الفشل على مستوى المنطقة.
دعم منطقة التوفر التلقائي
يمكنك استخدام دعم منطقة التوفر التلقائي لاختيار تكوين مثيل وحدة واحدة أو متعدد الوحدات لتحقيق تكرار المنطقة:
التكوين متعدد الوحدات (موصى به): إذا كان المثيل الخاص بك يحتوي على وحدتين أو أكثر، فإن إدارة واجهة برمجة التطبيقات تبذل قصارى جهدها لنشر وحدات المثيل بين مناطق توفر المنطقة. لا توجد طريقة لتحديد مناطق التوفر التي يتم وضع وحداتك فيها. نوصي بنشر وحدتين على الأقل، والتي يمكن توزيعها عبر منطقتين.
يوضح الرسم التخطيطي التالي مثيل إدارة واجهة برمجة التطبيقات بثلاث وحدات تم تكوينها لدعم منطقة التوفر التلقائي:
يوضح الرسم التخطيطي ثلاثة مربعات تسمى الوحدة 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 على أي وحدات.
Important
التثبيت في منطقة توفر واحدة فقط إذا كان زمن الانتقال عبر المناطق مرتفعا جدا بالنسبة لاحتياجاتك وبعد التحقق من أن زمن الانتقال لا يفي بمتطلباتك. في حد ذاته، لا يوفر مثيل المنطقة مرونة لانقطاع منطقة التوفر. لتحسين مرونة توزيع إدارة واجهة برمجة التطبيقات النطاقية، تحتاج إلى نشر مثيلات منفصلة بشكل صريح في مناطق توفر متعددة وتكوين توجيه نسبة استخدام الشبكة وتجاوز الفشل.
Requirements
دعم المنطقة: تدعم إدارة واجهة برمجة التطبيقات مناطق التوفر للطبقة المتميزة (الكلاسيكية) في جميع مناطق Azure التي تدعم مناطق التوفر.
متطلبات المستوى: يجب عليك استخدام الطبقة المميزة (الكلاسيكية) لتكوين دعم منطقة التوفر. لا تدعم إدارة واجهة برمجة التطبيقات حاليا مناطق التوفر في مستويات الاستهلاك والمطور والأساسي والقياسي الكلاسيكية أو في المستويات الأساسية v2 وStandard v2 وPremium v2. لترقية المثيل إلى المستوى Premium (الكلاسيكي)، راجع الترقية إلى المستوى المتميز.
Note
الطبقة المميزة v2 مع إمكانات المؤسسة قيد المعاينة. لتحديد ما إذا كان يجب أن يعتمد تصميمك على ميزات الوصول المبكر أو القدرات المتاحة بشكل عام، قم بتقييم المخططات الزمنية للتصميم والتنفيذ فيما يتعلق بالمعلومات المتوفرة حول مسارات الإصدار والترحيل من Premium v2.
Considerations
عدد وحدات المثيلات المكررة في المنطقة: إذا قمت بتكوين تكرار المنطقة يدويا لمثيل ما، فستحتاج أيضا إلى تكوين عدد من وحدات APIM التي يمكن توزيعها بالتساوي عبر جميع مناطق التوفر المحددة. على سبيل المثال، إذا حددت منطقتين، يجب تكوين وحدتين على الأقل. يمكنك بدلا من ذلك تكوين أربع وحدات، أو مضاعف آخر من وحدتين. إذا حددت ثلاث مناطق توفر، فيجب عليك تكوين ثلاث وحدات أو ست وحدات أو مضاعف آخر لثلاث وحدات.
إذا كنت تستخدم دعم منطقة التوفر التلقائي، فلا يوجد شرط لاستخدام عدد محدد من الوحدات. يتم توزيع الوحدات التي تقوم بنشرها بين مناطق التوفر بأفضل طريقة من الجهود. للحصول على أقصى قدر من التكرار في المنطقة، نوصي باستخدام وحدتين على الأقل للتأكد من أن انقطاع منطقة التوفر لا يؤثر على المثيل الخاص بك.
لتحديد عدد الوحدات التي توفر أداء البوابة المطلوب، استخدم مقاييس السعة والاختبار الخاص بك. لمزيد من المعلومات حول توسيع نطاق مثيل الخدمة الخاص بك وترقيته، راجع ترقية مثيل إدارة واجهة برمجة التطبيقات وتوسيع نطاقه.
التحجيم التلقائي: إذا قمت بتكوين مناطق التوفر يدويا على مثيل إدارة واجهة برمجة التطبيقات الذي تم تكوينه باستخدام التحجيم التلقائي، فقد تحتاج إلى ضبط إعدادات التحجيم التلقائي بعد التكوين. في هذه الحالة، يجب أن يكون عدد وحدات APIM في قواعد وحدود التحجيم التلقائي مضاعفا لعدد المناطق. إذا كنت تستخدم دعم منطقة التوفر التلقائي، فلن تحتاج إلى ضبط إعدادات التحجيم التلقائي.
متطلبات عنوان IP: عند تمكين دعم منطقة التوفر على مثيل إدارة واجهة برمجة التطبيقات الذي تم نشره في شبكة ظاهرية خارجية أو داخلية، يجب عليك تحديد مورد عنوان IP عام لاستخدام المثيل. في شبكة ظاهرية داخلية، يتم استخدام عنوان IP العام فقط لعمليات الإدارة، وليس لطلبات واجهة برمجة التطبيقات. لمزيد من المعلومات، راجع عناوين IP في إدارة واجهة برمجة التطبيقات.
Cost
بغض النظر عن تكوين منطقة التوفر الخاصة بك، إذا أضفت المزيد من الوحدات، فإنك تتحمل المزيد من التكاليف. للحصول على معلومات، راجع تسعير إدارة واجهة برمجة التطبيقات.
تكوين دعم منطقة التوفر
يشرح هذا القسم كيفية تكوين دعم منطقة التوفر لمثيل إدارة واجهة برمجة التطبيقات.
Note
عند تحديد مناطق التوفر التي يجب استخدامها، فإنك تحدد بالفعل منطقة التوفر المنطقية. إذا قمت بنشر مكونات حمل العمل الأخرى في اشتراك Azure مختلف، فقد تستخدم رقم منطقة توفر منطقية مختلفة للوصول إلى نفس منطقة التوفر الفعلية. لمزيد من المعلومات، راجع مناطق التوفر المادية والمنطقية.
قم بإنشاء مثيل إدارة واجهة برمجة التطبيقات الذي يدعم مناطق التوفر: عند إنشاء مثيل Premium (كلاسيكي) لإدارة واجهة برمجة التطبيقات في منطقة تدعم مناطق التوفر، يدعم المثيل مناطق التوفر افتراضيا. يمكنك تحديد دعم منطقة التوفر التلقائي أو تكوين الدعم المناطقي أو دعم المنطقة المكرر يدويا.
تمكين دعم منطقة التوفر أو إعادة تكوينه: يمكنك تغيير تكوين منطقة التوفر لمثيل APIM، بما في ذلك إضافة مناطق التوفر ونقل مثيل نطاقي بين مناطق التوفر. لمعرفة كيفية تكوين دعم منطقة التوفر على مثيل إدارة واجهة برمجة التطبيقات، راجع تمكين دعم منطقة التوفر على مثيلات إدارة واجهة برمجة التطبيقات. لا توجد متطلبات وقت تعطل لأي من خيارات التكوين.
عند تغيير تكوين منطقة التوفر، قد يستغرق تطبيق التغييرات من 15 إلى 45 دقيقة أو أكثر. يمكن لبوابة API Management الاستمرار في معالجة طلبات واجهة برمجة التطبيقات خلال هذا الوقت.
يؤدي تغيير تكوين منطقة التوفر إلى تغيير عنوان IP عام وخاصة.
تخطيط القدرات وإدارتها
في سيناريو انخفاض المنطقة، ليس هناك ما يضمن نجاح طلبات الحصول على المزيد من السعة في منطقة توفر أخرى. يتم ردم الوحدات المفقودة على أساس أفضل الجهود. إذا كنت بحاجة إلى سعة مضمونة عند فشل منطقة التوفر، فيجب عليك إنشاء مثيل إدارة واجهة برمجة التطبيقات وتكوينه لحساب فقدان منطقة عن طريق اتخاذ جميع الإجراءات التالية:
الإفراط في توفير وحدات مثيل إدارة واجهة برمجة التطبيقات.
استخدم التكوين التلقائي لمنطقة التوفر أو التكرار في المنطقة.
لمزيد من المعلومات، راجع إدارة السعة مع الإفراط في التوفير.
استخدم مقاييس السعة والاختبار الخاص بك لتحديد عدد الوحدات التي توفر أداء البوابة المطلوب. لمزيد من المعلومات حول كيفية توسيع نطاق مثيل الخدمة الخاص بك وترقيته، راجع ترقية مثيل إدارة واجهة برمجة التطبيقات وتوسيع نطاقه.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات إدارة واجهة برمجة التطبيقات مع دعم منطقة التوفر وتشغيل جميع مناطق التوفر.
توجيه نسبة استخدام الشبكة بين المناطق: أثناء العمليات العادية، يتم توجيه نسبة استخدام الشبكة بين جميع وحدات إدارة واجهة برمجة التطبيقات المتوفرة عبر جميع مناطق التوفر المحددة.
النسخ المتماثل للبيانات بين المناطق: تقوم إدارة واجهة برمجة التطبيقات بتخزين البيانات التالية وتكرارها.
تتم مزامنة تكوين البوابة، مثل واجهات برمجة التطبيقات وتعريفات النهج، بانتظام بين مناطق التوفر التي تحددها للمثيل. عادة ما يستغرق نشر التحديثات بين مناطق التوفر أقل من 10 ثوان.
البيانات الموجودة في ذاكرة التخزين المؤقت الداخلية، إذا كنت تستخدم ذاكرة التخزين المؤقت الداخلية التي توفرها إدارة واجهة برمجة التطبيقات. يتم توزيع إدخالات ذاكرة التخزين المؤقت بين مناطق التوفر. ذاكرة التخزين المؤقت الداخلية متقلبة والبيانات غير مضمونة لاستمرارها. ضع في اعتبارك استخدام ذاكرة تخزين مؤقت خارجية إذا كنت بحاجة إلى استمرار البيانات المخزنة مؤقتا.
عدادات حد المعدل، إذا كنت تستخدم إمكانات تحديد المعدل التي توفرها إدارة واجهة برمجة التطبيقات. يتم نسخ عدادات حد المعدل بشكل غير متزامن بين مناطق التوفر التي تحددها للمثيل.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات إدارة واجهة برمجة التطبيقات مع دعم منطقة التوفر وهناك انقطاع في منطقة التوفر.
الكشف والاستجابة: تعتمد مسؤولية الكشف والاستجابة على تكوين منطقة التوفر التي يستخدمها المثيل الخاص بك.
تلقائي ومتكرر في المنطقة: بالنسبة للمثيلات التي تم تكوينها لاستخدام دعم منطقة التوفر التلقائي أو التي تم تكوينها يدويا لاستخدام تكرار المنطقة، تكون منصة إدارة واجهة برمجة التطبيقات مسؤولة عن اكتشاف فشل في منطقة التوفر والاستجابة. لا تحتاج إلى القيام بأي شيء لبدء تجاوز فشل المنطقة.
المناطق: بالنسبة للمثيلات التي تم تكوينها لتكون منطقية، تحتاج إلى اكتشاف فقدان منطقة توفر وبدء تجاوز الفشل إلى مثيل ثانوي تقوم بإنشائه في منطقة توفر أخرى.
الطلبات النشطة: عندما تكون منطقة التوفر غير متوفرة، يتم إنهاء أي طلبات قيد التقدم متصلة بوحدة إدارة واجهة برمجة التطبيقات في منطقة التوفر المعيبة وتحتاج إلى إعادة المحاولة.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام Azure Service Health لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
فقدان البيانات المتوقع: تخزن إدارة واجهة برمجة التطبيقات البيانات التالية.
تغييرات تكوين البوابة، والتي يتم نسخها نسخا متماثلا إلى كل منطقة توفر محددة في غضون 10 ثوان تقريبا. في حالة حدوث انقطاع في منطقة توفر، قد تفقد تغييرات التكوين التي لم يتم نسخها نسخا.
البيانات في ذاكرة التخزين المؤقت الداخلية، إذا كنت تستخدم ميزة ذاكرة التخزين المؤقت الداخلية. ذاكرة التخزين المؤقت الداخلية متقلبة والبيانات غير مضمونة لاستمرارها. أثناء انقطاع منطقة التوفر ، قد تفقد بعض البيانات المخزنة مؤقتا أو جميعها. ضع في اعتبارك استخدام ذاكرة تخزين مؤقت خارجية إذا كنت بحاجة إلى استمرار البيانات المخزنة مؤقتا.
عدادات حد المعدل، إذا كنت تستخدم ميزة حد المعدل. أثناء انقطاع منطقة التوفر، قد لا تكون عدادات حد المعدل up-to-التاريخ في المناطق الباقية.
وقت التوقف المتوقع: يعتمد وقت التوقف المتوقع على تكوين منطقة التوفر التي يستخدمها المثيل الخاص بك.
تلقائي: يمكنك توقع عدم وجود وقت تعطل للمثيلات التي تستخدم دعم منطقة التوفر التلقائي أثناء انقطاع منطقة التوفر. تستمر الوحدات في المنطقة أو المناطق غير المتأثرة في العمل.
يمكنك أيضا توقع عدم وجود وقت تعطل للمثيلات التي تستخدم دعم منطقة التوفر التلقائي، ولكن لديها وحدة واحدة. في هذه الحالة، تقوم APIM بتوزيع الأجهزة الظاهرية الأساسية للوحدة على منطقتين. يستمر الجهاز الظاهري في المنطقة غير المتأثرة في العمل.
المنطقة الزائدة عن الحاجة: يمكنك توقع عدم وجود وقت تعطل للمثيلات الزائدة عن الحاجة في المنطقة أثناء انقطاع منطقة التوفر.
المناطق: بالنسبة للمثيلات المنطقية، عندما تكون المنطقة غير متوفرة، يكون المثيل الخاص بك غير متاح حتى يتم استرداد منطقة التوفر.
إعادة توجيه حركة المرور: يعتمد سلوك إعادة توجيه نسبة استخدام الشبكة على تكوين منطقة التوفر التي يستخدمها المثيل الخاص بك.
تلقائي ومتكرر في المنطقة: بالنسبة للمثيلات التي تم تكوينها لاستخدام دعم منطقة التوفر التلقائي أو التي تم تكوينها يدويا لاستخدام تكرار المنطقة، عندما تكون المنطقة غير متوفرة، تكون أي وحدات في المنطقة المتأثرة غير متوفرة أيضا. يمكنك اختيار تغيير حجم المثيل الخاص بك لإضافة المزيد من الوحدات.
المناطق: بالنسبة للمثيلات المنطقية، عندما تكون المنطقة غير متوفرة، يكون المثيل الخاص بك غير متاح. إذا كان لديك مثيل ثانوي في منطقة توفر أخرى، فأنت مسؤول عن إعادة توجيه نسبة استخدام الشبكة إلى هذا المثيل الثانوي.
استعادة المنطقة
يعتمد سلوك استرداد المنطقة على تكوين منطقة التوفر التي يستخدمها المثيل الخاص بك.
تلقائي ومتكرر في المنطقة: بالنسبة للمثيلات التي تم تكوينها لاستخدام دعم منطقة التوفر التلقائي أو التي تم تكوينها يدويا لاستخدام تكرار المنطقة، عند استرداد منطقة التوفر، تقوم إدارة واجهة برمجة التطبيقات تلقائيا باستعادة الوحدات في منطقة التوفر وإعادة توجيه حركة المرور بين وحداتك كالمعتاد.
المناطق: بالنسبة للمثيلات المنطقية، فأنت مسؤول عن إعادة توجيه نسبة استخدام الشبكة إلى المثيل في منطقة التوفر الأصلية بعد استرداد منطقة التوفر.
اختبار فشل المنطقة
تعتمد خيارات اختبار حالات فشل المنطقة على تكوين منطقة التوفر التي يستخدمها المثيل الخاص بك.
تلقائي ومتكرر في المنطقة: بالنسبة للمثيلات التي تم تكوينها لاستخدام دعم منطقة التوفر التلقائي أو التي تم تكوينها يدويا لاستخدام تكرار المنطقة، يدير النظام الأساسي لإدارة واجهة برمجة التطبيقات توجيه نسبة استخدام الشبكة وتجاوز الفشل وإرجاع الفشل. تتم إدارة هذه الميزة بالكامل، لذلك لا تحتاج إلى بدء عمليات فشل منطقة التوفر أو التحقق من صحتها.
المناطق: بالنسبة للمثيلات المناطقية، لا توجد طريقة لمحاكاة انقطاع منطقة التوفر التي تحتوي على مثيل إدارة واجهة برمجة التطبيقات. ومع ذلك، يمكنك تكوين بوابات المصدر أو موازنات التحميل يدويا لإعادة توجيه حركة المرور إلى مثيل مختلف في منطقة توفر مختلفة.
القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة
باستخدام التوزيع متعدد المناطق، يمكنك إضافة بوابات API إقليمية إلى مثيل APIM موجود في منطقة واحدة أو أكثر من مناطق Azure المدعومة. يساعد النشر متعدد المناطق على تقليل أي زمن انتقال للطلب ينظر إليه مستهلكو واجهة برمجة التطبيقات الموزعون جغرافيا. يعمل التوزيع متعدد المناطق أيضا على تحسين توفر الخدمة إذا كانت إحدى المناطق غير متصلة.
النشر متعدد المناطق الذي تديره Microsoft
تدعم إدارة واجهة برمجة التطبيقات عمليات النشر متعددة المناطق فقط في المستوى المتميز (الكلاسيكي). لا يدعم عمليات النشر متعددة المناطق في مستويات Consumption و Developer و Basic و Basic v2 و Standard و Standard v2 و Premium v2 (معاينة). لمزيد من المعلومات، راجع المتطلبات.
عند إضافة منطقة، فإنك تقوم بتكوين:
عدد الوحدات التي تستضيفها المنطقة.
المرونة في مواجهة حالات فشل منطقة التوفر، إذا كانت تلك المنطقة توفر مناطق توفر.
إعدادات الشبكة الظاهرية في المنطقة المضافة، إذا تم تكوين الشبكات في المنطقة أو المناطق الموجودة.
Requirements
دعم المنطقة: يمكنك إنشاء عمليات توزيع متعددة المناطق في المستوى المتميز (الكلاسيكي) مع أي منطقة Azure تدعم إدارة واجهة برمجة التطبيقات. لمعرفة المناطق التي تدعم عمليات النشر متعددة المناطق، راجع توفر المنتج حسب المنطقة.
متطلبات المستوى: يجب عليك استخدام المستوى المتميز (الكلاسيكي) لتكوين دعم متعدد المناطق. لترقية المثيل إلى المستوى Premium (الكلاسيكي)، راجع الترقية إلى المستوى المتميز.
Note
طبقة Premium v2 مع قدرات المؤسسة قيد المعاينة. لتحديد ما إذا كان يجب أن يعتمد تصميمك على ميزات الوصول المبكر أو القدرات المتاحة بشكل عام، قم بتقييم المخططات الزمنية للتصميم والتنفيذ فيما يتعلق بالمعلومات المتوفرة حول مسارات الإصدار والترحيل من Premium v2.
Considerations
البوابة فقط: يتم نسخ مكون البوابة لمثيل إدارة واجهة برمجة التطبيقات فقط إلى مناطق متعددة. تظل وحدة إدارة المثيل ومدخل المطور مستضافين فقط في المنطقة الأساسية حيث قمت بنشر الخدمة في الأصل.
متطلبات الشبكة: إذا كنت ترغب في تكوين موقع ثانوي لمثيل إدارة واجهة برمجة التطبيقات عند نشره (إدخاله) في شبكة ظاهرية، فيجب أن تتطابق الشبكة الظاهرية ومنطقة الشبكة الفرعية مع الموقع الثانوي الذي تقوم بتكوينه. إذا قمت بإضافة منطقة التوفر أو إزالتها أو تمكينها في المنطقة الأساسية، أو إذا قمت بتغيير الشبكة الفرعية للمنطقة الأساسية، فإن عنوان 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
تؤدي إضافة المناطق إلى تكليف. للحصول على معلومات، راجع تسعير إدارة واجهة برمجة التطبيقات.
تكوين الدعم متعدد المناطق
لتكوين دعم متعدد المناطق على مثيل إدارة واجهة برمجة التطبيقات، راجع توزيع مثيل إدارة واجهة برمجة التطبيقات إلى مناطق Azure متعددة.
لإزالة منطقة من مثيل إدارة واجهة برمجة التطبيقات، راجع إزالة منطقة خدمة إدارة واجهة برمجة التطبيقات.
تخطيط القدرات وإدارتها
في سيناريو انخفاض المنطقة، ليس هناك ما يضمن نجاح طلبات الحصول على المزيد من السعة في منطقة أخرى. إذا كنت بحاجة إلى سعة مضمونة عند فشل المنطقة، فيجب عليك إنشاء مثيل إدارة واجهة برمجة التطبيقات وتكوينه لحساب فقدان منطقة. يمكنك القيام بذلك عن طريق الإفراط في توفير سعة مثيل إدارة واجهة برمجة التطبيقات الخاص بك. لمعرفة المزيد حول مبدأ الإفراط في التوفير، راجع إدارة السعة مع الإفراط في التوفير.
في عمليات التوزيع متعددة المناطق، ينطبق التحجيم التلقائي فقط على المنطقة الأساسية. تتطلب المناطق الثانوية تعديلات تحجيم يدوية أو أدوات مخصصة تتحكم فيها.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات إدارة واجهة برمجة التطبيقات بدعم متعدد المناطق وتشغيل جميع المناطق.
توجيه حركة المرور بين المناطق: تقوم إدارة واجهة برمجة التطبيقات تلقائيا بتوجيه الطلبات الواردة إلى بوابة إقليمية. يتم توجيه طلب إلى البوابة الإقليمية بأقل زمن انتقال من العميل. إذا كنت بحاجة إلى استخدام نهج توجيه مختلف، يمكنك تكوين Traffic Manager الخاص بك باستخدام قواعد توجيه مخصصة. لمزيد من المعلومات، راجع استخدام التوجيه المخصص إلى البوابات الإقليمية لإدارة واجهة برمجة التطبيقات.
عندما يصل الطلب إلى بوابة إقليمية لإدارة واجهة برمجة التطبيقات، يتم توجيهه إلى واجهة برمجة التطبيقات الخلفية ما لم ترجع النهج استجابة مباشرة من البوابة، مثل استجابة مخزنة مؤقتا أو رمز خطأ. في حل متعدد المناطق، تحتاج إلى الحرص على التوجيه إلى مثيل واجهة برمجة التطبيقات الخلفية التي تفي بمتطلبات الأداء الخاصة بك. لمزيد من المعلومات، راجع توجيه استدعاءات واجهة برمجة التطبيقات إلى خدمات الواجهة الخلفية الإقليمية.
النسخ المتماثل للبيانات بين المناطق: تتم مزامنة تكوين البوابة، مثل واجهات برمجة التطبيقات وتعريفات النهج، بانتظام بين المناطق الأساسية والثانوية التي تضيفها. عادة ما يستغرق نشر التحديثات إلى البوابات الإقليمية أقل من 10 ثوان.
عدادات حد المعدل والبيانات الموجودة في ذاكرة التخزين المؤقت الداخلية خاصة بالمنطقة، لذا لا يتم نسخها نسخا متماثلا بين المناطق.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين مثيلات إدارة واجهة برمجة التطبيقات بدعم متعدد المناطق ويكون هناك انقطاع في إحدى المناطق التي تستخدمها.
الكشف والاستجابة: إدارة واجهة برمجة التطبيقات مسؤولة عن اكتشاف فشل في منطقة والفشل التلقائي في بوابة في إحدى المناطق الأخرى التي تقوم بتكوينها.
الطلبات النشطة: قد يتم إسقاط أي طلبات نشطة تتم معالجتها في المنطقة المعيبة ويجب إعادة محاولتها من قبل العميل.
فقدان البيانات المتوقع: لا تخزن إدارة واجهة برمجة التطبيقات البيانات، باستثناء عدادات التكوين وذاكرة التخزين المؤقت وحد المعدل.
يتم نسخ تغييرات التكوين إلى كل منطقة في غضون 10 ثوان تقريبا. في حالة حدوث انقطاع في منطقتك الأساسية، قد تفقد تغييرات التكوين التي لم يتم نسخها نسخا.
عدادات حد المعدل والبيانات الموجودة في ذاكرة التخزين المؤقت الداخلية خاصة بالمنطقة، لذا لا يتم نسخها نسخا متماثلا بين المناطق.
وقت التوقف المتوقع: لا يتوقع تعطل البوابة.
إذا أصبحت المنطقة الأساسية غير متصلة، تصبح وحدة إدارة واجهة برمجة التطبيقات ومدخل المطور غير متوفرة، ولكن تستمر المناطق الثانوية في خدمة طلبات واجهة برمجة التطبيقات باستخدام أحدث تكوين للبوابة.
إعادة توجيه حركة المرور: إذا أصبحت المنطقة غير متصلة بالإنترنت، يتم توجيه طلبات واجهة برمجة التطبيقات تلقائيا حول المنطقة الفاشلة إلى أقرب بوابة تالية.
انتعاش المنطقة
عند استرداد المنطقة الأساسية، تستعيد إدارة واجهة برمجة التطبيقات تلقائيا الوحدات في المنطقة وتعيد توجيه حركة المرور بين وحداتك.
اختبار حالات فشل المنطقة
لتكون جاهزا لانقطاعات المنطقة غير المتوقعة، نوصيك باختبار استجاباتك بانتظام لحالات فشل المنطقة. يمكنك محاكاة بعض جوانب فشل المنطقة عن طريق تعطيل التوجيه إلى بوابة إقليمية.
النسخ الاحتياطي والاستعادة
لا تخزن إدارة واجهة برمجة التطبيقات معظم بيانات وقت التشغيل. ومع ذلك، يمكنك نسخ تكوين خدمة إدارة واجهة برمجة التطبيقات احتياطيا. يمكنك أيضا استخدام عمليات النسخ الاحتياطي والاستعادة لنسخ تكوينات خدمة إدارة واجهة برمجة التطبيقات بين البيئات التشغيلية، على سبيل المثال، التطوير والتدريج.
Important
في إجراء النسخ الاحتياطي، يتم تضمين بيانات وقت التشغيل مثل المستخدمين والاشتراكات، وهو ما قد لا يكون مرغوبا فيه دائما.
يتم دعم النسخ الاحتياطي في مستويات المطور والأساسي والقياسي والمتميزة.
لمزيد من المعلومات، راجع كيفية تنفيذ التعافي من الكوارث باستخدام النسخ الاحتياطي للخدمة واستعادتها في إدارة واجهة برمجة التطبيقات.
للنسخ الاحتياطي أو استعادة بعض مكونات الخدمة أو الموارد، يمكنك أيضا التفكير في الخيارات المدارة من قبل العميل مثل أدوات APIOps والبنية الأساسية كحلول التعليمات البرمجية (IaC).
المرونة في صيانة الخدمة
تقوم إدارة واجهة برمجة التطبيقات بإجراء ترقيات منتظمة للخدمة وأشكال الصيانة الأخرى.
في المستويات الأساسية والقياسية والمتميزة (الكلاسيكية)، يمكنك تخصيص الوقت الذي يتلقى فيه المثيل تحديثا في عملية التحديث. إذا كنت بحاجة إلى التحقق من صحة تأثير الترقيات على حمل العمل الخاص بك، ففكر في تكوين مثيل اختبار لتلقي التحديثات في وقت مبكر من دورة التحديث، وتعيين مثيل الإنتاج لتلقي التحديثات في وقت متأخر من الدورة. يمكنك أيضا تحديد نافذة صيانة، وهو الوقت من اليوم الذي تريد أن يقوم فيه المثيل بتطبيق تحديثات الخدمة.
لمزيد من المعلومات، راجع تكوين إعدادات تحديث الخدمة لمثيلات إدارة واجهة برمجة التطبيقات.
اتفاقية مستوى الخدمة
تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.
عند نشر مثيل APIM في مناطق أو مناطق توفر متعددة، تزداد نسبة وقت التشغيل المحددة في اتفاقية مستوى الخدمة.
توفر الخدمة اتفاقية مستوى الخدمة الخاصة بها، ولكنك تحتاج أيضا إلى حساب الموثوقية المتوقعة لمكونات حمل العمل الأخرى، مثل الواجهات الخلفية لواجهة برمجة التطبيقات.