التكرار العالمي للتوجيه لتطبيقات الويب ذات المهام الحرجة
هام
يمكن أن يكون تصميم تطبيقات التكرار التي تتعامل مع انقطاع النظام الأساسي العالمي لبنية مهمة بالغة الأهمية معقدا ومكلفة. نظرا للمشاكل المحتملة التي قد تنشأ مع هذا التصميم، ضع في اعتبارك المفاضلات بعناية.
في معظم الحالات، لن تحتاج إلى البنية الموضحة في هذه المقالة.
تسعى الأنظمة ذات المهام الحرجة إلى تقليل نقاط الفشل الفردية من خلال بناء قدرات التكرار واشفاء الذات في الحل قدر الإمكان. يمكن اعتبار أي نقطة دخول موحدة للنظام نقطة فشل. إذا واجه هذا المكون انقطاعا، فسيكون النظام بأكمله غير متصل بالمستخدم. عند اختيار خدمة توجيه، من المهم مراعاة موثوقية الخدمة نفسها.
في البنية الأساسية لتطبيق مهم، تم اختيار Azure Front Door بسبب اتفاقيات مستوى الخدمة (SLA) في وقت التشغيل العالي ومجموعة ميزات غنية:
- توجيه حركة المرور إلى مناطق متعددة في نموذج نشط-نشط
- تجاوز الفشل الشفاف باستخدام TCP anycast
- خدمة المحتوى الثابت من عقد الحافة باستخدام شبكات تسليم المحتوى المتكاملة (CDNs)
- حظر الوصول غير المصرح به باستخدام جدار حماية تطبيق الويب المتكامل
تم تصميم Front Door لتوفير أقصى قدر من المرونة والتوافر ليس فقط لعملائنا الخارجيين، ولكن أيضا لخصائص متعددة عبر Microsoft. لمزيد من المعلومات حول قدرات Front Door، راجع تسريع وتأمين تطبيق الويب الخاص بك باستخدام Azure Front Door.
قدرات Front Door أكثر من كافية لتلبية معظم متطلبات العمل، ومع ذلك، مع أي نظام موزع، تتوقع فشلا. إذا كانت متطلبات العمل تتطلب SLO مركبا أعلى أو وقت تعطل صفري في حالة انقطاع التيار الكهربائي، فستحتاج إلى الاعتماد على مسار دخول حركة مرور بديل. ومع ذلك، فإن السعي للحصول على SLO أعلى يأتي مع تكاليف كبيرة، ونفقات تشغيلية، ويمكن أن يقلل من الموثوقية الإجمالية الخاصة بك. فكر بعناية في المقايضات والمشكلات المحتملة التي قد يقدمها المسار البديل في المكونات الأخرى الموجودة على المسار الحرج. حتى عندما يكون تأثير عدم التوفر كبيرا، قد يفوق التعقيد الفائدة.
أحد الأساليب هو تحديد مسار ثانوي، مع خدمة (خدمات) بديلة، والتي تصبح نشطة فقط عندما يكون Azure Front Door غير متوفر. لا ينبغي التعامل مع تماثل الميزة مع Front Door كمتطلب صعب. تحديد أولويات الميزات التي تحتاجها تماما لأغراض استمرارية الأعمال، حتى أنه من المحتمل أن تعمل بسعة محدودة.
وهناك نهج آخر وهو استخدام تقنية الجهات الخارجية للتوجيه العالمي. سيتطلب هذا الأسلوب نشرا نشطا-نشطا متعدد السحابات مع طوابع مستضافة عبر اثنين أو أكثر من موفري السحابة. على الرغم من أنه يمكن دمج Azure بشكل فعال مع الأنظمة الأساسية السحابية الأخرى، لا يوصى بهذا النهج بسبب التعقيد التشغيلي عبر الأنظمة الأساسية السحابية المختلفة.
توضح هذه المقالة بعض الاستراتيجيات للتوجيه العمومي باستخدام Azure Traffic Manager كموجه بديل في الحالات التي لا يتوفر فيها Azure Front Door.
النهج
يوضح الرسم التخطيطي للبنية هذا نهجا عاما مع مسارات حركة مرور متكررة متعددة.
باستخدام هذا النهج، سنقدم العديد من المكونات ونقدم إرشادات من شأنها إجراء تغييرات كبيرة مرتبطة بتسليم تطبيق (تطبيقات) الويب الخاص بك:
يوجه Azure Traffic Manager نسبة استخدام الشبكة إلى Azure Front Door أو إلى الخدمة البديلة التي حددتها.
Azure Traffic Manager هو موازن تحميل عمومي قائم على DNS. يشير سجل CNAME لمجالك إلى Traffic Manager، الذي يحدد الوجهة استنادا إلى كيفية تكوين أسلوب التوجيه الخاص به. سيؤدي استخدام التوجيه ذي الأولوية إلى تدفق نسبة استخدام الشبكة عبر Azure Front Door بشكل افتراضي. يمكن ل Traffic Manager تبديل نسبة استخدام الشبكة تلقائيا إلى المسار البديل إذا كان Azure Front Door غير متوفر.
هام
يخفف هذا الحل من المخاطر المرتبطة بتعطل Azure Front Door، ولكنه عرضة لأنقطاعات Azure Traffic Manager كنقطة فشل عالمية.
يمكنك أيضا التفكير في استخدام نظام توجيه نسبة استخدام الشبكة العمومي مختلف، مثل موازن تحميل عمومي. ومع ذلك، يعمل Traffic Manager بشكل جيد للعديد من الحالات.
لديك مساران للدخول:
يوفر Azure Front Door المسار الأساسي ويعالج ويوجه جميع حركة مرور التطبيق الخاص بك.
يتم استخدام جهاز توجيه آخر كنسخة احتياطية ل Azure Front Door. تتدفق نسبة استخدام الشبكة عبر هذا المسار الثانوي فقط إذا لم يكن Front Door متوفرا.
تعتمد الخدمة المحددة التي تحددها للموجه الثانوي على العديد من العوامل. يمكنك اختيار استخدام خدمات Azure الأصلية أو خدمات الجهات الخارجية. في هذه المقالات نقدم خيارات Azure الأصلية لتجنب إضافة تعقيد تشغيلي إضافي إلى الحل. إذا كنت تستخدم خدمات الجهات الخارجية، فأنت بحاجة إلى استخدام مستويات تحكم متعددة لإدارة الحل الخاص بك.
يجب أن تكون خوادم تطبيق الأصل جاهزة لقبول نسبة استخدام الشبكة من أي خدمة. ضع في اعتبارك كيفية تأمين نسبة استخدام الشبكة إلى أصلك، وما هي المسؤوليات التي توفرها Front Door وخدمات المصدر الأخرى. تأكد من أن التطبيق الخاص بك يمكنه التعامل مع نسبة استخدام الشبكة من أي مسار تتدفق إليه نسبة استخدام الشبكة.
Tradeoffs
في حين أن استراتيجية التخفيف هذه يمكن أن تجعل التطبيق متاحا أثناء انقطاع النظام الأساسي، هناك بعض المقايضات الهامة. يجب عليك تقييم الفوائد المحتملة مقابل التكاليف المعروفة، واتخاذ قرار مستنير حول ما إذا كانت المزايا تستحق تلك التكاليف.
التكلفة المالية: عند توزيع مسارات زائدة عن الحاجة متعددة إلى التطبيق الخاص بك، تحتاج إلى النظر في تكلفة توزيع الموارد وتشغيلها. نقدم سيناريوهين مثالين لحالات استخدام مختلفة، كل منها له ملف تعريف تكلفة مختلف.
التعقيد التشغيلي: في كل مرة تضيف فيها مكونات إضافية إلى الحل الخاص بك، فإنك تزيد من النفقات الإدارية. قد يؤثر أي تغيير في أحد المكونات على المكونات الأخرى.
لنفترض أنك قررت استخدام الإمكانات الجديدة ل Azure Front Door. تحتاج إلى التحقق مما إذا كان مسار نسبة استخدام الشبكة البديل يوفر أيضا إمكانية مكافئة، وإذا لم يكن الأمر كذلك، فأنت بحاجة إلى تحديد كيفية التعامل مع الفرق في السلوك بين مساري حركة المرور. في تطبيقات العالم الحقيقي، يمكن أن يكون لهذه التعقيدات تكلفة عالية، ويمكن أن تشكل خطرا كبيرا على استقرار النظام الخاص بك.
الأداء: يتطلب هذا التصميم عمليات بحث CNAME إضافية أثناء تحليل الاسم. في معظم التطبيقات، هذا ليس مصدر قلق كبير، ولكن يجب تقييم ما إذا كان أداء التطبيق الخاص بك يتأثر بإدخال طبقات إضافية في مسار الدخول الخاص بك.
تكلفة الفرصة: يتطلب تصميم مسارات الدخول المكررة وتنفيذها استثمارا هندسيا كبيرا، والذي يأتي في نهاية المطاف بتكلفة فرصة لتطوير الميزات وتحسينات النظام الأساسي الأخرى.
تحذير
إذا لم تكن حذرا في كيفية تصميم وتنفيذ حل معقد عالي التوفر، يمكنك في الواقع جعل توفرك أسوأ. زيادة عدد المكونات في البنية الخاصة بك يزيد من عدد نقاط الفشل. وهذا يعني أيضا أن لديك مستوى أعلى من التعقيد التشغيلي. عند إضافة مكونات إضافية، يجب مراجعة كل تغيير تجريه بعناية لفهم كيفية تأثيره على الحل العام.
توفر Azure Traffic Manager
Azure Traffic Manager هي خدمة موثوقة، ولكن اتفاقية مستوى الخدمة لا تضمن توفرا بنسبة 100٪. إذا لم يكن Traffic Manager متوفرا، فقد لا يتمكن المستخدمون من الوصول إلى التطبيق الخاص بك، حتى إذا كان كل من Azure Front Door والخدمة البديلة متوفرة. من المهم التخطيط لكيفية استمرار الحل الخاص بك في العمل في ظل هذه الظروف.
يقوم Traffic Manager بإرجاع استجابات DNS القابلة للتخزين المؤقت. إذا كان وقت البقاء (TTL) على سجلات DNS يسمح بالتخزين المؤقت، فقد لا يكون الانقطاع القصير في Traffic Manager مصدر قلق. وذلك لأن محللي DNS المتلقين للمعلومات قد قاموا بتخزين استجابة سابقة مؤقتا. يجب أن تخطط للانقطاعات المطولة. قد تختار إعادة تكوين خوادم DNS يدويا لتوجيه المستخدمين إلى Azure Front Door إذا لم يكن Traffic Manager متوفرا.
تناسق توجيه نسبة استخدام الشبكة
من المهم فهم قدرات وميزات Azure Front Door التي تستخدمها وتعتمد عليها. عند اختيار الخدمة البديلة، حدد الحد الأدنى من الإمكانات التي تحتاجها واحذف الميزات الأخرى عندما يكون الحل الخاص بك في وضع متدهور.
عند التخطيط لمسار حركة مرور بديل، إليك بعض الأسئلة الرئيسية التي يجب مراعاتها:
- هل تستخدم ميزات التخزين المؤقت ل Azure Front Door؟ إذا لم يكن التخزين المؤقت متوفرا، هل يمكن لخوادم الأصل مواكبة نسبة استخدام الشبكة؟
- هل تستخدم محرك قواعد Azure Front Door لتنفيذ منطق توجيه مخصص، أو لإعادة كتابة الطلبات؟
- هل تستخدم جدار حماية تطبيق الويب Azure Front Door (WAF) لتأمين تطبيقاتك؟
- هل تقيد حركة المرور استنادا إلى عنوان IP أو الجغرافيا؟
- من الذي أصدر شهادات TLS الخاصة بك وأدارها؟
- كيف يمكنك تقييد الوصول إلى خوادم التطبيقات الأصلية للتأكد من أنه يأتي من خلال Azure Front Door؟ هل تستخدم Private Link، أم أنك تعتمد على عناوين IP العامة مع علامات الخدمة ورؤوس المعرفات؟
- هل تقبل خوادم التطبيقات نسبة استخدام الشبكة من أي مكان آخر غير Azure Front Door؟ إذا فعلوا ذلك، فما هي البروتوكولات التي يقبلونها؟
- هل يستخدم عملاؤك دعم HTTP/2 من Azure Front Door؟
جدار حماية تطبيق الويب (WAF)
إذا كنت تستخدم WAF الخاص ب Azure Front Door لحماية التطبيق الخاص بك، ففكر في ما يحدث إذا لم تمر نسبة استخدام الشبكة عبر Azure Front Door.
إذا كان المسار البديل يوفر أيضا WAF، ففكر في الأسئلة التالية:
- هل يمكن تكوينه بنفس طريقة Azure Front Door WAF؟
- هل تحتاج إلى ضبطها واختبارها بشكل مستقل، لتقليل احتمالية الاكتشافات الإيجابية الزائفة؟
تحذير
قد تختار عدم استخدام WAF لمسار الدخول البديل. يمكن اعتبار هذا النهج لدعم هدف موثوقية التطبيق. ومع ذلك، هذه ليست ممارسة جيدة ولا نوصي بها.
ضع في اعتبارك المفاضلة في قبول نسبة استخدام الشبكة من الإنترنت دون أي فحوصات. إذا اكتشف المهاجم مسار نسبة استخدام الشبكة الثانوي غير المحمي إلى التطبيق الخاص بك، فقد يرسل حركة مرور ضارة عبر المسار الثانوي حتى عندما يتضمن المسار الأساسي WAF.
من الأفضل تأمين جميع المسارات إلى خوادم التطبيقات الخاصة بك.
أسماء المجالات وDNS
يجب أن يستخدم تطبيق المهام الحرجة اسم مجال مخصص. ستتحكم في كيفية تدفق نسبة استخدام الشبكة إلى التطبيق الخاص بك، وتقلل من التبعيات على موفر واحد.
من الممارسات الجيدة أيضا استخدام خدمة DNS عالية الجودة ومرنة لاسم مجالك، مثل Azure DNS. إذا كانت خوادم DNS الخاصة باسم المجال غير متوفرة، فلن يتمكن المستخدمون من الوصول إلى خدمتك.
يوصى باستخدام أدوات حل DNS متعددة لزيادة المرونة الإجمالية بشكل أكبر.
تسلسل CNAME
تستخدم الحلول التي تجمع بين Traffic Manager وAzure Front Door والخدمات الأخرى عملية تحليل DNS CNAME متعددة الطبقات، تسمى أيضا تسلسل CNAME. على سبيل المثال، عند حل المجال المخصص الخاص بك، قد ترى خمسة سجلات CNAME أو أكثر قبل إرجاع عنوان IP.
يمكن أن تؤثر إضافة ارتباطات إضافية إلى سلسلة CNAME على أداء تحليل اسم DNS. ومع ذلك، عادة ما يتم تخزين استجابات DNS مؤقتا، ما يقلل من تأثير الأداء.
شهادات TLS
بالنسبة إلى تطبيق مهم، يوصى بتوفير واستخدام شهادات TLS الخاصة بك بدلا من الشهادات المدارة التي يوفرها Azure Front Door. سوف تقلل من عدد المشاكل المحتملة مع هذه البنية المعقدة.
فيما يلي بعض الفوائد:
لإصدار شهادات TLS المدارة وتجديدها، يتحقق Azure Front Door من ملكيتك للمجال. تفترض عملية التحقق من المجال أن سجلات CNAME لمجالك تشير مباشرة إلى Azure Front Door. ولكن هذا الافتراض غالبا ما يكون غير صحيح. قد لا يعمل إصدار شهادات TLS المدارة وتجديدها على Azure Front Door بسلاسة، ويمكنك زيادة مخاطر الانقطاعات بسبب مشاكل شهادة TLS.
حتى إذا كانت خدماتك الأخرى توفر شهادات TLS مدارة، فقد لا تتمكن من التحقق من ملكية المجال.
إذا حصلت كل خدمة على شهادات TLS المدارة الخاصة بها بشكل مستقل، فقد تكون هناك مشكلات. على سبيل المثال، قد لا يتوقع المستخدمون رؤية شهادات TLS مختلفة صادرة عن سلطات مختلفة، أو مع تواريخ انتهاء صلاحية مختلفة أو بصمات إبهام مختلفة.
ومع ذلك، ستكون هناك عمليات إضافية تتعلق بتجديد وتحديث الشهادات قبل انتهاء صلاحيتها.
أمان الأصل
عند تكوين الأصل لقبول نسبة استخدام الشبكة فقط من خلال Azure Front Door، يمكنك الحصول على الحماية من هجمات DDoS للطبقة 3 والطبقة 4. نظرا لأن Azure Front Door يستجيب فقط لحركة مرور HTTP صالحة، فإنه يساعد أيضا على تقليل تعرضك للعديد من التهديدات المستندة إلى البروتوكول. إذا قمت بتغيير بنيتك للسماح بمسارات دخول بديلة، فأنت بحاجة إلى تقييم ما إذا كنت قد زادت عن طريق الخطأ من تعرض أصلك للتهديدات.
إذا كنت تستخدم Private Link للاتصال من Azure Front Door بخادم الأصل، كيف تتدفق نسبة استخدام الشبكة عبر المسار البديل؟ هل يمكنك استخدام عناوين IP الخاصة للوصول إلى أصولك، أو يجب عليك استخدام عناوين IP العامة؟
إذا كان الأصل يستخدم علامة خدمة Azure Front Door ورأس X-Azure-FDID للتحقق من تدفق حركة المرور عبر Azure Front Door، ففكر في كيفية إعادة تكوين أصولك للتحقق من تدفق حركة المرور عبر أي من المسارات الصالحة. يجب عليك اختبار أنك لم تفتح أصلك عن طريق الخطأ لحركة المرور عبر مسارات أخرى، بما في ذلك من ملفات تعريف Azure Front Door للعملاء الآخرين.
عند تخطيط أمان الأصل الخاص بك، تحقق مما إذا كان مسار نسبة استخدام الشبكة البديل يعتمد على توفير عناوين IP عامة مخصصة. قد يحتاج هذا إلى عملية يتم تشغيلها يدويا لإحضار مسار النسخ الاحتياطي عبر الإنترنت.
إذا كانت هناك عناوين IP عامة مخصصة، ففكر فيما إذا كان يجب عليك تنفيذ Azure DDoS Protection لتقليل مخاطر هجمات رفض الخدمة ضد أصولك. ضع في اعتبارك أيضا ما إذا كنت بحاجة إلى تنفيذ جدار حماية Azure أو جدار حماية آخر قادر على حمايتك من مجموعة متنوعة من تهديدات الشبكة. قد تحتاج أيضا إلى المزيد من استراتيجيات الكشف عن التسلل. يمكن أن تكون عناصر التحكم هذه عناصر مهمة في بنية متعددة المسارات أكثر تعقيدا.
التصميم الصحي
تتطلب منهجية التصميم ذات المهام الحرجة نموذجا لصحة النظام يمنحك إمكانية المراقبة الشاملة للحل ومكوناته. عند استخدام مسارات دخول حركة مرور متعددة، تحتاج إلى مراقبة صحة كل مسار. إذا تم إعادة توجيه نسبة استخدام الشبكة إلى مسار الدخول الثانوي، يجب أن يعكس نموذج الصحة الخاص بك حقيقة أن النظام لا يزال قيد التشغيل ولكنه يعمل في حالة متدهورة.
قم بتضمين هذه الأسئلة في تصميم نموذج الصحة الخاص بك:
- كيف تراقب المكونات المختلفة للحل صحة مكونات انتقال البيانات من الخادم؟
- متى يجب على مراقبي الصحة اعتبار مكونات انتقال البيانات من الخادم غير سليمة؟
- كم من الوقت يستغرق الكشف عن انقطاع التيار الكهربائي؟
- بعد اكتشاف انقطاع، كم من الوقت يستغرق توجيه حركة المرور عبر مسار بديل؟
هناك العديد من حلول موازنة التحميل العمومية التي تمكنك من مراقبة صحة Azure Front Door وتشغيل تجاوز الفشل التلقائي إلى نظام أساسي للنسخ الاحتياطي في حالة حدوث انقطاع. Azure Traffic Manager مناسب في معظم الحالات. باستخدام Traffic Manager، يمكنك تكوين مراقبة نقطة النهاية لمراقبة خدمات انتقال البيانات من الخادم عن طريق تحديد عنوان URL الذي يجب التحقق منه، ومدى تكرار التحقق من عنوان URL هذا، ومتى يجب اعتبار خدمة انتقال البيانات من الخادم غير سليمة استنادا إلى استجابات الفحص. بشكل عام، كلما كان الفاصل الزمني أقصر بين عمليات التحقق، قل الوقت الذي يستغرقه Traffic Manager لتوجيه نسبة استخدام الشبكة عبر مسار بديل للوصول إلى خادم الأصل.
إذا لم يكن Front Door متوفرا، فإن عوامل متعددة تؤثر على مقدار الوقت الذي يؤثر فيه الانقطاع على نسبة استخدام الشبكة، بما في ذلك:
- وقت البقاء (TTL) على سجلات DNS.
- عدد مرات تشغيل Traffic Manager لعمليات التحقق من السلامة الخاصة به.
- كم عدد التحقيقات الفاشلة التي تم تكوين Traffic Manager لمشاهدتها قبل إعادة توجيه حركة المرور.
- المدة التي يخزن فيها العملاء وخوادم DNS المصدر استجابات DNS الخاصة ب Traffic Manager مؤقتا.
تحتاج أيضا إلى تحديد أي من هذه العوامل تقع ضمن سيطرتك وما إذا كانت الخدمات الأولية الخارجة عن سيطرتك قد تؤثر على تجربة المستخدم. على سبيل المثال، حتى إذا كنت تستخدم TTL منخفضا على سجلات DNS، فقد لا تزال ذاكرة التخزين المؤقت DNS المصدر تخدم استجابات قديمة لفترة أطول مما ينبغي. قد يؤدي هذا السلوك إلى تفاقم تأثيرات الانقطاع أو جعله يبدو وكأنه غير متوفر، حتى عندما يكون Traffic Manager قد بدل بالفعل إلى إرسال الطلبات إلى مسار حركة المرور البديل.
تلميح
تتطلب الحلول الحرجة للمهام نهج تجاوز الفشل التلقائي حيثما أمكن ذلك. تعتبر عمليات تجاوز الفشل اليدوية بطيئة حتى يبقى التطبيق مستجيبا.
توزيع وقت التعطل الصفري
عندما تخطط لكيفية تشغيل حل بمسار دخول زائد عن الحاجة، يجب عليك أيضا التخطيط لكيفية توزيع خدماتك أو تكوينها عندما تكون متدهورة. بالنسبة لمعظم خدمات Azure، تنطبق اتفاقيات مستوى الخدمة على وقت تشغيل الخدمة نفسها، وليس على عمليات الإدارة أو عمليات النشر. ضع في اعتبارك ما إذا كانت عمليات التوزيع والتكوين الخاصة بك بحاجة إلى أن تكون مرنة في مواجهة انقطاع الخدمة.
يجب عليك أيضا مراعاة عدد طائرات التحكم المستقلة التي تحتاج إلى التفاعل معها لإدارة الحل الخاص بك. عند استخدام خدمات Azure، يوفر Azure Resource Manager مستوى تحكم موحدا ومتسقا. ومع ذلك، إذا كنت تستخدم خدمة تابعة لجهة خارجية لتوجيه نسبة استخدام الشبكة، فقد تحتاج إلى استخدام وحدة تحكم منفصلة لتكوين الخدمة، ما يؤدي إلى مزيد من التعقيد التشغيلي.
تحذير
يؤدي استخدام طائرات التحكم المتعددة إلى التعقيد والمخاطر على الحل الخاص بك. تزيد كل نقطة اختلاف من احتمالية أن يفتقد شخص ما عن طريق الخطأ إعداد التكوين، أو يطبق تكوينات مختلفة على المكونات المكررة. تأكد من أن إجراءاتك التشغيلية تخفف من هذا الخطر.
الرجوع إلى: منطقة التصميم ذات المهام الحرجة: نشر وقت التعطل الصفري
التحقق المستمر
للحصول على حل مهم، تحتاج ممارسات الاختبار الخاصة بك إلى التحقق من أن الحل الخاص بك يفي بمتطلباتك بغض النظر عن المسار الذي تتدفق إليه حركة مرور التطبيق الخاص بك. ضع في اعتبارك كل جزء من الحل وكيفية اختباره لكل نوع من أنواع الانقطاع.
تأكد من أن عمليات الاختبار تتضمن هذه العناصر:
- هل يمكنك التحقق من إعادة توجيه نسبة استخدام الشبكة بشكل صحيح من خلال المسار البديل عندما يكون المسار الأساسي غير متوفر؟
- هل يمكن أن يدعم كلا المسارين مستوى حركة مرور الإنتاج التي تتوقع تلقيها؟
- هل كلا المسارين آمنين بشكل كاف، لتجنب فتح أو كشف الثغرات الأمنية عندما تكون في حالة تدهور؟
السيناريوهات الشائعة
فيما يلي سيناريوهات شائعة حيث يمكن استخدام هذا التصميم:
ينطبق تسليم المحتوى العالمي عادة على تسليم المحتوى الثابت والوسائط وتطبيقات التجارة الإلكترونية واسعة النطاق. في هذا السيناريو، يعد التخزين المؤقت جزءا مهما من بنية الحل، ويمكن أن يؤدي الفشل في ذاكرة التخزين المؤقت إلى انخفاض كبير في الأداء أو الموثوقية.
ينطبق دخول HTTP العمومي عادة على التطبيقات الديناميكية وواجهات برمجة التطبيقات ذات الأهمية الحرجة. في هذا السيناريو، يتمثل المطلب الأساسي في توجيه نسبة استخدام الشبكة إلى خادم الأصل بشكل موثوق وفعال. في كثير من الأحيان، يعد WAF عنصر تحكم أمني مهم يستخدم في هذه الحلول.
تحذير
إذا لم تكن حذرا في كيفية تصميم وتنفيذ حل معقد متعدد الدخول، يمكنك في الواقع جعل توفرك أسوأ. زيادة عدد المكونات في البنية الخاصة بك يزيد من عدد نقاط الفشل. وهذا يعني أيضا أن لديك مستوى أعلى من التعقيد التشغيلي. عند إضافة مكونات إضافية، يجب مراجعة كل تغيير تجريه بعناية لفهم كيفية تأثيره على الحل العام.
الخطوات التالية
راجع دخول HTTP العمومي وسيناريوهات تسليم المحتوى العمومي لفهم ما إذا كانت تنطبق على الحل الخاص بك.