تقييد الطلبات المتقدم باستخدام Azure API Management

ينطبق على: جميع مستويات إدارة واجهة برمجة التطبيقات

القدرة على تقييد الطلبات الواردة هو دور رئيسي لـ Azure API Management. إما عن طريق التحكم في معدل الطلبات أو إجمالي الطلبات / البيانات المنقولة، تسمح API Management لمقدمي API بحماية واجهات برمجة التطبيقات الخاصة APIs بهم من سوء الاستخدام وإنشاء قيمة لمختلف مستويات منتجات API.

حدود الأسعار والحصص النسبية

وتُستخدم حدود الأسعار والحصص لأغراض مختلفة.

حدود السعر

عادة ما تستخدم حدود الأسعار للحماية من دفعات قصيرة ومكثفة الحجم. على سبيل المثال، إذا كنت تعرف أن خدمة الواجهة الخلفية الخاصة بك بها ازدحام في قاعدة البيانات الخاصة بها مع حجم استدعاء مرتفع، يمكنك تعيين نهج rate-limit-by-key لعدم السماح بارتفاع حجم الاستدعاء باستخدام هذا الإعداد.

تنبيه

نظرًا للطبيعة الموزعة للهندسة المعمارية ذات التقييد، فإن الحد من المعدل ليس دقيقًا تمامًا. يختلف الاختلاف بين العدد الذي تم تكوينه والعدد الفعلي للطلبات المسموح بها بناءً على حجم الطلب وسعره وزمن انتقال الخلفية وعوامل أخرى.

الحصص النسبية

تستخدم الحصص النسبية عادة للتحكم في أسعار الاستدعاء على مدى فترة زمنية أطول. على سبيل المثال، يمكنهم تعيين إجمالي عدد الاستدعاءات التي يمكن لمشترك معين إجراؤها خلال شهر معين. لتحقيق الدخل من واجهة برمجة التطبيقات API، يمكن أيضًا تعيين الحصص النسبية بشكل مختلف للاشتراكات المستندة إلى المستويات. على سبيل المثال، قد يتمكن اشتراك المستوى الأساسي من إجراء ما لا يزيد عن 10,000 استدعاء شهريًّا، ولكن قد يصل مستوى Premium إلى 100,000,000 استدعاء شهريًّا.

ضمن إدارة Azure API Management، عادة ما يتم نشر حدود الأسعار بشكل أسرع عبر العقد للحماية من الارتفاعات المفاجئة. وعلى العكس، يتم استخدام معلومات الحصة النسبية للاستخدام على المدى الطويل، وبالتالي فإن تطبيقها مختلف.

إشعار

عند إعادة تشغيل موارد الحوسبة الأساسية في النظام الأساسي للخدمة، قد تستمر APIM برمجة التطبيقات في معالجة الطلبات لفترة قصيرة بعد الوصول إلى الحصة النسبية.

تقييد قائم على المنتج

تعتبر إمكانيات اختناق الأسعار التي يتم تحديد نطاقها لاشتراك معين مفيدة لموفر API لتطبيق حدود على المطورين الذين قاموا بالتسجيل لاستخدام واجهة برمجة التطبيقات API الخاصة بهم. ومع ذلك، فإنه لا يساعد، على سبيل المثال، في تقييد المستخدمين النهائيين الفرديين API. من الممكن لمستخدم واحد من تطبيق المطور أن يستهلك الحصة النسبية بأكملها ومن ثم منع العملاء الآخرين للمطور من أن يكونوا قادرين على استخدام التطبيق. أيضًا، يقوم العديد من العملاء الذين قد يقومون بإنشاء حجم كبير من الطلبات بالحد من الوصول إلى المستخدمين العرضيين.

اختناق مخصص يستند إلى مفتاح

إشعار

نهج rate-limit-by-key وquota-by-key غير متوفرة عندما تكون في مستوى الاستهلاك من Azure API Management. النهج quota-by-key أيضا غير متوفر حاليا في مستويات v2.

وتوفر سياسات rate-limit-by-key وquota-by-key حلًّا أكثر مرونة لمراقبة حركة المرور. تسمح لك هذه النهج بتعريف التعبيرات لتحديد المفاتيح المستخدمة لتعقب استخدام حركة المرور. الطريقة التي يعمل بها هذا هو أسهل يتضح مع مثال.

