مشاركة عبر


أساليب توجيه نسبة استخدام الشبكة إلى الأصل

هام

سيتم إيقاف Azure Front Door (الكلاسيكي) في 31 مارس 2027. لتجنب أي تعطيل للخدمة، من المهم ترحيل ملفات تعريف Azure Front Door (الكلاسيكية) إلى مستوى Azure Front Door Standard أو Premium بحلول مارس 2027. لمزيد من المعلومات، راجع إيقاف Azure Front Door (الكلاسيكي).

يدعم Azure Front Door أربع طرق لتوجيه نسبة استخدام الشبكة لإدارة كيفية توزيع نسبة استخدام الشبكة HTTP/HTTPS بين أصول مختلفة. عندما تصل طلبات المستخدم إلى مواقع حافة Front Door، يضمن أسلوب التوجيه المكون إعادة توجيه الطلبات إلى أفضل مورد خلفية.

إشعار

في هذه المقالة، يشير الأصل إلى الخلفية، وتشير مجموعة الأصل إلى تجمع الواجهة الخلفية في تكوين Azure Front Door (الكلاسيكي).

تتمثل أساليب توجيه نسبة استخدام الشبكة الأربعة في:

  • زمن الانتقال: يوجه الطلبات إلى الأصول ذات أقل زمن انتقال ضمن نطاق حساسية مقبول، ما يضمن إرسال الطلبات إلى أقرب الأصول من حيث زمن انتقال الشبكة.

  • الأولوية: يسمح لك بتعيين أولوية لأصولك، وتعيين أصل أساسي للتعامل مع كل حركة المرور وأصل ثانوي كنسخة احتياطية إذا أصبح الأساسي غير متوفر.

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

  • ترابط الجلسة: يضمن إرسال الطلبات من نفس المستخدم النهائي إلى نفس الأصل عن طريق تكوين ترابط الجلسة لمضيفي الواجهة الأمامية أو المجالات.

إشعار

في مستويات Azure Front Door Standard وPremium، يشار إلى اسم نقطة النهاية باسم مضيف الواجهة الأمامية في Azure Front Door (كلاسيكي).

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

إشعار

باستخدام محرك قواعد Front Door، يمكنك تكوين القواعد لتجاوز تكوينات المسار في مستويات Azure Front Door Standard وPremium أو تجاوز تجمع الواجهة الخلفية في Azure Front Door (الكلاسيكي) لطلب ما. ستتجاوز مجموعة الأصل أو تجمع الخلفية الذي تم تعيينه بواسطة محرك القواعد عملية التوجيه الموضحة في هذه المقالة.

تدفق القرار الكلي

يوضح الرسم التخطيطي التالي تدفق القرار الكلي:

رسم تخطيطي يوضح كيفية تحديد الأصول استنادا إلى إعدادات الأولوية وزمن الانتقال والوزن في Azure Front Door.

خطوات القرار هي:

  1. الأصول المتوفرة: حدد جميع الأصول التي تم تمكينها وصحية (200 موافق) استنادا إلى فحص السلامة.
    • مثال: إذا كانت هناك ستة أصول A وB وC وD وE وF وC غير سليمة ويتم تعطيل E، فإن الأصول المتوفرة هي A وB وD وF.
  2. الأولوية: حدد الأصول ذات الأولوية العليا من الأصول المتوفرة.
    • مثال: إذا كانت الأصول A وB وD لها الأولوية 1 وكان الأصل F له الأولوية 2، فإن الأصول المحددة هي A وB وD.
  3. إشارة زمن الانتقال (استنادا إلى فحص السلامة): حدد الأصول ضمن نطاق زمن الانتقال المسموح به من بيئة Front Door حيث وصل الطلب. ويستند هذا إلى إعداد حساسية زمن الانتقال لمجموعة الأصل وزمن الانتقال لأقرب الأصول.
    • مثال: إذا كان زمن الانتقال إلى الأصل A هو 15 مللي ثانية، إلى B هو 30 مللي ثانية، وإلى D هو 60 مللي ثانية، وتم تعيين حساسية زمن الانتقال إلى 30 مللي ثانية، فإن الأصول المحددة هي A وB، حيث يتجاوز D النطاق 30 مللي ثانية.
  4. الأوزان: توزيع نسبة استخدام الشبكة بين الأصول النهائية المحددة استنادا إلى نسب الوزن المحددة.
    • مثال: إذا كان الأصل أ له وزن 3 وكان الأصل B وزنه 7، يتم توزيع نسبة استخدام الشبكة 3/10 إلى A و7/10 إلى B.

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

