HeadlinesBriefing favicon HeadlinesBriefing.com

حماية Uber من عواصف إعادة المحاولة

Hacker News •
×

أثّرت عواصف إعادة المحاولة تاريخياً على العمليات التجارية وثقة العلامة التجارية. وبينما يوفر ضبط تكوين إعادة المحاولة وميزانيات إعادة المحاولة تخفيفاً ذا مغزى على مستوى الخدمة، إلا أنها تُكوَّن يدوياً وتفتقر إلى الرؤية في التضخيم عبر الخدمات الناتج عن سلاسل التبعية العميقة وأنماط التوزيع. ونتيجة لذلك، قد يكون من الصعب حماية البنية التحتية من تأثير الدومينو الناتج عن انقطاع خدمة واحدة في عمق المكدس.

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

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

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