Sharding (كذا!) المستوى على شبكة الإنترنت من أجل منع عنق الزجاجة موازن الحمل؟

Question

كيف تحقق مواقع الويب الكبيرة التي لا يمكن أن تكون عديمة الجنسية تمامًا قابلية التوسع الشديدة في طبقة الويب؟

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

من ناحية أخرى ، تم تحجيم كل من eBay وكذلك Amazon بشكل كبير. الشائعات هو أن هناك حوالي 15000 خوادم تطبيق J2EE في eBay.

كيف تتعامل هذه المواقع على حد سواء: قابلية التوسع الشديدة والدولة؟ نظرًا لأن الموقع مناسب ، فليس من الممكن القيام بتوازن بسيط في DNS. لذلك يمكن للمرء أن يفترض أن هذه الشركات لديها موازن تحميل على أساس الأجهزة مثل Bigip أو Netscaler أو شيء من هذا القبيل ، وهو الجهاز الوحيد وراء عنوان IP واحد لهذا الموقع. من شأن هذا الحمل أن فك تشفير SSL (إذا تم ترميزه) ، وتفقد ملف تعريف الارتباط ويقرر اعتمادًا على معرف الجلسة لهذا ملف تعريف الارتباط الذي يحتفظ به خادم التطبيق على جلسة ذلك العميل.

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

أيضًا ، يتم إجراء توازن التحميل بشفافية للمستخدم ، أي لم يتم إعادة توجيه المستخدمين إلى عناوين مختلفة ، ولكن لا يزال جميعهم يبقون جماعيًا على www.amazon.com طوال الوقت.

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

يحرر: أدركت أنه لا توجد سوى حاجة إلى الشفافية ، إذا كانت هناك حاجة إلى أن يكون الموقع العنكبوت ومرجعية. على سبيل المثال ، إذا كان الموقع مجرد تطبيق ويب ، شيء يشبه نظام حجز تذاكر الطائرة أو قطار ، فلا ينبغي أن تكون هناك مشكلة في إعادة توجيه المستخدمين إلى مجموعات محددة من خوادم الويب خلف عناوين URL المختلفة ، على سبيل المثال A17.TicketReservation.com. في هذه الحالة المحددة ، سيكون من الممكن مجرد استخدام مجموعات متعددة من خوادم التطبيق ، كل منها خلف موازن التحميل الخاص به. ومن المثير للاهتمام ، لم أجد موقعًا يستخدم هذا النوع من المفاهيم.يحرر: لقد وجدت هذا المفهوم ناقش في Highscalability.com, ، حيث تشير المناقشة إلى مقال كتبه لي تشو "موازنة التحميل جانب العميل لتطبيقات الويب 2.0". يستخدم Lei Zhu البرمجة النصية المتقاطعة للقيام بهذا التحميل الجانبي للعميل في موازنة شفافية.

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

يمكن أن يكون هناك إعادة توجيه بسيطة من الموقع الرئيسي إلى الخادم ، مثل إعادة توجيه من www.ticketreservation.com إلى A17.TicketReservation.com. من هناك على المستخدم يبقى في الخادم A17. A17 ليس خادمًا ، ولكنه مجموعة نفسها ، يمكن من خلالها تحقيق التكرار.

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

بطبيعة الحال ، فإن إعادة التوجيه إلى عناوين URL المختلفة تبدو سيئة للغاية ، ولكن مع مجرد تطبيقات الويب (التي لا تحتاج إلى أن تكون عنكبوتًا أو مرتبطًا بعمق أو بعمق على أي حال) ، يجب أن يكون هذا مجرد مشكلة بصرية للمستخدم؟

يمكن للكتلة المعاد توجيهها استطلاع حمولة مجموعات التطبيق وتكييف عمليات إعادة التوجيه وفقًا لذلك ، وبالتالي تحقيق التوازن وليس مجرد توزيع الحمل.

Answer 1

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

إن سرعة Memcached و Microsoft هي منتجات تحل هذه الحاجة الدقيقة.

تحرير: كيف يعرف خادم الويب خادم التطبيق الذي يجب الاتصال به؟ يتم تضمين هذا في تجزئة معرف الجلسة ، ويمكن أن يتم ذلك بشكل عام كما تريد. قد يكون الأمر بسيطًا مثل معرف الجلسة الخاص بك هو الخادم: GUID. memcached قواعد على التجزئة ، رغم ذلك.

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

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