توجيه نسبة استخدام الشبكة حسب أقل زمن انتقال

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

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

إشعار

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

لمزيد من المعلومات، راجع بنية توجيه Azure Front Door.

توجيه نسبة استخدام الشبكة حسب الأولوية

لضمان قابلية وصول عالية، غالبا ما تقوم المؤسسات بنشر خدمات النسخ الاحتياطي للاستيلاء عليها في حالة فشل الخدمة الأساسية. يعرف هذا الإعداد باسم Active/Standby أو Active/Passive deployment. يسمح لك أسلوب توجيه نسبة استخدام الشبكة الأولوية في Azure Front Door بتنفيذ نمط تجاوز الفشل هذا بشكل فعال.

بشكل افتراضي، يوجه Azure Front Door نسبة استخدام الشبكة إلى الأصول ذات الأولوية القصوى (القيمة الأقل أولوية). إذا أصبحت هذه الأصول الأساسية غير متوفرة، فإنه يوجه حركة المرور إلى الأصول الثانوية (القيمة الأقل أولوية التالية). تستمر هذه العملية بأصول ثلاثية إذا كانت الأصول الأساسية والثانوية غير متوفرة. تراقب تحقيقات الصحة توفر الأصول استنادا إلى حالتها المكونة وصحتها.

تكوين الأولوية للأصول

يحتوي كل أصل في مجموعة أصل Azure Front Door على خاصية Priority ، والتي يمكن تعيينها إلى قيمة بين 1 و5. تشير القيم الأقل إلى أولوية أعلى. يمكن أن تشترك أصول متعددة في نفس قيمة الأولوية.

أسلوب توجيه نسبة استخدام الشبكة المُرجح

يسمح لك أسلوب توجيه نسبة استخدام الشبكة المرجح بتوزيع نسبة استخدام الشبكة استنادا إلى الأوزان المحددة مسبقا.

في هذا الأسلوب، يمكنك تعيين وزن لكل أصل في مجموعة أصل Azure Front Door. الوزن هو عدد صحيح بين 1 و1000، بقيمة افتراضية 50.

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

يدعم الأسلوب المرجح عدة سيناريوهات:

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

تقارب الجلسة

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

يستخدم Azure Front Door ترابط جلسة العمل المستندة إلى ملفات تعريف الارتباط، حيث يتم استخدام ملفات تعريف الارتباط المدارة مع SHA256 من عنوان URL الأصلي كمعرف. يؤدي هذا إلى توجيه نسبة استخدام الشبكة اللاحقة من جلسة عمل المستخدم إلى نفس الأصل.

يمكن تمكين ترابط الجلسة على مستوى مجموعة الأصل في مستويات Azure Front Door Standard وPremium، وعلى مستوى مضيف الواجهة الأمامية في Azure Front Door (كلاسيكي) لكل مجال أو مجال فرعي تم تكوينه. بمجرد التمكين، يضيف Azure Front Door ملفات تعريف الارتباط المسماة ASLBSA وإلى ASLBSACORS جلسة عمل المستخدم. تساعد ملفات تعريف الارتباط هذه في تحديد المستخدمين المختلفين حتى إذا كانوا يشاركون نفس عنوان IP، ما يسمح بتوزيع نسبة استخدام الشبكة بين الأصول بشكل أكثر التساوي.

تتطابق مدة بقاء ملف تعريف الارتباط مع جلسة عمل المستخدم، حيث يدعم Front Door حاليا ملفات تعريف الارتباط الخاصة بجلسة العمل فقط.

إشعار

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

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

سيتم تأسيس ترابط الجلسة في الظروف التالية خارج السيناريوهات القياسية غير القابلة للتخزين المؤقت:

  • تتضمن الاستجابة Cache-Control العنوان بدون مخزن.
  • تحتوي الاستجابة على عنوان صالح Authorization .
  • تحتوي الاستجابة على رمز حالة بروتوكول نقل نص تشعبي 302.

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