Ribbon ist eine Komponente, die für die Lastausgleich in den Buckets der Feder Cloud Netflix -Familie verantwortlich ist. Es ist eine Sammlung von Klassenbibliotheken. Durch das Ribbon können Programmierer "transparent" Lastausgleich verwenden, ohne spezifische Implementierungsdetails einzubeziehen, ohne zu viel Code schreiben zu müssen, um Lastausgleich in Projekten zu implementieren.
Beispielsweise wird in einem Cluster, der Eureka und Ribbon enthält, ein Dienst (der als JAR -Paket verstanden werden kann) auf mehreren Servern bereitgestellt. Wenn mehrere Dienstnutzer den Dienst gleichzeitig anrufen, können diese gleichzeitigen Anforderungen mit einer angemessenen Strategie an jeden Server weitergeleitet werden.
Tatsächlich können wir bei der Verwendung verschiedener anderer Komponenten der Federwolke sehen, wie Spuren des Bandes wie Eureka in das Band integriert werden können, und die Zuul -Komponente, die die Gateway -Funktion liefert, kann auch bei Weiterleitungsanforderungen in das Band integriert werden.
Aus der Codeebene verfügt Ribbon über die folgenden drei wichtigen Schnittstellen.
Erstens iLoadbalancer, das auch als Lastausgleich bezeichnet wird. Dadurch können wir Anfragen im Projekt nach bestimmten Regeln vernünftigerweise weiterleiten. Die gemeinsame Implementierungsklasse ist Baseloadbalancer.
Zweitens verfügt diese Schnittstelle über mehrere Implementierungsklassen wie RandomRule und RoundrobenRule. Diese Implementierungsklassen definieren speziell Lastausgleichsstrategien wie "zufällige" und "Umfragen" usw. Wir können die Methoden in dieser Schnittstelle auch umschreiben, um Lastausgleichsstrategien anzupassen.
In der Baseloadbalancer -Klasse können wir Lastausgleichsrichtlinien über die IRULE -Implementierungsklasse einrichten, damit der Lastausgleich angemessen darauf basieren.
Drittens können wir über diese Schnittstelle über die IPP -Schnittstelle erhalten, welche Server derzeit verfügbar sind, und wir können die Regeln auch anpassen, um festzustellen, ob der Server verfügbar ist, indem die Methoden in dieser Schnittstelle neu geschrieben werden. In der Baseloadbalancer -Klasse können wir auch Richtlinien festlegen, um festzustellen, ob der Server über die IPing -Implementierungsklasse verfügbar ist.
1 iloadbalancer: Laell -Balancer -Schnittstelle
In der Band können wir auch Server basierend auf spezifischen Lastausgleichsrichtlinien über die Iloadbalancer -Schnittstelle auswählen.
Schauen wir uns durch die IloadbalancerDemo.java einen Blick auf die grundlegende Verwendung dieser Schnittstelle. Diese Klasse ist in das in Teil 4.2 erstellte Rabbionbasicdemo -Projekt aufgenommen, und der Code ist wie folgt.
// das erforderliche Paket weglassen und Code importieren öffentliche Klasse iloadBalancerDemo {public static void main (String [] args) {// Erstellen Sie das Iloadbalancer -Objekt iloadballer loadBalancer = new BaseloadBalancer (); // Definieren Sie eine Serverliste <Server> myServers = new ArrayList <Server> (); // Erstellen Sie zwei Serverobjekte Server s1 = neuer Server ("ekServer1", 8080); Server S2 = neuer Server ("ekServer2", 8080); // Zwei Serverobjekte in Listentyp MyServers Object myServers.add (S1) eingeben; MyServers.add (S2); // MyServers in den Last -Balancer -LoadBalancer.addServers (MyServers) eingeben; // 10 Aufrufe in die for -Schleife für (int i = 0; i <10; i ++) {// Standardladungsausgleichsregeln verwenden, um Servertyp -Objektserver s = LoadBalancer.chooServer ("Standard") zu erhalten; // Ausgabe von IP -Adresse und Portnummer System.out.println (S. Gethost () + ":" + S.Getport ()); }}}In Zeile 5 erstellen wir ein LoadBalancer -Objekt vom Typ Baseloadbalancer, und Baseloadbalancer ist die Implementierungsklasse der Lastballer -Iloadbalancer -Schnittstelle.
In Zeilen 6 bis 13 erstellen wir zwei Objekte vom Servertyp und setzen sie in MyServers ein. In Zeile 15 geben wir MyServers-Objekt vom Typ Listen-Typ in den Lastausgleich.
In der For -Loop in den Zeilen 17 bis 22 simulierten wir die Serverauswahl 10 -mal durch den Lastausgleich. In Zeile 19 wählen wir den Server mit den Standardlastausgleichsregeln über die Choiceserver -Methode von LoadBalancer aus. In Zeile 21 verwenden wir die Aktion "Print", um das tatsächliche "Serverobjekt zum Verarbeiten von Anforderungen" zu simulieren.
Die laufenden Ergebnisse des obigen Codes sind wie folgt. Wir können sehen, dass der Lastballer -Last -Balancer 10 Anfragen an 2 Server verteilt, und wir können tatsächlich den Effekt von "Lastausgleich" erkennen.
Zweitens verfügt diese Schnittstelle über mehrere Implementierungsklassen wie RandomRule und RoundrobenRule. Diese Implementierungsklassen definieren speziell Lastausgleichsstrategien wie "zufällige" und "Umfragen" usw. Wir können die Methoden in dieser Schnittstelle auch umschreiben, um Lastausgleichsstrategien anzupassen.
In der Baseloadbalancer -Klasse können wir Lastausgleichsrichtlinien über die IRULE -Implementierungsklasse einrichten, damit der Lastausgleich angemessen darauf basieren.
Drittens können wir über diese Schnittstelle über die IPP -Schnittstelle erhalten, welche Server derzeit verfügbar sind, und wir können die Regeln auch anpassen, um festzustellen, ob der Server verfügbar ist, indem die Methoden in dieser Schnittstelle neu geschrieben werden. In der Baseloadbalancer -Klasse können wir auch Richtlinien festlegen, um festzustellen, ob der Server über die IPing -Implementierungsklasse verfügbar ist.
ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver1: 8080
2 iRule: Schnittstelle, die Lastausgleichsregeln definiert
In der Band können wir entsprechende Regeln für den Lastausgleich festlegen, indem wir die Implementierungsklasse der iRule -Schnittstelle definieren. In der folgenden Tabelle sehen wir einige häufig verwendete Implementierungsklassen der iRule -Schnittstelle.
Der Name der Implementierungsklasse | Lastausgleichsregeln |
RandomRule | Eine zufällig ausgewählte Strategie anwenden |
RoundrobinRule | Eine Wahlstrategie verfolgen |
Wiederholung | Bei der Verwendung dieser Strategie ist eine Wiederholungsaktion enthalten |
Verfügbarkeitsfilterru | Es filtert Server mit mehreren Verbindungsfehlern und einer übermäßigen Anfrage zur Parallelität |
Gewichtsresponsetimerule | Legen Sie ein Gewicht für jeden Server gemäß der durchschnittlichen Antwortzeit ein und wählen Sie Server mit einer geringeren durchschnittlichen Antwortzeit aus diesem Gewichtswert aus. |
Zoneavoidanzer | Die Zuweisung der Anfrage an Server mit der gleichen Zone wie die Anfrage |
Schauen wir uns im folgenden IRLEDEMO.JAVA -Programm einen Blick auf die grundlegende Nutzung von Irule an.
// das erforderliche Paket weglassen und Code importieren öffentliche Klasse Iruleedemo {public static void main (String [] args) {// Bitte beachten Sie, dass dies für BaseloadBalancer verwendet wird, nicht für Iloadbalancer -SchnittstellenbaseloadBalancer LoadBalancer = New BaseloadBalancer (); // die Lastausgleichspolitik an der Grundlage der IRULE -Regel für die Wahl des Lastausgleichs deklarieren = neuer RoundRobinrule (); // Lastbalancer festlegen. // 3 Server wie folgt definieren und in eine Sammlung von Listentypliste <Server> myServers = new ArrayList <Server> () geben; Server S1 = neuer Server ("ekServer1", 8080); Server S2 = neuer Server ("ekServer2", 8080); Server S3 = neuer Server ("ekServer3", 8080); MyServers.add (S1); MyServers.add (S2); MyServers.add (S3); // Setzen Sie die Liste des Servers lastbalancer.addServers (myServers); // Ausgeben das Ergebnis des Lastausgleichs für (int i = 0; i <10; i ++) {Server s = loadBalancer.chooServer (null); System.out.println (S. Gethost () + ":" + S.Getport ()); }}}Dieser Code ist dem obigen Artikel sehr ähnlich wie bei iLoadbalancerDemo.java, es gibt jedoch die folgenden Unterschiede.
1 In Zeile 5 definieren wir den Lastausgleich über die Baseloadbalancer -Klasse anstelle der Schnittstelle, da die Klasse die SetRule -Methode enthält.
2 Definieren Sie ein Regelobjekt basierend auf der Wahlregel in Zeile 7 und stellen Sie es in den Lastausgleich in Zeile 9 ein.
3 In Zeile 19 setzen wir das Listenobjekt mit 3 Servern in den Lastausgleich anstelle der beiden vorherigen. Da es hier zu Demonstrationszwecken gespeichert wird, werden wir einen "EkServer3" -Server aufnehmen, der überhaupt nicht existiert.
Nach dem Ausführen des Programms können wir sehen, dass es 10 Ausgänge gibt, und es gibt tatsächlich die Namen von 3 Servern nach der "Polling" -Regel aus. Wenn wir den Code in Zeile 7 in Folgendes ändern, wird der Servername "zufällig" ausgegeben.
IRule regel = new randomRule ();
3 IPING: Die Schnittstelle zum Bestimmen, ob der Server verfügbar ist
Im Projekt lassen wir die IloadBalancer -Schnittstelle normalerweise automatisch feststellen, ob der Server verfügbar ist (diese Dienste sind in den zugrunde liegenden Code von Ribbon eingekapselt). Darüber hinaus können wir die IPing -Schnittstelle in der Bandkomponente verwenden, um diese Funktion zu implementieren.
Im folgenden Code von Iruledemo.java werden wir die allgemeine Verwendung der IPing -Schnittstelle demonstrieren.
// Die erforderlichen Paket- und Importcodeklasse implementiert. } Return true; }}
Die in Zeile 2 definierte MyPing -Klasse implementiert die IPP -Schnittstelle und überschreibt die ISALIVE -Methode in Zeile 3.
In dieser Methode beurteilen wir nach dem Servernamen. Wenn der Name EkServer2 ist, gibt er insbesondere False zurück, was bedeutet, dass der Server nicht verfügbar ist, andernfalls gibt er True zurück, was bedeutet, dass der aktuelle Server verfügbar ist.
öffentliche Klasse iRuledemo {public static void main (String [] args) {BaseloadBalancer loadBalancer = new BaseloadBalancer (); // Definieren Sie das Myping -Objekt, mit dem Sie myPing = new myPing () iPing -Typ iPing -Typ definieren; // Verwenden Sie den MyPing -Objekt -LoadBalancer. Seting (MyPing); // Erstellen Sie drei Serverobjekte und setzen Sie sie in die Liste der Lade -Balancer -Liste <Server> myServers = new ArrayList <Server> (); Server S1 = neuer Server ("ekServer1", 8080); Server S2 = neuer Server ("ekServer2", 8080); Server S3 = neuer Server ("ekServer3", 8080); MyServers.add (S1); MyServers.add (S2); MyServers.add (S3); loLeBalancer.AdsServers (myServers); // den Server mehrmals über eine für die Schleife für (int i = 0; i <10; i ++) {Server s = loadBalancer.chooServer (null) anfordern; System.out.println (S. Gethost () + ":" + S.Getport ()); }}}In der Hauptfunktion in Zeile 12 erstellen wir in Zeile 15 ein IPing -Typ Myping -Objekt und setzen dieses Objekt in Zeile 17 in den Lastausgleich. Durch den Code in den Zeilen 18 bis 26 erstellen wir drei Server und setzen sie auch in den Lastausgleicher ein.
In der für Schleife in Zeile 28 fordern und geben wir den Servernamen weiterhin an. Da der Last -Balancer hier ein IPP -Objekt enthält, wird nach Erhalt des Servers gemäß der Richtlinie bestimmt, ob der Server basierend auf der isaktiven Methode in MyPing verfügbar ist.
Da wir in dieser Methode definieren, dass das Server EkServer2 nicht verfügbar ist, wird das Last -Balancer -LoadBalancer -Objekt niemals die Anforderung an den Server senden, dh im Ausgabeergebnis werden wir nicht die Ausgabe von "EkServer2: 8080" angezeigt.
Daraus können wir die allgemeine Verwendung der IPing -Schnittstelle sehen. Wir können die Logik "beurteilen, ob der Server verfügbar ist" definieren, indem wir die ISALIVE -Methode neu schreiben. In den tatsächlichen Projekten ist die Grundlage für das Urteilsvermögen nichts weiter als "ob der Server zu lange antwortet" oder "ob die Anzahl der an den Server gesendeten Anfragen zu viele ist". Diese Urteilsmethoden werden in der iRule -Schnittstelle und ihrer Implementierungsklasse eingekapselt. In allgemeinen Szenarien verwenden wir die IPP -Schnittstelle.
Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, es wird für das Lernen aller hilfreich sein und ich hoffe, jeder wird Wulin.com mehr unterstützen.