تقييد عنوان IP

تُقيّد النُّهج التالية عنوان IP لعميل واحد إلى 10 مكالمات فقط كل دقيقة، مع إجمالي 1,000,000 استدعاء و10,000 كيلوبايت من النطاق الترددي شهريًّا.

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

<quota-by-key calls="1000000"
          bandwidth="10000"
          renewal-period="2629800"
          counter-key="@(context.Request.IpAddress)" />

إذا كان كافة العملاء على الإنترنت يستخدمون عنوان IP فريدًا، فقد تكون هذه طريقة فعالة للحد من الاستخدام من قبل المستخدم. ومع ذلك، فمن المحتمل أن العديد من المستخدمين يشاركون عنوان IP عامًّا واحدًا بسبب الوصول إلى الإنترنت عبر جهاز NAT. على الرغم من هذا، واجهات برمجة التطبيقات API التي تسمح بوصول IpAddress غير مصادق عليه قد نكون الخيار الأفضل.

تقييد هوية المستخدم

إذا تمت مصادقة مستخدم، يمكن إنشاء مفتاح اختناق استنادًا إلى المعلومات التي تعرف هذا المستخدم بشكل فريد.

<rate-limit-by-key calls="10"
    renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />

يوضح هذا المثال كيفية استخراج عنوان التخويل وتحويله إلى كائن JWT واستخدام موضوع الرمز المميز لتعريف المستخدم واستخدام ذلك كمفتاح تحديد السعر. إذا تم تخزين هوية المستخدم في JWT واحدة من المطالبات الأخرى، ثم يمكن استخدام هذه القيمة في مكانها.

السياسات المشتركة

على الرغم من أن نُهج الاختناق المستندة إلى المستخدم توفر تحكمًا أكبر من نهج الاختناق المستندة إلى الاشتراك، لا تزال هناك قيمة تجمع بين كلتا القدرتين. يعد التحكم حسب مفتاح الاشتراك في المنتج (الحد من معدل الاستدعاء حسب الاشتراك وتعيين حصة الاستخدام حسب الاشتراك) طريقة رائعة لتمكين تحقيق الدخل من واجهة برمجة التطبيقات API عن طريق فرض رسوم استنادًا إلى مستويات الاستخدام. التحكم الدقيق في القدرة على التقييد من قبل المستخدم هو متمم ويمنع سلوك مستخدم واحد من الحط من تجربة آخر.

تقييد يعتمد على العميل

عند تعريف مفتاح اختناق باستخدام تعبير نهج، ثم موفر API الذي يتم اختيار كيفية يتم نطاق اختناق. ومع ذلك، قد يرغب المطور في التحكم في كيفية تحديد معدل عملائه. يمكن تمكين هذا من قبل موفر API عن طريق تقديم رأس مخصص للسماح لتطبيق العميل المطور للاتصال المفتاح إلى API.

<rate-limit-by-key calls="100"
          renewal-period="60"
          counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>

وهذا يمكن تطبيق العميل المطور لاختيار الطريقة التي تريد إنشاء مفتاح الحد من معدل. يمكن لمطوري العميل إنشاء مستويات الأسعار الخاصة بهم عن طريق تخصيص مجموعات من المفاتيح للمستخدمين وتناوب استخدام المفتاح.

الملخص

توفر إدارة واجهة برمجة تطبيقات API Azure معدل تقييد حصة نسبية لحماية خدمة API وإضافتها. تسمح لك سياسات الاختناق الجديدة التي لها قواعد تحديد النطاق المخصصة بالتحكم الدقيق في هذه السياسات لتمكين عملائك من إنشاء تطبيقات أفضل. توضح الأمثلة في هذه المقالة استخدام هذه النهج الجديدة بواسطة مفاتيح تحديد معدل التصنيع مع عناوين IP العميل وهوية المستخدم والقيم التي أنشأها العميل. ومع ذلك، هناك العديد من أجزاء أخرى من الرسالة التي يمكن استخدامها مثل عامل المستخدم، أجزاء مسار URL، حجم الرسالة.

الخطوات التالية

يرجى إعطاؤنا ملاحظاتك كمشكلة GitHub لهذا الموضوع. سيكون من الرائع أن نسمع عن القيم الرئيسية المحتملة الأخرى التي كانت خيارًا منطقيًّا في سيناريوهاتك.