إرشادات تقييد واجهة برمجة التطبيقات ل Azure Data Manager للزراعة

يحد التقييد من عدد الطلبات إلى خدمة في فترة زمنية لمنع الإفراط في استخدام الموارد. يسمح تقييد واجهة برمجة تطبيقات REST في Azure Data Manager للزراعة بأداء أكثر اتساقا خلال فترة زمنية للعملاء الذين يتصلون بواجهات برمجة التطبيقات للخدمة.

يمكن ل Azure Data Manager for Agriculture معالجة حجم كبير من الطلبات. إذا حدث عدد هائل من الطلبات من عدد قليل من العملاء، يساعد التقييد في الحفاظ على الأداء الأمثل والموثوقية لجميع العملاء.

تعتمد حدود التقييد على الإصدار المحدد وقدرات المنتج الذي يستخدمه العميل. يدعم Azure Data Manager للزراعة إصدارين متميزين:

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

تعمل هذه الحدود في غضون ثلاث نوافذ زمنية (في دقيقة واحدة، لكل خمس دقائق، وكل شهر واحد) للحماية من الطفرات المفاجئة في حركة المرور.

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

تصنيف واجهات برمجة التطبيقات

تندرج واجهات برمجة تطبيقات Azure Data Manager للزراعة في ثلاث فئات رئيسية:

  • عمليات الكتابة: واجهات برمجة التطبيقات التي تستخدم أساليب REST API مثل PATCHو DELETEPOSTو لتغيير البيانات.
  • عمليات القراءة: واجهات برمجة التطبيقات التي تستخدم نوع GET أسلوب REST API لاسترداد البيانات، بما في ذلك واجهات برمجة تطبيقات البحث من نوع POSTالأسلوب .
  • عمليات الوظيفة طويلة الأمد: واجهات برمجة تطبيقات الوظائف غير المتزامنة طويلة الأمد التي تستخدم نوع PUTأسلوب REST API .

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

العملية تكلفة الوحدة لكل طلب
كتابة 5
قراءة 1 1
مهمة طويلة الأمد: استنتاج الحل 5
مهمة طويلة الأمد: عملية المزرعة 5
مهمة طويلة الأمد: نقطية الصورة 2
مهمة طويلة الأمد: الحذف المتتالي للكيان 2
وظيفة طويلة الأمد: استيعاب الطقس 1
وظيفة طويلة الأمد: استيعاب الأقمار الصناعية 1

1يتم أخذ تكلفة الوحدة الإضافية في الاعتبار لكل عنصر يتم إرجاعه في الاستجابة عند استرداد أكثر من عنصر واحد.

حدود واجهة برمجة التطبيقات للإصدار الأساسي

يسرد الجدول التالي إجمالي الوحدات المتوفرة لكل فئة للإصدار الأساسي:

العملية النافذة الزمنية للتقييد إعادة تعيين الوحدات بعد كل نافذة زمنية
الكتابة/القراءة في دقيقة واحدة 25,000
الكتابة/القراءة لكل خمس دقائق 100,000
الكتابة/القراءة كل شهر واحد 5,000,000
مهمة طويلة الأمد لكل خمس دقائق 1000
مهمة طويلة الأمد كل شهر واحد 100,000

حدود واجهة برمجة التطبيقات للإصدار القياسي

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

يسرد الجدول التالي إجمالي الوحدات المتوفرة لكل فئة للإصدار القياسي:

العملية النافذة الزمنية للتقييد إعادة تعيين الوحدات بعد كل نافذة زمنية
الكتابة/القراءة في دقيقة واحدة 25,000
الكتابة/القراءة لكل خمس دقائق 100,000
الكتابة/القراءة كل شهر واحد 25,000,000 1
مهمة طويلة الأمد لكل خمس دقائق 1000
مهمة طويلة الأمد كل شهر واحد 500,000 1

1هذا الحد هو خمسة أضعاف حد الإصدار الأساسي.

رمز الخطأ

عندما تصل إلى الحد الأقصى، تتلقى رمز حالة HTTP 429 طلبات كثيرة جدًا . تتضمن الاستجابة قيمة Retry-After ، والتي تحدد عدد الثوان التي يجب أن ينتظرها تطبيقك (أو وضع السكون) قبل إرسال الطلب التالي.

إذا أرسلت طلبا قبل انقضاء قيمة إعادة المحاولة، فلن تتم معالجة طلبك ويتم إرجاع قيمة إعادة محاولة جديدة. بعد انقضاء الوقت المحدد، يمكنك تقديم الطلبات مرة أخرى إلى Azure Data Manager for Agriculture. لا تتجاوز محاولة إنشاء اتصال TCP أو استخدام أساليب مصادقة مستخدم مختلفة هذه الحدود، لأنها خاصة بكل مستأجر.

الأسئلة المتداولة

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

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

كيف يمكنني حساب العدد الإجمالي للطلبات الناجحة المسموح بها لنافذة زمنية معينة؟

يعتمد العدد الإجمالي المسموح به لطلبات واجهة برمجة التطبيقات الناجحة على الإصدار الذي قمت بتوفيره والنافذة الزمنية التي تقوم فيها بتقديم الطلبات.

على سبيل المثال، باستخدام الإصدار القياسي، يمكنك جعل 25000 (إعادة تعيين الوحدات بعد كل نافذة زمنية) / 5 (تكلفة الوحدة لكل طلب) = 5000 واجهة برمجة تطبيقات لعملية الكتابة في غضون نافذة زمنية مدتها دقيقة واحدة. أو يمكنك استخدام مزيج من 4000 عملية كتابة و5000 عملية قراءة، مما يؤدي إلى 4000 * 5 + 5000 * 1 = 25000 وحدة إجمالية من الاستهلاك.

وبالمثل، بالنسبة للإصدار الأساسي، يمكنك تنفيذ 5000000 (إعادة تعيين الوحدات بعد كل نافذة زمنية) / 1 (تكلفة الوحدة لكل طلب) = 5000000 واجهة برمجة تطبيقات لعملية القراءة خلال نافذة زمنية لمدة شهر واحد.

كم عدد أحداث الاستشعار التي يمكن للعميل استيعابها كأقصى عدد؟

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

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