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

ينطبق على: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (كلاسيكي)

هام

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

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

إشعار

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

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

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

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

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

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

إشعار

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

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

إشعار

باستخدام محرك قواعد الباب الأمامي ، يمكنك تكوين القواعد على <تكوينات المسار c1>تجاوز الطريق في الواجهة الأمامية لـ Azure المستويات القياسية والمميزة أو تجاوز تجمع الخلفية في الواجهة الأمامية لـ Azure (الكلاسيكي) لطلب معين. مجموعة الأصل أو مجموعة الخلفية التي يحددها محرك القواعد تتجاوز عملية التوجيه الموضحة في هذا المقال.

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

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

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

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. يوجه هذا الأسلوب طلبات المستخدم إلى الأصل بأقل زمن انتقال للشبكة، بدلا من أقرب موقع جغرافي، ما يضمن الأداء الأمثل.

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

إشعار

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

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

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

لضمان توفر عالي، نشر خدمات النسخ الاحتياطي لتتولى المهمة إذا فشل الخدمة الأساسية. يعرف هذا الإعداد باسم Active/Standby أو Active/Passive deployment. طريقة توجيه حركة المرور Priority في الواجهة الأمامية لـ Azure تساعدك على تنفيذ نمط التحويل التلقائي هذا.

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

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

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

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

إشعار

بالنسبة للعملاء الذين لديهم RPS منخفض جدا (طلبات في الثانية)، وبسبب الطبيعة الموزعة لنقاط الحضور (POPs) والآلات في الواجهة الأمامية لـ Azure، لا يمكن ل الواجهة الأمامية لـ Azure ضمان اتباع الأوزان التي تكوينها بدقة، وقد يبدو توازن الحمل منحرا.

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

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

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

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

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

تقارب الجلسة

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

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

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

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

إشعار

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

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

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

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

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

• تعرف على كيفية إنشاء ملف تعريف الواجهة الأمامية لـ Azure.
• تعرف على كيفية عمل Front Door.