شرح مفصل لاستخدام الفصول المهمة في الشريط ، مكونات مهمة لموازنة الحمل السحابي الربيعي

الشريط هو مكون مسؤول عن موازنة التحميل في دلاء عائلة Netflix Cloud Spring. إنها مجموعة من مكتبات الفصل. من خلال الشريط ، يمكن للمبرمجين استخدام موازنة التحميل "بشفافية" دون إشراك تفاصيل تنفيذ محددة ، دون الحاجة إلى كتابة الكثير من التعليمات البرمجية لتنفيذ موازنة التحميل في المشاريع.

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

في الواقع ، عند استخدام مكونات مختلفة من سحابة الربيع ، يمكننا رؤية آثار الشريط ، مثل Eureka يمكن دمجها مع الشريط ، ويمكن أيضًا دمج مكون Zuul الذي يوفر وظيفة البوابة مع الشريط عند إعادة توجيه طلبات.

من مستوى الكود ، يحتوي الشريط على الواجهات الثلاثة التالية الأكثر أهمية.

أولاً ، iloadbalancer ، والذي يسمى أيضًا موازن الحمل. من خلال ذلك ، يمكننا إعادة توجيه الطلبات بشكل معقول في المشروع وفقًا لقواعد محددة. فئة التنفيذ المشتركة هي baseloadbalancer.

ثانياً ، irule ، تحتوي هذه الواجهة على فئات تنفيذ متعددة ، مثل RandomRule و RoundRobinrule. تحدد فئات التنفيذ هذه على وجه التحديد استراتيجيات موازنة التحميل مثل "عشوائي" و "الاقتراع" ، وما إلى ذلك. يمكننا أيضًا إعادة كتابة الأساليب في هذه الواجهة لتخصيص استراتيجيات موازنة التحميل.

في فئة BaseloadBalancer ، يمكننا إعداد سياسات موازنة التحميل من خلال فئة تنفيذ IRULE ، بحيث يمكن لموازن التحميل إعادة توجيه الطلبات بشكل معقول بناءً على ذلك.

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

1 iloadbalancer: واجهة loadbalancer

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

من خلال iloadbalancerdemo.java أدناه ، دعونا نلقي نظرة على الاستخدام الأساسي لهذه الواجهة. يتم وضع هذه الفئة في مشروع RabbionbasicDemo الذي تم إنشاؤه في الجزء 4.2 ، والرمز كما يلي.

 // حذف الحزمة الضرورية واستيراد كود الفئة العامة iloadbalancerdemo {public static void main (string [] args) {// إنشاء كائن IloAdbalancer Iloadbalancer loadbalancer = new baseloadbalancer () ؛ . // إنشاء كائن خادمين خادم S1 = خادم جديد ("Ekserver1" ، 8080) ؛ الخادم S2 = خادم جديد ("Ekserver2" ، 8080) ؛ // ضع كائنين خادمين في قائمة كائن MyServers MyServers.Add (S1) ؛ myservers.add (S2) ؛ // ضع myservers في Load Balancer LoadBalancer.AddServers (myservers) ؛ // ابدأ 10 مكالمات في الحلقة لـ (int i = 0 ؛ i <10 ؛ i ++) {// استخدم قواعد موازنة التحميل الافتراضية للحصول على خادم كائن نوع الخادم s = loadbalancer.chooseServer ("Default") ؛ // Output IP عنوان و NUMBER SYSTEM.UT.PRINTLN (S.Gethost () + ":" + S.GetPort ()) ؛ }}}

في السطر 5 ، نقوم بإنشاء كائن loadbalancer من نوع baseloadbalancer ، و baseloadbalancer هو فئة تنفيذ واجهة موازن الحمل IloAdbalancer.

في الأسطر 6 إلى 13 ، نقوم بإنشاء كائنين من نوع الخادم ونضعهما في MyServers. في السطر 15 ، وضعنا كائن MyServers من نوع القائمة في موازن التحميل.

في الحلقة على الخطوط 17 إلى 22 ، قمنا بمحاكاة اختيار الخادم 10 مرات من خلال موازن التحميل. على وجه التحديد ، في السطر 19 ، نختار الخادم مع قواعد موازنة التحميل الافتراضية من خلال طريقة choiceserver من loadbalancer. في السطر 21 ، نستخدم الإجراء "طباعة" لمحاكاة "كائن الخادم الفعلي" لمعالجة إجراءات "الطلبات".

نتائج تشغيل الكود أعلاه هي كما يلي. يمكننا أن نرى أن موازن تحميل LoadBalancer يوزع 10 طلبات على خادمين ، ويمكننا بالفعل أن نرى تأثير "موازنة التحميل".

ثانياً ، irule ، تحتوي هذه الواجهة على فئات تنفيذ متعددة ، مثل RandomRule و RoundRobinrule. تحدد فئات التنفيذ هذه على وجه التحديد استراتيجيات موازنة التحميل مثل "عشوائي" و "الاقتراع" ، وما إلى ذلك. يمكننا أيضًا إعادة كتابة الأساليب في هذه الواجهة لتخصيص استراتيجيات موازنة التحميل.

في فئة BaseloadBalancer ، يمكننا إعداد سياسات موازنة التحميل من خلال فئة تنفيذ IRULE ، بحيث يمكن لموازن التحميل إعادة توجيه الطلبات بشكل معقول بناءً على ذلك.

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

 ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver1: 8080

