نقاش شو هو مفهوم Load Balancing وكيف بيمكن استخدامه مع Shopware؟

[Akram Mohra]

لأصحاب الخبرة، ايش هو مفهوم Load Balancing وكيف بيمكن تطبيقه مع أنظمة التسوق الإلكتروني (E-Commerce) مثل Shopware؟

 

[Mohammad Mustafa]

هلق هوي ما الو علاقة بنظام معين هوي لتحسين الأداء و توزيع الضغط على السيرفرات بس في كم شغلة لازم تفهمها بالأول
مشان تعمل scaling لمشروع في عندك نوعين من ال scaling

1. Vertical Scaling: هوي بكل بساطة انو انت يزود قدرة السيرفر من رام و معالجة و هيك قصص و من ايجابياتو انو بسيط بس من سلبياتو انو الو حد معين و كمان انو انت عندك single point of faliure لأن اذا وقع السيرفر بيوقع الموقع
2. Horizental Scaling: هون انت بتخلي يكون عندك كم سيرفر و بصير لما بيجيك ريكوست بكون في load balancer بيعمل redirect للريكوست لواحد من هالسيرفرات و هون حلاوتو انو بتزيد الأداء قد ما بدك بانك تزيد سيرفرات و في تقللو أحيانا اذا بدك بانك تشيل سيرفر او اكتر و هاد الشي بكون بناءا ع ال load يلي عندك
   من الايجابيات انو هوي بزيد ال availability للموقع تبعك و حتى لو وقع سيرفر في سيرفر بنوب عنو فهون انت بتكون تجنبت ال single point of failure و كمان من الايجابيات التانية انو الديناميكية ففيك قد ما بدك تزود او تنقص سيرفرات على حسب اللود
   من السلبيات هوي التعقيد تبعو فبدك management الو كمان اذا تطبيقك stateful هوي بدك طريقة انو تنقل ال state بين السيرفرات كمثال من shopware افترض انو اجت ريكوست على سيرفر A و هون كان الها session_id معين و لنفرض انو هوي 1 و من بعدها اجا نفس اليوزر عمل ريكوست تاني و راحت على سيرفر B فهون السيرفر B ما عندو ال session أو ال state لهيك بقلك لا تواخذني بس ما بعرفك
   طبعا هي المشكلة الها حلول متل حل ال sticky sessions و هيي انو تروح ع نفس السيرفر كل مرة بس انا هاد ما بحبو لانو بيرجعنا لل single point of faliure
   و حل تاني انو تخزن ال sessions بداتابيز متل Redis أو Mongo بحيث انو دائما تجيب ال session منها
   الصورة للتوضيح
   اقرأ المزيد: https://bytebytego.com/courses/system-design-interview/scale-from-zero-to-millions-of-users

 

[Qusay Alhasan]

هلق هوي ما الو علاقة بنظام معين هوي لتحسين الأداء و توزيع الضغط على السيرفرات بس في كم شغلة لازم تفهمها بالأول
مشان تعمل scaling لمشروع في عندك نوعين من ال scaling

1. Vertical Scaling: هوي بكل بساطة انو انت يزود قدرة السيرفر من رام و معالجة و هيك قصص و من ايجابياتو انو بسيط بس من سلبياتو انو الو حد معين و كمان انو انت عندك single point of faliure لأن اذا وقع السيرفر بيوقع الموقع
2. Horizental Scaling: هون انت بتخلي يكون عندك كم سيرفر و بصير لما بيجيك ريكوست بكون في load balancer بيعمل redirect للريكوست لواحد من هالسيرفرات و هون حلاوتو انو بتزيد الأداء قد ما بدك بانك تزيد سيرفرات و في تقللو أحيانا اذا بدك بانك تشيل سيرفر او اكتر و هاد الشي بكون بناءا ع ال load يلي عندك
   من الايجابيات انو هوي بزيد ال availability للموقع تبعك و حتى لو وقع سيرفر في سيرفر بنوب عنو فهون انت بتكون تجنبت ال single point of failure و كمان من الايجابيات التانية انو الديناميكية ففيك قد ما بدك تزود او تنقص سيرفرات على حسب اللود
   من السلبيات هوي التعقيد تبعو فبدك management الو كمان اذا تطبيقك stateful هوي بدك طريقة انو تنقل ال state بين السيرفرات كمثال من shopware افترض انو اجت ريكوست على سيرفر A و هون كان الها session_id معين و لنفرض انو هوي 1 و من بعدها اجا نفس اليوزر عمل ريكوست تاني و راحت على سيرفر B فهون السيرفر B ما عندو ال session أو ال state لهيك بقلك لا تواخذني بس ما بعرفك
   طبعا هي المشكلة الها حلول متل حل ال sticky sessions و هيي انو تروح ع نفس السيرفر كل مرة بس انا هاد ما بحبو لانو بيرجعنا لل single point of faliure
   و حل تاني انو تخزن ال sessions بداتابيز متل Redis أو Mongo بحيث انو دائما تجيب ال session منها
   الصورة للتوضيح
   اقرأ المزيد: https://bytebytego.com/courses/system-design-interview/scale-from-zero-to-millions-of-users

مشاهدة المرفق 9

جوابك على السؤال كافي ووافي أخي بس حابب ضيف بعض الأمثلة على مبدأ عمل Loadbalancer مع Shopware:

