التعامل مع مشاكل الاختناق (429 - أخطاء "طلبات كثيرة جدا") في تطبيقات Azure المنطقية

  • مقالة
  • قراءة خلال 10 دقائق

في Azure Logic Apps، يعرض تطبيقك المنطقي خطأ "HTTP 429 الكثير من الطلبات" عند مواجهة الاختناق ، والذي يحدث عندما يتجاوز عدد الطلبات المعدل الذي يمكن للوجهة التعامل معه خلال فترة زمنية محددة. يمكن أن يؤدي الاختناق إلى حدوث مشكلات مثل تأخير معالجة البيانات وانخفاض سرعة الأداء وأخطاء مثل تجاوز سياسة إعادة المحاولة المحددة.

Throttling in SQL Server connector

في ما يلي بعض أنواع الاختناق الشائعة التي قد يواجهها تطبيقك المنطقي:

اختناق تطبيق المنطق

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

للعثور على أحداث الاختناق على هذا المستوى، تحقق من جزء المقاييس في تطبيق المنطق في مدخل Azure.

  1. في مدخل Azure، افتح تطبيقك المنطقي في مصمم تطبيقات المنطق.

  2. في قائمة التطبيق المنطقي، ضمن مراقبة، حدد المقاييس.

  3. ضمن عنوان المخطط، حدد إضافة مقياس بحيث تضيف مقياسا آخر إلى المقياس الموجود.

  4. في شريط المقاييس الأول، من قائمة METRIC ، حدد الأحداث الخانقة للإجراءات. في شريط المقاييس الثاني، من قائمة METRIC ، حدد تشغيل الأحداث المقيدة.

للتعامل مع الاختناق عند هذا المستوى، تتوفر لديك الخيارات التالية:

  • حدد عدد مثيلات التطبيق المنطقي التي يمكن تشغيلها في نفس الوقت.

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

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

  • تمكين وضع الإنتاجية العالية.

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

  • تعطيل سلوك اقتطاع الصفيف ("الانقسام على") في المشغلات.

    إذا قام مشغل بإرجاع صفيف لإجراءات سير العمل المتبقية لمعالجتها، فإن إعداد Split On الخاص بمشغل يقوم بتقسيم عناصر الصفيف وبدء مثيل سير عمل لكل عنصر صفيف، مما يؤدي بشكل فعال إلى تشغيل العديد من عمليات التشغيل المتزامنة حتى حد Split On. للتحكم في الاختناق، قم بإيقاف تشغيل سلوك Split On واطلب من تطبيقك المنطقي معالجة الصفيف بأكمله بمكالمة واحدة، بدلا من التعامل مع عنصر واحد لكل مكالمة.

  • أعد تشكيل الإجراءات إلى تطبيقات منطقية أصغر.

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

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

    Logic app

    بعد إعادة الهيكلة ، أصبح تطبيق المنطق الآن تطبيقا منطقيا للوالدين وتابعا. يحصل الأصل على الجداول من SQL Server ثم يستدعي تطبيقا منطقيا تابعا لكل جدول للحصول على الصفوف:

    Create logic app for one action

    إليك تطبيق المنطق التابع الذي يطلق عليه تطبيق المنطق الأصل للحصول على الصفوف لكل جدول:

    Create another logic app for a second action

اختناق الموصل

لكل موصل حدود اختناق خاصة به، والتي يمكنك العثور عليها في صفحة المرجع الفني للموصل. على سبيل المثال، يحتوي موصل ناقل خدمة Azure على حد اختناق يسمح بإجراء ما يصل إلى 6000 مكالمة في الدقيقة، بينما يحتوي موصل SQL Server على حدود اختناق تختلف بناء على نوع العملية.

تحتوي بعض المشغلات والإجراءات، مثل HTTP، على " سياسة إعادة المحاولة" التي يمكنك تخصيصها استنادا إلى حدود نهج إعادة المحاولة لتنفيذ معالجة الاستثناءات. تحدد هذه السياسة ما إذا كان المشغل أو الإجراء يعيد محاولة طلب وكم مرة عندما يفشل الطلب الأصلي أو تنتهي مهلته وينتج عنه استجابة 408 أو 429 أو 5xx. لذلك ، عند بدء الاختناق وإرجاع خطأ 429 ، تتبع Logic Apps سياسة إعادة المحاولة حيثما تكون مدعومة.

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