2 irule: واجهة تحدد قواعد موازنة التحميل

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

في برنامج Iroledemo.java التالي ، دعونا نلقي نظرة على الاستخدام الأساسي لـ Irule.

 . // إعلان سياسة موازنة التحميل بناءً على قاعدة الاقتراع IRULE = RoundRobinRule () جديد ؛ // قم بتعيين السياسة loadbalancer.setRule (القاعدة) ؛ . الخادم S1 = خادم جديد ("Ekserver1" ، 8080) ؛ الخادم S2 = خادم جديد ("Ekserver2" ، 8080) ؛ الخادم S3 = خادم جديد ("Ekserver3" ، 8080) ؛ myservers.add (s1) ؛ myservers.add (S2) ؛ myservers.add (S3) ؛ // قم بتعيين قائمة الخادم loadbalancer.addservers (myservers) ؛ // إخراج نتيجة موازنة التحميل لـ (int i = 0 ؛ i <10 ؛ i ++) {server s = loadbalancer.chooseServer (null) ؛ System.out.println (S.Gethost () + ":" + S.GetPort ()) ؛ }}}

يشبه هذا الرمز إلى حد كبير IloAdbalancerDemo.java في المقالة أعلاه ، ولكن هناك الاختلافات التالية.

1 في السطر 5 ، نحدد موازن التحميل من خلال فئة baseloadbalancer بدلاً من الواجهة لأن الفئة تحتوي على طريقة setRule.

2 حدد كائن قاعدة بناءً على قاعدة الاقتراع في السطر 7 وقم بتعيينه في موازن التحميل في السطر 9.

3 في السطر 19 ، وضعنا كائن القائمة الذي يحتوي على 3 خوادم في موازن التحميل ، بدلاً من السابقين. نظرًا لأنه يتم تخزينه هنا لأغراض العرض التوضيحي ، فسوف نضع خادم "ekserver3" غير موجود على الإطلاق.

بعد تشغيل البرنامج ، يمكننا أن نرى أن هناك 10 مخرجات ، وهو بالفعل يخرج أسماء 3 خوادم بالتسلسل وفقًا لقاعدة "الاقتراع". إذا قمنا بتغيير الكود في السطر 7 إلى ما يلي ، فسنرى اسم الخادم "بشكل عشوائي".

 IRULE RULE = New RandomRule () ؛

3 iping: الواجهة لتحديد ما إذا كان الخادم متاحًا

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

في رمز Iruledemo.java التالي ، سوف نوضح الاستخدام العام لواجهة Iping.

 // حذف الحزمة الضرورية والاستيراد فئة رمز myping iping {public boolean isAlive (server server) {// إذا كان اسم الخادم هو ekserver2 ، إرجاع خطأ if (server.gethost (). يساوي ("ekserver2")) {return false ؛ } إعادة صواب ؛ }}

تقوم فئة myping المحددة في السطر 2 بتنفيذ واجهة Iping ويتجاوز طريقة isalive في السطر 3.

في هذه الطريقة ، نحكم على اسم الخادم. على وجه التحديد ، إذا كان الاسم هو ekserver2 ، فإنه يعيد خطأ ، مما يعني أن الخادم غير متوفر ، وإلا فإنه يعود صحيحًا ، مما يعني أن الخادم الحالي متاح.

 الفئة العامة Iruledemo {public static void main (string [] args) {baseloadbalancer loadBalancer = new BaseloadBalancer () ؛ // تحديد كائن myping من نوع iping iping myping = جديد myping () ؛ // استخدم myping object loadbalancer.setping (myping) ؛ // قم بإنشاء ثلاثة كائنات خادم ووضعها في قائمة موازن التحميل <Rover> myservers = new ArrayList <Sroder> () ؛ الخادم S1 = خادم جديد ("Ekserver1" ، 8080) ؛ الخادم S2 = خادم جديد ("Ekserver2" ، 8080) ؛ الخادم S3 = خادم جديد ("Ekserver3" ، 8080) ؛ myservers.add (s1) ؛ myservers.add (S2) ؛ myservers.add (S3) ؛ loadBalancer.addservers (myservers) ؛ // اطلب الخادم عدة مرات من خلال حلقة لـ (int i = 0 ؛ i <10 ؛ i ++) {server s = loadbalancer.chooseServer (null) ؛ System.out.println (S.Gethost () + ":" + S.GetPort ()) ؛ }}}

في الوظيفة الرئيسية في السطر 12 ، نقوم بإنشاء كائن myping type في السطر 15 ، ونضع هذا الكائن في موازن التحميل في السطر 17. من خلال الكود في الأسطر من 18 إلى 26 ، نقوم بإنشاء ثلاثة خوادم ونضعها في موازن التحميل أيضًا.

في الحلقة على السطر 28 ، ما زلنا نطلب اسم الخادم ونخرجه. نظرًا لأن BALANCER الحمل هنا يحتوي على كائن نوع IPing ، بعد الحصول على الخادم وفقًا للسياسة ، سيحدد ما إذا كان الخادم متاحًا بناءً على طريقة ISACTY في MYPING.

نظرًا لأنه في هذه الطريقة ، نحدد أن Server Ekserver2 غير متوفر ، لن يرسل كائن Load Balancer LoadBalancer أبدًا الطلب إلى الخادم ، أي في نتيجة الإخراج ، لن نرى إخراج "Ekserver2: 8080".

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

ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.