لنفترض عندك سيرفر موازن حمل (Loadbalancer) بالاضافة ل 3 سيرفرات اضافية منفصلة أيضا, كيف بهي الحالة بيتم توزيع الترافيك ل Shopware على الخوادم المذكورة؟

خلينا نوضح هالحالة ببساطة, عندك السيرفر الأول هو لل Backend مخصص للوحة التحكم "/admin" الخاص Shopware وعندك سيرفرين للـ Frontend مخصصين للترافيك العادي للمتجر (مثل تصفح المنتجات، السلة، إلخ).
لما حدا يحاول يدخل على لوحة التحكم (/admin) الـ Load Balancer بيفهم من الـ URL أنه هالطلب موجه لسيرفر ال Backend لهيك بيحول هالترافيك مباشرة لسيرفر الـ Backend المخصص، يلي بيشتغل على معالجة طلبات لوحة التحكم أو ادارة المواقع. مثلا لو مدير الموقع بده يعدل المنتجات أو يشوف الطلبات، الترافيك بيوصل لسيرفر Backend فورا أما بالنسبة الترافيك العادي للـ Frontend (تصفح المتجر) فينا نقول انو أي طلب تاني ما بيحتوي على /admin، الـ Load Balancer بيقوم بتوزيعه بين السيرفرين المخصصين للـ Frontend أو التصفح العادي للمتجر من قبل الزوار أو العملاء وطبعا ال Loadbalancer بيحلل هي الزيارات (Requests) وبعيد توجيهها على احد سيرفرات ال Frontend المتاحة بناءً على سياسة توزيع معينة على سبيل المثال Round Robin. بهالطريقة بنضمن إن الترافيك الخاص بلوحة التحكم /admin منفصل بشكل كلي عن الترافيك العادي، وبيضل فيه توزيع منظم للترافيك بين السيرفرات، بحيث كل سيرفر بيأدي مهام معينة ومنضمن انو شغال بكفاءة. هيك بيكون عندنا نظام لتوزيع الحمل أمن ودقيق ومرن، ويلي طبعا بيعطي مرونة وأداء عالي لمنصة التسوق. بتمنى كون قدمت قيمة اضافية لشرحك الجميل.

 

[Akram Mohra]

هلق هوي ما الو علاقة بنظام معين هوي لتحسين الأداء و توزيع الضغط على السيرفرات بس في كم شغلة لازم تفهمها بالأول
مشان تعمل scaling لمشروع في عندك نوعين من ال scaling

1. Vertical Scaling: هوي بكل بساطة انو انت يزود قدرة السيرفر من رام و معالجة و هيك قصص و من ايجابياتو انو بسيط بس من سلبياتو انو الو حد معين و كمان انو انت عندك single point of faliure لأن اذا وقع السيرفر بيوقع الموقع
2. Horizental Scaling: هون انت بتخلي يكون عندك كم سيرفر و بصير لما بيجيك ريكوست بكون في load balancer بيعمل redirect للريكوست لواحد من هالسيرفرات و هون حلاوتو انو بتزيد الأداء قد ما بدك بانك تزيد سيرفرات و في تقللو أحيانا اذا بدك بانك تشيل سيرفر او اكتر و هاد الشي بكون بناءا ع ال load يلي عندك
   من الايجابيات انو هوي بزيد ال availability للموقع تبعك و حتى لو وقع سيرفر في سيرفر بنوب عنو فهون انت بتكون تجنبت ال single point of failure و كمان من الايجابيات التانية انو الديناميكية ففيك قد ما بدك تزود او تنقص سيرفرات على حسب اللود
   من السلبيات هوي التعقيد تبعو فبدك management الو كمان اذا تطبيقك stateful هوي بدك طريقة انو تنقل ال state بين السيرفرات كمثال من shopware افترض انو اجت ريكوست على سيرفر A و هون كان الها session_id معين و لنفرض انو هوي 1 و من بعدها اجا نفس اليوزر عمل ريكوست تاني و راحت على سيرفر B فهون السيرفر B ما عندو ال session أو ال state لهيك بقلك لا تواخذني بس ما بعرفك
   طبعا هي المشكلة الها حلول متل حل ال sticky sessions و هيي انو تروح ع نفس السيرفر كل مرة بس انا هاد ما بحبو لانو بيرجعنا لل single point of faliure
   و حل تاني انو تخزن ال sessions بداتابيز متل Redis أو Mongo بحيث انو دائما تجيب ال session منها
   الصورة للتوضيح
   اقرأ المزيد: https://bytebytego.com/courses/system-design-interview/scale-from-zero-to-millions-of-users

مشاهدة المرفق 9

صديقي شكرا الك شكلو الموضوع طلع بسيط مو متل ما توقعت حبيبي ما قصرت

 

[Morgan]

جزي الله خيرا الاخوة جاوبوا وكفو ، و لو حب احد من الإخوة الاستزاده في مجال تصميم النظم ذات البيانات الضخمة ، فانصحه بكتاب
Designing Data-Intensive Applications_ The Big Ideas Behind Reliable, Scalable, and Maintainable Systems-
للكاتب Kleppmann
وهو بيتكلم عن المفاهيم و بيتعرض في الكناب للمشكلات التي قد تواجه تلك التطبيقات (اي التطبيقات العملية لفض النظر كان العميل ويب او موبيل اب او برنامج كمبيوتر ) وكيفية حلها مع بعض الامثلة التي حدثت في الواقع مع شركات التكنولوجيا العملاقة