تحتوي خوادم التطبيقات هذه على DAL "ذكي" تقوم بتوجيهات إلى قواعد البيانات المتقلبة (المقسم لكل من الوظيفة والبيانات ، وبالتالي المستخدمين على قاعدة البيانات 1 ، والمستخدمين MZ على قاعدة البيانات 2 ، والمواد 1-10000 على العناصر 1 ، وما إلى ذلك).

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

هذا هو مماثل إلى ما نشرته أعلاه ، فقط انتقلت إلى أسفل طبقة. بدلاً من وجود خادم الويب ، حدد خادم التطبيق الذي يجب الاتصال به ، يحدد خادم التطبيق قاعدة البيانات التي يجب الاتصال بها. فقط ، في حالة eBay ، يمكن أن تصل فعليًا إلى أكثر من 20 خوادم قاعدة بيانات بسبب استراتيجية التقسيم الخاصة بهم. ولكن ، مرة أخرى ، فإن الطبقة عديمة الجنسية لديها نوع من القواعد (القواعد) التي تستخدمها للاتصال بالمستوى الدقيق. ومع ذلك ، فإن قواعد eBay أكثر تعقيدًا قليلاً من القاعدة "user1 user1 على Server10" التي كنت أشرحها أعلاه.

Answer 2

قد تجد الورقة التالية مفيدة ، والتي تعرض تصميم وتنفيذ نظام تخزين قيمة رئيسي متاح للغاية تستخدمه بعض الخدمات الأساسية لـ Amazon لتوفير تجربة "دائمًا":

جوزيبي ديكانديا ، دنيز هاستورون ، مادان جامباني ، غونافاردهان كاكولاباتي ، أفيناش لاكشمان ، أليكس بيلشين ، سوامي سيفاسوبرامانيان ، بيتر فوسهال ، ويرنر فوجيلز, “Dynamo: متجر أمازون المتاح للغاية لقيمة المفاتيح"، في وقائع ندوة ACM الحادية والعشرين حول مبادئ أنظمة التشغيل ، ستيفنسون ، واشنطن ، أكتوبر 2007.

Answer 3

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

العمارة eBay و العمارة الأمازون

مجرد موازن حمولة واحدة في حد ذاته في عالم اليوم هو نوع من ما يعادل DNS Round Robin من السنوات الماضية. اليوم لديك أشياء مثل Anycast هذا يتيح لك لعب جميع أنواع الحيل. يمكنك أن تكون متأكدًا تمامًا من أن أمثال eBay و Amazon تستخدم موازنات الحمل وأنهم يستخدمون الكثير منها.

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

إذا لم ينقلك ذلك إلى حد أنه يمكن لموازن التحميل الواحد التعامل مع الحمل ، فإن الخطوة التالية لأعلى هي كسر المعاملات باستخدام توجيه IP و/أو GEO-DNS. ستكون المواقع الكبيرة مثل eBay و Amazon في عدد من المراكز المختلفة مع عدد كبير من اتصالات الإنترنت في كل منها. أنت تأخذ كل شيء قادمًا من الإنترنت Pop Quest-West وترسله إلى خوادم "Quest" لـ West Coast Coast ، أي شيء من ATT-West يتم إرساله إلى خوادم ATT "ATT" خوادم "Quest" لمادة بيانات الساحل الشرقي ، وما إلى ذلك. يمكن أن يكون كل من هذه الأنظمة جزيرة حمولة واحدة يمكن أن تتعامل مع الحمل ، ويمكن لبعض موازنات الحمل أن يتعامل مع مئات الآلاف من المعاملات. على الجانب الخلفي ، تكرر بكميات كبيرة لكل مركز بيانات باستمرار ولكن يمكن أن يكون غير متزامن.

Answer 4

لا أعرف كيف يفعلون ذلك ، ولكن إليك بعض الاقتراحات:

• لتجنب التحميل الزائد لمضيف التحميل ، استخدم DNS Round-Robin أو
• إعادة توجيه عملاء مختلفين إلى عناوين مجموعات مختلفة بناءً

لتوزيع تحميل الطبقة المتوسطة ،

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

لتوزيع تحميل قاعدة بيانات النهاية الخلفية

• "التقليدية" التقليدية من "الوقت الحقيقي" لكل حساب أو بيانات لكل مستخدم
• تكرار بشكل غير متزامن البيانات المتغيرة ببطء أو ثابتة نسبيا ؛ يمكن للمستخدمين رؤيته خارج التاريخ (ولكن ليس في معظم الوقت). تتصل خوادم الطبقة الوسطى وخوادم الويب بقاعدة بيانات محلية بموقعها الخاص