View action's run history, retries, inputs, and outputs

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

بالنسبة للتطبيقات المنطقية في خدمة Azure Logic Apps العالمية متعددة المستأجرين، يحدث الاختناق على مستوى الاتصال . لذلك ، على سبيل المثال ، بالنسبة للتطبيقات المنطقية التي تعمل في بيئة خدمة تكامل (ISE) ، لا يزال الاختناق يحدث للاتصالات غير التابعة ل ISE لأنها تعمل في خدمة Logic Apps العالمية متعددة المستأجرين. ومع ذلك ، لا يتم خنق اتصالات ISE ، التي يتم إنشاؤها بواسطة موصلات ISE ، لأنها تعمل في ISE الخاص بك.

للتعامل مع الاختناق عند هذا المستوى، تتوفر لديك الخيارات التالية:

  • قم بإعداد اتصالات متعددة لإجراء واحد بحيث يقوم تطبيق المنطق بتقسيم البيانات للمعالجة.

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

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

    • التعبير 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))

      في ما يلي مثال مرئي يوضح كيفية استخدام هذه التعبيرات:

      Create and use multiple connections for a single action

  • قم بإعداد اتصال مختلف لكل إجراء.

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

    على سبيل المثال، افترض أن تطبيقك المنطقي يحصل على الجداول من قاعدة بيانات SQL Server ويحصل على كل صف في كل جدول. يمكنك استخدام اتصالات منفصلة بحيث يستخدم الحصول على الجداول اتصالا واحدا، بينما يستخدم الحصول على كل صف اتصالا آخر.

    Create and use a different connections for each action

  • تغيير التزامن أو التوازي على حلقة "لكل منها".

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

خدمة الوجهة أو اختناق النظام

على الرغم من أن الموصل له حدود اختناق خاصة به، إلا أن خدمة الوجهة أو النظام الذي يستدعيه الموصل قد يكون له أيضا حدود اختناق. على سبيل المثال، تحتوي بعض واجهات برمجة التطبيقات في Microsoft Exchange Server على حدود اختناق أكثر صرامة من موصل Office 365 Outlook.

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

على سبيل المثال، افترض أن لديك صفيف يحتوي على 100 عنصر. يمكنك استخدام حلقة "لكل منها" للتكرار عبر الصفيف وتشغيل عنصر تحكم تزامن الحلقة بحيث يمكنك تقييد عدد التكرارات المتوازية إلى 20 أو الحد الافتراضي الحالي. داخل هذه الحلقة ، يقوم إجراء بإدراج عنصر من الصفيف في قاعدة بيانات SQL Server ، والتي تسمح ب 15 مكالمة فقط في الثانية. يؤدي هذا السيناريو إلى مشكلة اختناق بسبب تراكم تراكمات عمليات إعادة المحاولة وعدم تشغيلها أبدا.

يصف هذا الجدول المخطط الزمني لما يحدث في الحلقة عندما يكون الفاصل الزمني لإعادة محاولة الإجراء 1 ثانية:

نقطة في الوقت المناسب عدد الإجراءات التي يتم تشغيلها عدد الإجراءات التي تفشل عدد عمليات إعادة المحاولة التي تنتظر
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 في هذه الحالة.

  • إعداد معالجة الدفعات.

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

  • استخدم إصدارات webhook للمشغلات والإجراءات، بدلا من إصدارات الاقتراع.

    لماذا؟ يستمر مشغل الاقتراع في التحقق من خدمة أو نظام الوجهة على فترات زمنية محددة. يمكن أن يؤدي الفاصل الزمني المتكرر جدا ، مثل كل ثانية ، إلى حدوث مشاكل في الاختناق. ومع ذلك، يقوم مشغل أو إجراء webhook، مثل HTTP Webhook، بإنشاء مكالمة واحدة فقط إلى الخدمة أو النظام الوجهة، والذي يحدث في وقت الاشتراك ويطلب من الوجهة إخطار المشغل أو الإجراء فقط عند حدوث حدث. وبهذه الطريقة، لا يتعين على المشغل أو الإجراء التحقق باستمرار من الوجهة.

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

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