استخدام Azure API Management في حل متعدد المستأجرين
Azure API Management هي بوابة API شاملة ووكيل عكسي لواجهات برمجة التطبيقات. يوفر العديد من الميزات، بما في ذلك التخزين المؤقت، والسخرية من الاستجابة، ومدخل المطور، والتي تعد مفيدة للتطبيقات التي تركز على واجهة برمجة التطبيقات. تلخص هذه المقالة بعض الميزات الرئيسية لإدارة واجهة برمجة التطبيقات المفيدة للحلول متعددة المستأجرين.
إشعار
تركز هذه المقالة على كيفية استخدام APIM عندما يكون لديك تطبيقات متعددة المستأجرين الخاصة بك التي تستضيف واجهات برمجة التطبيقات للاستخدام الداخلي أو الخارجي.
شكل آخر من أشكال تعدد المستأجرين هو توفير بوابة إدارة واجهة برمجة التطبيقات كخدمة لفرق أخرى. على سبيل المثال، قد يكون لدى المؤسسة مثيل APIM مشترك تقوم فرق تطبيق متعددة بنشره واستخدامه. لا تناقش هذه المقالة هذا الشكل من تعدد المستأجرين. ضع في اعتبارك استخدام مساحات العمل، والتي تساعدك على مشاركة مثيل APIM عبر فرق متعددة قد يكون لديها مستويات مختلفة من الوصول.
نماذج العزل
عادة ما يتم نشر APIM كمكون مشترك مع مثيل واحد يخدم طلبات لمستأجرين متعددين. ومع ذلك، استنادا إلى نموذج الإيجار الخاص بك، هناك العديد من الطرق التي يمكنك من خلالها نشر APIM. تفترض هذه المقالة أنك تنشر الحل الخاص بك باستخدام طوابع التوزيع.
عادة ما تكون الطريقة التي تستخدم بها إدارة واجهة برمجة التطبيقات متشابهة، بغض النظر عن نموذج العزل. يركز هذا القسم على الاختلافات في التكلفة والتعقيد بين نماذج العزل وكيف يوجه كل نهج الطلبات إلى تطبيقات واجهة برمجة التطبيقات الخلفية.
الاعتبار | مثيل مشترك مع أطراف خلفية لمستأجر واحد | مثيل مشترك مع نهاية خلفية مشتركة متعددة المستأجرين | مثيل لكل مستأجر |
---|---|---|---|
عدد المستأجرين المدعومين | كثير | غير مقيد تقريبا | واحد لكل مثيل |
التكلفة | أدنى | أدنى | أعلى |
تعقيد التوزيع | منخفض: مثيل واحد لإدارته لكل طابع | منخفض: مثيل واحد لإدارته لكل طابع | عالي: مثيلات متعددة لإدارتها |
تعقيد تكوين التوجيه | أعلى | أدنى | أدنى |
القابلية لمشكلات الجيران المزعجة | نعم | نعم | لا |
عزل الشبكة على مستوى المستأجر | لا | لا | نعم |
سيناريو مثال | أسماء المجالات المخصصة لكل مستأجر | حل كبير متعدد المستأجرين مع مستوى تطبيق مشترك | طوابع التوزيع الخاصة المستأجر |
نماذج عزل المثيل المشترك
من الشائع مشاركة مثيل APIM بين مستأجرين متعددين، ما يساعد على تقليل التكلفة والتوزيع وتعقيد الإدارة. تعتمد تفاصيل كيفية مشاركة مثيل APIM على كيفية تعيين المستأجرين لتطبيقات واجهة برمجة التطبيقات الخلفية.
تطبيق خلفي لمستأجر واحد
إذا قمت بنشر تطبيقات خلفية مميزة لكل مستأجر، يمكنك نشر مثيل APIM واحد وتوجيه نسبة استخدام الشبكة إلى النهاية الخلفية للمستأجر الصحيح لكل طلب. يتطلب هذا الأسلوب تكوين إدارة واجهة برمجة التطبيقات مع أسماء المضيفين الخلفية لكل مستأجر أو أن يكون لديك طريقة أخرى لتعيين طلب وارد إلى النهاية الخلفية للمستأجر الصحيح.
لأنه يتطلب بحث إضافي، قد لا يتم توسيع هذا الأسلوب إلى أعداد كبيرة من المستأجرين الذين يشاركون مثيل APIM واحد. قد يكون هناك أيضا بعض النفقات العامة للأداء عند البحث عن نهاية المستأجر الخلفية. ومع ذلك، يعتمد حجم حمل الأداء هذا على كيفية تصميم مثل هذا البحث.
تطبيق خلفي مشترك متعدد المستأجرين
في السيناريوهات التي يشارك فيها المستأجرون تطبيقا خلفيا شائعا، يتم تبسيط عملية توجيه إدارة واجهة برمجة التطبيقات لأنه يمكنك توجيه جميع الطلبات إلى نهاية خلفية واحدة. إذا كنت تستخدم مجالات أحرف البدل أو المجالات الصادرة عن موفر الخدمة، فقد تتمكن من تحقيق مقياس غير مقيد تقريبا باستخدام هذا الأسلوب. أيضا، نظرا لعدم الحاجة إلى تعيين الطلبات إلى النهاية الخلفية للمستأجر، فلا يوجد تأثير على الأداء من قرارات التوجيه المخصصة.
مثيل لكل مستأجر
في بعض الحالات، قد تقوم بنشر مثيل APIM لكل مستأجر. نوصي بهذا النهج فقط إذا كان لديك عدد صغير من المستأجرين أو إذا كان لديك متطلبات امتثال صارمة تقيدك من مشاركة أي بنية أساسية بين المستأجرين. على سبيل المثال، إذا قمت بنشر شبكة ظاهرية مخصصة لكل مستأجر، فربما تحتاج أيضا إلى نشر مثيل APIM مخصص لكل مستأجر.
تلميح
إذا كان السبب الوحيد لنشر مثيلات متعددة هو دعم المستخدمين عبر مناطق جغرافية مختلفة، فقد ترغب في التفكير فيما إذا كانت ميزة النشر متعددة المناطق في APIM تفي بمتطلباتك.
عند نشر مثيل APIM، تحتاج إلى مراعاة حدود الخدمة، بما في ذلك أي حدود قد تنطبق على عدد مثيلات APIM داخل اشتراك أو منطقة Azure.
عادة ما يكون لمثيلات المستأجر الفردي تكوين توجيه بسيط لأنه يمكنك توجيه جميع الطلبات إلى نهاية خلفية واحدة. لا يتطلب هذا السيناريو قرارات توجيه مخصصة، لذلك لا يوجد أي تأثير إضافي على الأداء. ومع ذلك، عادة ما تتحمل تكلفة موارد أعلى مما لو قمت بنشر مثيل مشترك. إذا كنت بحاجة إلى نشر مثيلات المستأجر الفردي، ففكر فيما إذا كانت البوابات المستضافة ذاتيا تمكنك من إعادة استخدام موارد الحوسبة الخاصة المستأجر التي قمت بنشرها بالفعل.
ميزات APIM التي تدعم تعدد المستأجرين
تستخدم إدارة واجهة برمجة التطبيقات النهج لتمكين المرونة. يمكنك تخصيص كيفية التحقق من صحة الطلبات وتوجيهها ومعالجتها عند استخدام النهج. وعند تصميم حل متعدد المستأجرين باستخدام APIM، يمكنك استخدام النهج لتنفيذ العديد من قدراته.
تحديد المستأجرين على الطلبات الواردة
ضع في اعتبارك كيف يمكنك تحديد المستأجر المناسب داخل كل طلب وارد. في حل متعدد المستأجرين، من المهم أن يكون لديك فهم واضح لمن يقدم كل طلب بحيث تقوم بإرجاع البيانات لهذا المستأجر المحدد ولا أحد آخر.
توفر إدارة واجهة برمجة التطبيقات الاشتراكات التي يمكنك استخدامها لمصادقة الطلبات. تستخدم هذه الاشتراكات مفتاح اشتراك فريد يساعد على تحديد المشترك الذي يقوم بالطلب. إذا اخترت استخدام الاشتراكات، ففكر في كيفية تعيين اشتراكات APIM إلى معرفات المستأجر أو العميل الخاصة بك. يتم دمج الاشتراكات بإحكام في مدخل المطور. بالنسبة لمعظم الحلول، من الممارسات الجيدة استخدام الاشتراكات لتحديد المستأجرين.
بدلا من ذلك، يمكنك تحديد المستأجر باستخدام أساليب أخرى. فيما يلي بعض الأمثلة على الأساليب التي تعمل ضمن نهج مخصص تحدده:
استخدم مكونا مخصصا لعنصر URL، مثل مجال فرعي أو مسار أو سلسلة استعلام. على سبيل المثال، في عنوان URL
https://api.contoso.com/tenant1/products
، يمكنك استخراج الجزء الأول من المسار،tenant1
، والتعامل معه كمعرف مستأجر. وبالمثل، بالنظر إلى عنوان URLhttps://tenant1.contoso.com/products
الوارد ، يمكنك استخراج المجال الفرعي،tenant1
. لاستخدام هذا الأسلوب، ضع في اعتبارك تحليل المسار أو سلسلة الاستعلام من الخاصيةContext.Request.Url
.استخدم عنوان طلب. على سبيل المثال، قد تضيف تطبيقات العميل عنوانا مخصصا
TenantID
للطلبات. لاستخدام هذا الأسلوب، ضع فيContext.Request.Headers
اعتبارك القراءة من المجموعة.استخراج المطالبات من رمز ويب JSON المميز (JWT). على سبيل المثال، قد يكون لديك مطالبة مخصصة
tenantId
في JWT التي تم إصدارها من قبل موفر الهوية الخاص بك. لاستخدام هذا الأسلوب، استخدم نهج validate-jwt وقم بتعيين الخاصيةoutput-token-variable-name
بحيث يمكن لتعريف النهج قراءة القيم من الرمز المميز.ابحث عن معرفات المستأجر ديناميكيا. يمكنك الاتصال بقاعدة بيانات خارجية أو خدمة أثناء معالجة الطلب. باتباع هذا الأسلوب، يمكنك إنشاء منطق تعيين مستأجر مخصص لتعيين معرف مستأجر منطقي إلى عنوان URL معين أو للحصول على معلومات إضافية حول المستأجر. لاستخدام هذا الأسلوب، استخدم نهج إرسال الطلب .
من المحتمل أن يزيد هذا الأسلوب من زمن انتقال طلباتك. للتخفيف من هذا التأثير، من الجيد استخدام التخزين المؤقت لتقليل عدد الاستدعاءات إلى واجهة برمجة التطبيقات الخارجية. يمكنك استخدام نهج قيمة مخزن ذاكرة التخزين المؤقت وقيمة البحث عن ذاكرة التخزين المؤقت لتنفيذ نهج التخزين المؤقت. تأكد من إبطال ذاكرة التخزين المؤقت مع كل مستأجر تمت إضافته أو إزالته أو نقله يؤثر على البحث الخلفي.
القيم المسماة
تدعم API Management القيم المسماة، وهي إعدادات تكوين مخصصة يمكنك استخدامها في جميع نهجك. على سبيل المثال، قد تستخدم قيمة مسماة لتخزين عنوان URL الخلفي للمستأجر ثم إعادة استخدام نفس القيمة في عدة أماكن داخل النهج. إذا كنت بحاجة إلى تحديث عنوان URL، يمكنك تحديثه في مكان واحد.
تحذير
في حل متعدد المستأجرين، من المهم توخي الحذر عند تعيين أسماء القيم المسماة. إذا كانت الإعدادات تختلف بين المستأجرين، فتأكد من تضمين معرف المستأجر في الاسم. على سبيل المثال، يمكنك استخدام نمط مثل tenantId-key:value
بعد تأكيد أن tenantId
مناسب للطلب.
قم بتضمين المعرف لتقليل فرصة الإشارة عن طريق الخطأ إلى قيمة مستأجر آخر أو معالجتها عند معالجة طلب لمستأجر آخر.
مصادقة الطلبات الواردة
عادة ما تحتاج طلبات واجهة برمجة التطبيقات التي تم إجراؤها إلى بوابة APIM إلى المصادقة. توفر APIM عدة طرق لمصادقة الطلبات الواردة إلى البوابة، بما في ذلك OAuth 2.0 وشهادات العميل. ضع في اعتبارك أنواع بيانات الاعتماد التي يجب أن تدعمها وأين يجب التحقق من صحتها. على سبيل المثال، ضع في اعتبارك ما إذا كان يجب التحقق من الصحة في APIM أو في التطبيقات الخلفية أو في كلا المكانين.
لمزيد من المعلومات، راجع المصادقة والتخويل لواجهات برمجة التطبيقات في Azure API Management.
إشعار
إذا كنت تستخدم مفتاح اشتراك أو مفتاح API، فمن الممارسات الجيدة أيضا استخدام طريقة أخرى للمصادقة.
مفتاح الاشتراك وحده ليس شكلا قويا من أشكال المصادقة، ولكنه مفيد لسيناريوهات أخرى، مثل تعقب استخدام واجهة برمجة التطبيقات للمستأجر الفردي.
التوجيه إلى الأطراف الخلفية الخاصة بمستأجر
عند استخدام API Management كمكون مشترك، قد تحتاج إلى توجيه طلبات واجهة برمجة التطبيقات الواردة إلى أطراف خلفية مختلفة خاصة بالمستأجر. قد تكون هذه النهايات الخلفية في طوابع توزيع مختلفة، أو قد تكون تطبيقات مختلفة داخل طابع واحد. لتخصيص التوجيه في تعريف نهج، استخدم نهج set-backend-service . تحتاج إلى تحديد عنوان URL الأساسي الجديد الذي يجب إعادة توجيه الطلب إليه.
استجابات ذاكرة التخزين المؤقت أو بيانات أخرى
تحتوي APIM على ميزة ذاكرة تخزين مؤقت قوية يمكنك استخدامها لتخزين استجابات HTTP بالكامل أو أي بيانات أخرى. على سبيل المثال، يمكنك استخدام ذاكرة التخزين المؤقت لتعيينات المستأجر إذا كنت تستخدم منطقا مخصصا أو إذا كنت تبحث عن التعيين من خدمة خارجية.
استخدم نهج قيمة مخزن ذاكرة التخزين المؤقت وقيمة البحث عن ذاكرة التخزين المؤقت لتنفيذ نهج التخزين المؤقت.
تحذير
في حل متعدد المستأجرين، من المهم توخي الحذر عند تعيين مفاتيح ذاكرة التخزين المؤقت. إذا كانت البيانات المخزنة مؤقتا قد تختلف بين المستأجرين، فتأكد من تضمين معرف المستأجر في مفتاح ذاكرة التخزين المؤقت.
قم بتضمين المعرف لتقليل فرصة الإشارة عن طريق الخطأ إلى التلاعب به للإشارة إلى قيمة مستأجر آخر عند معالجة طلب لمستأجر آخر.
إضافة مجالات مخصصة
استخدم APIM لتكوين المجالات المخصصة الخاصة بك لبوابة واجهة برمجة التطبيقات ومدخل المطور. في بعض المستويات، يمكنك تكوين مجالات أحرف البدل أو أسماء مجالات متعددة مؤهلة بالكامل (FQDNs).
يمكنك أيضا استخدام APIM مع خدمة مثل Azure Front Door. في هذا النوع من التكوين، يتعامل Azure Front Door بشكل متكرر مع المجالات المخصصة وشهادات أمان طبقة النقل (TLS) ويتواصل مع APIM باستخدام اسم مجال واحد. إذا كان عنوان URL الأصلي من العميل يتضمن معلومات المستأجر التي تحتاج إلى إرسالها إلى مثيل APIM للمعالجة اللاحقة، ففكر في X-Forwarded-Host
استخدام عنوان الطلب، أو استخدم قواعد Azure Front Door لتمرير المعلومات كعنوان HTTP.
حدود السعر
من الشائع تطبيق الحصص النسبية أو حدود المعدل في حل متعدد المستأجرين. يمكن أن تساعدك حدود المعدلات على التخفيف من مشكلة الجوار المزعجة. يمكنك أيضا استخدام حدود المعدل لفرض جودة الخدمة والتمييز بين مستويات التسعير المختلفة.
استخدم إدارة واجهة برمجة التطبيقات لفرض حدود الأسعار الخاصة للمستأجر. إذا كنت تستخدم اشتراكات خاصة بالمستأجر، ففكر في استخدام نهج الحصة النسبية لفرض حصة نسبية لكل اشتراك. بدلا من ذلك، ضع في اعتبارك استخدام نهج الحصة النسبية حسب المفتاح لفرض الحصص النسبية باستخدام أي مفتاح حد سعر آخر، مثل معرف المستأجر الذي حصلت عليه من عنوان URL للطلب أو JWT.
تسييل
توفر وثائق APIM إرشادات شاملة حول تحقيق الدخل من واجهات برمجة التطبيقات، بما في ذلك نموذج التنفيذ. تجمع نهج تحقيق الدخل بين العديد من ميزات APIM بحيث يمكن للمطورين نشر واجهة برمجة تطبيقات وإدارة الاشتراكات والشحن استنادا إلى نماذج استخدام مختلفة.
إدارة القدرات
يدعم مثيل APIM قدرا معينا من السعة، والذي يمثل الموارد المتاحة لمعالجة طلباتك. عند استخدام نهج معقدة أو نشر المزيد من واجهات برمجة التطبيقات إلى المثيل، فإنك تستهلك المزيد من السعة. يمكنك إدارة سعة مثيل بعدة طرق، مثل شراء المزيد من الوحدات. يمكنك أيضا تغيير سعة المثيل ديناميكيا.
قد تستهلك بعض المثيلات متعددة المستأجرين سعة أكبر من مثيلات المستأجر الفردي، مثل إذا كنت تستخدم العديد من النهج لتوجيه الطلبات إلى نهايات خلفية مختلفة للمستأجر. ضع في اعتبارك تخطيط السعة بعناية، واخطط لتوسيع سعة المثيل الخاص بك إذا رأيت زيادة في استخدامك. يجب عليك أيضا اختبار أداء الحل الخاص بك لفهم احتياجات السعة الخاصة بك في وقت متقدم.
لمزيد من المعلومات حول تحجيم APIM، راجع ترقية مثيل إدارة واجهة برمجة تطبيقات Azure وتوسيع نطاقه.
عمليات النشر متعددة المواقع
تدعم إدارة واجهة برمجة التطبيقات عمليات النشر متعددة المناطق، ما يعني أنه يمكنك نشر مورد إدارة واجهة برمجة تطبيقات منطقي واحد عبر مناطق Azure متعددة دون الحاجة إلى نسخ التكوين الخاص به إلى موارد منفصلة. هذه الإمكانية مفيدة بشكل خاص عند توزيع الحل الخاص بك أو نسخه نسخا متماثلا على مستوى العالم. يمكنك نشر أسطول من مثيلات APIM بفعالية عبر مناطق متعددة، ما يسمح بمعالجة طلب زمن الانتقال المنخفض، وإدارتها كمثيل منطقي واحد.
ومع ذلك، إذا كنت بحاجة إلى مثيلات APIM معزولة بالكامل، فقد تختار أيضا توزيع موارد إدارة واجهة برمجة التطبيقات المستقلة في مناطق مختلفة. يفصل هذا الأسلوب مستوى الإدارة لكل مثيل APIM.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكتاب الرئيسيون:
- جون داونز | مهندس البرامج الرئيسي
- دانيال سكوت راينسفورد | الاستراتيجية التكنولوجية الشريكة، حلول الشركاء العالمية
المساهم الآخر:
- آرسن فلاديميرسكي | مهندس العملاء الرئيسي
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
راجع النهج المعمارية للتكامل في الحلول متعددة المستأجرين.