معالجة مشكلات التقييد (429 - أخطاء "عدد كبير جداً من الطلبات") في Azure Logic Apps
ينطبق على: Azure Logic Apps (الاستهلاك + قياسي)
إذا واجه سير عمل تطبيق المنطق التقييد، والذي يحدث عندما يتجاوز عدد الطلبات المعدل الذي يمكن للوجهة التعامل معه خلال فترة زمنية محددة، فستحصل على الخطأ "طلبات كثيرة جدا" HTTP 429. يمكن أن ينشأ عن التقييد مشكلات مثل تأخر معالجة البيانات وتقليل سرعة الأداء وظهور أخطاء مثل تجاوز نهج إعادة المحاولة المحدد.
على سبيل المثال، يظهر الإجراء SQL Server التالي في سير عمل Consumption خطأ 429، والذي يبلغ عن مشكلة تقييد:
تصف الأقسام التالية المستويات الشائعة التي قد يواجه فيها سير العمل تقييدا:
تقييد مورد تطبيق المنطق
لدى Azure Logic Apps حدود معدل النقل الخاصة بها. إذا تجاوز مورد تطبيق المنطق هذه الحدود، يتم تقييد مورد تطبيق المنطق الخاص بك، وليس فقط مثيل سير عمل معين أو تشغيله.
للعثور على أحداث التقييد على هذا المستوى، اتبع الخطوات التالية:
في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.
في قائمة مورد تطبيق المنطق، ضمن Monitoring، حدد Metrics.
ضمن عنوان المخطط، حدد إضافة مقياس، الذي يضيف شريط قياس آخر إلى المخطط.
في شريط المقاييس الأول، من قائمة Metric ، حدد Action Throttled Events. من قائمة التجميع ، حدد Count.
في شريط القياس الثاني، من قائمة Metric ، حدد Trigger Throttled Events. من قائمة التجميع ، حدد Count.
يعرض المخطط الآن الأحداث المقيدة لكل من الإجراءات والمشغلات في سير عمل تطبيق المنطق الخاص بك. لمزيد من المعلومات، راجع عرض مقاييس سلامة سير العمل وأدائه في Azure Logic Apps.
للتعامل مع التقييد في هذا المستوى، لديك الخيارات التالية:
حدد عدد مثيلات سير العمل التي يمكن تشغيلها في نفس الوقت.
بشكل افتراضي، إذا تم استيفاء شرط مشغل سير العمل الخاص بك أكثر من مرة واحدة في نفس الوقت، فعندئذ يتم تشغيل مثيلات متعددة من هذا المشغل بشكل متزامن أو بالتوازي. يتم تشغيل كل مثيل مشغل قبل انتهاء تشغيل مثيل سير العمل السابق.
على الرغم من أن العدد الافتراضي لمثيلات المشغل التي يمكن تشغيلها بالتزامن غير محدود، يمكنك تحديد هذا الرقم عن طريق تشغيل إعداد تزامن المشغل، وإذا لزم الأمر، حدد حداً آخر غير القيمة الافتراضية.
تمكين وضع معدل النقل العالي.
يحتوي سير عمل الاستهلاك على حد افتراضي لعدد الإجراءات التي يمكن تشغيلها عبر فاصل زمني متجدد مدته 5 دقائق. لرفع هذا الحد إلى الحد الأقصى لعدد الإجراءات، قم بتشغيل وضع معدل النقل العالي على مورد تطبيق المنطق الخاص بك.
لا يحتوي سير العمل القياسي على حد لعدد الإجراءات التي يمكن تشغيلها خلال أي فاصل زمني.
تعطيل سلوك تصحيح الصفيف أو "تقسيم على" في المشغلات.
إذا قام المشغل بإرجاع صفيف لإجراءات سير العمل المتبقية لمعالجتها، فإن إعداد Split On للمشغل يقسم عناصر الصفيف ويبدأ مثيل سير عمل لكل عنصر صفيف. يؤدي هذا السلوك بشكل فعال إلى تشغيل عمليات تشغيل متزامنة متعددة تصل إلى حد Split On.
للتحكم في التقييد، قم بإيقاف تشغيل سلوك Split On للمشغل واعمل على معالجة سير العمل الخاص بك الصفيف بأكمله باستدعاء واحد، بدلا من معالجة عنصر واحد لكل مكالمة.
إجراءات إعادة بناء التعليمات البرمجية في مهام سير عمل متعددة أصغر.
كما ذكرنا سابقا، يقتصر سير عمل تطبيق منطق الاستهلاك على عدد افتراضي من الإجراءات التي يمكن تشغيلها على مدى فترة 5 دقائق. على الرغم من أنه يمكنك زيادة هذا الحد عن طريق تمكين وضع معدل النقل العالي، فقد تفكر أيضا في ما إذا كنت تريد تقسيم إجراءات سير العمل إلى مهام سير عمل أصغر بحيث يظل عدد الإجراءات التي يتم تشغيلها في كل سير عمل ضمن الحد. وبهذه الطريقة، يمكنك تقليل العبء على سير عمل واحد وتوزيع الحمل عبر مهام سير عمل متعددة. يعمل هذا الحل بشكل أفضل في الإجراءات التي تتعامل مع مجموعات البيانات الكبيرة أو التي تدور حول العديد من الإجراءات قيد التشغيل بالتزامن أو تكرارات التكرار الحلقي أو الإجراءات المتخذة داخل كل تكرار للتكرار الحلقي بحيث تتجاوز حد تنفيذ الإجراء.
على سبيل المثال، يقوم سير عمل Consumption التالي بكل العمل للحصول على جداول من قاعدة بيانات SQL Server ويحصل على الصفوف من كل جدول. يتكرر إجراء التكرار الحلقي For each بشكل متزامن عبر كل جدول بحيث يقوم الإجراء Get rows بإرجاع الصفوف لكل جدول. استناداً إلى كميات البيانات في تلك الجداول، قد تتجاوز هذه الإجراءات الحد الأقصى لعمليات تنفيذ الإجراءات.
بعد إعادة بناء التعليمات البرمجية، يتم تقسيم سير العمل الأصلي إلى سير عمل أصل وسير عمل تابع.
يحصل سير العمل الأصل التالي على الجداول من SQL Server ثم يستدعي سير العمل التابع لكل جدول للحصول على الصفوف:
يتم استدعاء سير العمل التابع التالي بواسطة سير العمل الأصل للحصول على الصفوف لكل جدول:
تقييد الموصل
لكل موصل حدود تقييد خاصة به، والتي يمكنك العثور عليها في صفحة المرجع التقني لكل موصل. على سبيل المثال، يحتوي موصل ناقل خدمة Azure على حد تقييد يسمح بإجراء ما يصل إلى 6,000 استدعاء في الدقيقة، بينما يحتوي الموصل SQL Server على حدود تقييد تختلف حسب نوع العملية.
تحتوي بعض المشغلات والإجراءات، مثل HTTP، على "سياسة إعادة المحاولة" التي يمكنك تخصيصها استناداً إلى حدود سياسة إعادة المحاولة لتنفيذ معالجة الاستثناء. تحدد هذه السياسة ما إذا كان المشغل أو الإجراء يعيد محاولة طلب ومدى تكراره عند فشل الطلب الأصلي أو انتهاء مهلته وينتج عنه استجابة 408 أو 429 أو 5xx. لذلك، عند بدء التقييد وإرجاع خطأ 429، تتبع Logic Apps سياسة إعادة المحاولة حيثما كانت مدعومة.
لمعرفة ما إذا كان المشغل أو الإجراء يدعم سياسات إعادة المحاولة، تحقق من إعدادات المشغل أو الإجراء. لعرض محاولات إعادة محاولة المشغل أو الإجراء، انتقل إلى محفوظات تشغيل تطبيق المنطق، وحدد التشغيل الذي تريد مراجعته، وقم بتوسيع هذا المشغل أو الإجراء لعرض تفاصيل حول المدخلات والمخرجات وأي عمليات إعادة محاولة.
يوضح مثال سير عمل الاستهلاك التالي المكان الذي يمكنك فيه العثور على هذه المعلومات لإجراء HTTP:
على الرغم من أن محفوظات إعادة المحاولة توفر معلومات عن الخطأ، قد تواجه مشكلة في التمييز بين تقييد الموصل وتقييد الوجهة. في هذه الحالة، قد تضطر إلى مراجعة تفاصيل الاستجابة أو إجراء بعض حسابات الفاصل الزمني التقييدي لتحديد المصدر.
بالنسبة إلى مهام سير عمل تطبيق منطق الاستهلاك في Azure Logic Apps متعددة المستأجرين، يحدث التقييد على مستوى الاتصال . بالنسبة إلى مهام سير عمل تطبيق المنطق التي تعمل في بيئة خدمة تكامل (ISE)، لا يزال التقييد يحدث للاتصالات غير ISE لأنها تعمل في Azure Logic Apps متعددة المستأجرين. ومع ذلك، لا يتم تقييد اتصالات ISE، التي تم إنشاؤها بواسطة موصلات ISE، لأنها تعمل في ISE المتوفر لديك.
للتعامل مع التقييد في هذا المستوى، لديك الخيارات التالية:
قم بإعداد اتصالات متعددة لإجراء واحد بحيث يمكن لسير العمل تقسيم البيانات للمعالجة.
ضع في اعتبارك ما إذا كان يمكنك توزيع حمل العمل عن طريق تقسيم طلبات الإجراء عبر اتصالات متعددة إلى نفس الوجهة باستخدام نفس بيانات الاعتماد.
على سبيل المثال، افترض أن سير العمل الخاص بك يحصل على جداول من قاعدة بيانات SQL Server ثم يحصل على الصفوف من كل جدول. واستناداً إلى عدد الصفوف التي يتعين عليك معالجتها، يمكنك استخدام اتصالات متعددة والتكرارات الحلقية For each المتعددة لتقسيم العدد الإجمالي للصفوف إلى مجموعات أصغر للمعالجة. يستخدم هذا السيناريو تكرارين حلقيين For each لتقسيم العدد الإجمالي للصفوف إلى نصفين. يستخدم التكرار الحلقي For each الأول تعبيراً يحصل على النصف الأول. يستخدم التكرار الحلقي For each الآخر تعبيراً مختلفاً يحصل على النصف الثاني، على سبيل المثال:
التعبير 1: تحصل الدالة
take()على مقدمة المجموعة. لمزيد من المعلومات، راجعtake()الدالة.@take(collection-or-array-name, div(length(collection-or-array-name), 2))التعبير 2: تقوم الدالة
skip()بإزالة مقدمة المجموعة وإرجاع جميع العناصر الأخرى. لمزيد من المعلومات، راجع الدالةskip().@skip(collection-or-array-name, div(length(collection-or-array-name), 2))يوضح مثال سير عمل الاستهلاك التالي كيف يمكنك استخدام هذه التعبيرات:
إعداد اتصال مختلف لكل إجراء.
ضع في اعتبارك ما إذا كان يمكنك توزيع حمل العمل عن طريق نشر طلبات كل إجراء عبر اتصاله الخاص، حتى عندما تتصل الإجراءات بنفس الخدمة أو النظام وتستخدم نفس بيانات الاعتماد.
على سبيل المثال، افترض أن سير العمل الخاص بك يحصل على الجداول من قاعدة بيانات SQL Server ويحصل على كل صف في كل جدول. يمكنك استخدام اتصالات منفصلة بحيث يستخدم الحصول على الجداول اتصالاً واحداً، بينما يستخدم الحصول على كل صف اتصالاً آخر.
يوضح المثال التالي سير عمل Consumption الذي ينشئ ويستخدم اتصالا مختلفا لكل إجراء:
تغيير التزامن أو التوازي في التكرار الحلقي "For each".
بشكل افتراضي، يتم تشغيل تكرارات التكرار الحلقي "For each" في نفس الوقت لما يصل إلى حد التزامن. إذا كان لديك اتصال يتم تقييده داخل حلقة "لكل" ، يمكنك تقليل عدد تكرارات التكرار الحلقي التي تعمل بالتوازي. للاطلاع على مزيد من المعلومات، راجع الوثائق التالية:
تقييد خدمة الوجهة أو نظامها
بينما يحظى الموصل بحدود تقييد خاصة به، قد تتمتع خدمة الوجهة أو نظامها الذي يستدعيه الموصل بحدود تقييد أيضًا. على سبيل المثال، بعض واجهات برمجة التطبيقات API في Microsoft Exchange Server لها حدود تقييد أكثر صرامة من موصل Office 365 Outlook.
بشكل افتراضي، يتم تشغيل مثيلات سير عمل تطبيق المنطق وأي حلقات أو فروع داخل هذه المثيلات، بالتوازي. وهذا السلوك يعني أنه يمكن لمثيلات متعددة استدعاء نفس نقطة النهاية في نفس الوقت. لا يعرف كل مثيل عن وجود الآخر، لذلك يمكن أن تؤدي محاولات إعادة محاولة الإجراءات الفاشلة إلى إنشاء حالات تعارض حيث تحاول استدعاءات متعددة التشغيل في نفس الوقت، ولكن للنجاح، يجب أن تصل هذه الاستدعاءات إلى خدمة الوجهة أو نظامها قبل أن تبدأ عملية التقييد.
على سبيل المثال، افترض أن لديك صفيفاً يحتوي على 100 عنصر. يمكنك استخدام حلقة "لكل" للتكرار عبر الصفيف وتشغيل عنصر تحكم التزامن للحلقة بحيث يمكنك تقييد عدد التكرارات المتوازية إلى 20 أو الحد الافتراضي الحالي. في هذا التكرار الحلقي، يدرج أحد الإجراءات عنصراً من الصفيف في قاعدة بيانات SQL Server، ما يسمح بإجراء 15 استدعاء فقط في الثانية. ينتج عن هذا السيناريو مشكلة تقييد لأن تراكم عمليات إعادة المحاولة يتراكم ولا يتم تشغيله أبدا.
يصف الجدول التالي المخطط الزمني لما يحدث في التكرار الحلقي عندما يكون الفاصل الزمني لإعادة محاولة الإجراء ثانية واحدة:
| نقطة زمنية | عدد الإجراءات التي يجري تشغيلها | عدد الإجراءات التي تفشل | عدد مرات الانتظار لإعادة المحاولة |
|---|---|---|---|
| T + 0 ثانية | 20 إدراجاً | 5 حالات فشل، بسبب حد SQL | 5 حالات إعادة محاولة |
| T + 0.5 ثانية | 15 إدراجاً، بسبب حالات الانتظار لإعادة المحاولة الـ 5 السابقة | جميع الحالات 15 الفاشلة، بسبب حد SQL السابق الذي لا يزال سارياً لمدة 0.5 ثانية أخرى | 20 حالة إعادة محاولة (5 مسبقاً + 15 جديد) |
| T + 1 ثانية | 20 إدراجاً | فشل 5 بالإضافة إلى 20 حالة إعادة المحاولة السابقة، بسبب حد SQL | 25 محاولة (20 مسبقاً + 5 جديدة) |
للتعامل مع التقييد في هذا المستوى، لديك الخيارات التالية:
إنشاء مهام سير عمل فردية بحيث يتعامل كل منها مع عملية واحدة.
تابعا للسيناريو SQL Server المثال في هذا القسم، يمكنك إنشاء سير عمل يضع عناصر الصفيف في قائمة انتظار، مثل قائمة انتظار ناقل خدمة Azure. ثم تقوم بإنشاء سير عمل آخر يقوم فقط بعملية الإدراج لكل عنصر في قائمة الانتظار هذه. بهذه الطريقة، يتم تشغيل مثيل سير عمل واحد فقط في أي وقت محدد، والذي يكمل عملية الإدراج وينتقل إلى العنصر التالي في قائمة الانتظار، أو يحصل المثيل على 429 خطأ ولكنه لا يحاول إعادة المحاولة غير المنتجة.
إنشاء سير عمل أصل يستدعي سير عمل تابعا أو متداخلا لكل إجراء. إذا كان الأصل بحاجة إلى استدعاء مهام سير عمل تابعة مختلفة استنادا إلى نتيجة الأصل، يمكنك استخدام إجراء شرط أو تبديل الإجراء الذي يحدد سير العمل التابع الذي يجب استدعته. يمكن أن يساعدك هذا النمط في تقليل عدد الاستدعاءات أو العمليات.
على سبيل المثال، افترض أن لديك اثنين من مهام سير العمل، لكل منهما مشغل استقصاء يتحقق من حساب بريدك الإلكتروني كل دقيقة لموضوع معين، مثل "النجاح" أو "الفشل". ينتج عن هذا الإعداد 120 استدعاء في الساعة. بدلا من ذلك، إذا قمت بإنشاء سير عمل أصل واحد يستقصي كل دقيقة ولكنه يستدعي سير عمل تابع يتم تشغيله استنادا إلى ما إذا كان الموضوع هو "النجاح" أو "الفشل"، يمكنك خفض عدد عمليات التحقق إلى النصف، أو 60 في هذه الحالة.
إعداد معالجة دفعة من الملفات. (مهام سير عمل الاستهلاك فقط)
إذا كانت خدمة الوجهة تدعم عمليات الدفعات، يمكنك معالجة التقييد عن طريق معالجة العناصر في مجموعات أو دفعات، بدلاً من معالجة كل منها على حدة. لتنفيذ حل معالجة الدفعات، يمكنك إنشاء سير عمل تطبيق المنطق "مستقبل الدفعة" وسير عمل تطبيق المنطق "مرسل الدفعة". يجمع تطبيق مرسل الدفعة الرسائل أو العناصر حتى تستوفى المعايير المحددة، ثم يرسل هذه الرسائل أو العناصر في مجموعة واحدة. يقبل تطبيق مستقبل الدفعة هذه المجموعة ويعالج تلك الرسائل أو العناصر. لمزيد من المعلومات، راجع رسائل معالجة الدفعات في مجموعات.
استخدم إصدارات خطاف الويب للمشغلات والإجراءات، بدلاً من إصدارات التحقق.
لماذا؟ يستمر مشغل التحقق في فحص خدمة الوجهة أو نظامها على فترات زمنية محددة. يمكن أن يؤدي الفاصل الزمني كثير التكرار، مثل كل ثانية، إلى حدوث مشكلات تقييد. ومع ذلك، يقوم مشغل خطاف الويب أو الإجراء، مثل HTTP Webhook، بإنشاء استدعاء واحد فقط لخدمة الوجهة أو نظامها، والذي يحدث في وقت الاشتراك ويطلب أن تقوم الوجهة بإعلام المشغل أو الإجراء فقط عند حدوث حدث ما. وبهذه الطريقة، لا يتعين على المشغل أو الإجراء فحص الوجهة باستمرار.
لذلك، إذا كانت خدمة الوجهة أو نظامها يدعمان خطافات الويب أو يوفران موصلاً يحتوي على إصدار خطاف الويب، فهذا الخيار أفضل من استخدام إصدار التحقق. لتحديد مشغلات خطاف الويب وإجراءاته، تأكد من أن توفر النوع
ApiConnectionWebhookلديها أو أنهم لا يحتاجون إلى تحديد أحد التكرارات. لمزيد من المعلومات، راجع مشغل APIConnectionWebhookوإجراء APIConnectionWebhook.