Le ruban est un composant responsable de l'équilibrage de la charge dans les seaux de famille Netflix Cloud Spring. Il s'agit d'une collection de bibliothèques de classe. Grâce au ruban, les programmeurs peuvent utiliser l'équilibrage de charge "transparente" sans impliquer des détails d'implémentation spécifiques, sans avoir à écrire trop de code pour implémenter l'équilibrage de charge dans des projets.
Par exemple, dans un cluster contenant Eureka et Ribbon, un service (qui peut être compris comme un package JAR) est déployé sur plusieurs serveurs. Lorsque plusieurs utilisateurs de services appellent le service en même temps, ces demandes simultanées peuvent être transmises à chaque serveur en utilisant une stratégie raisonnable.
En fait, lorsque vous utilisez divers autres composants de Spring Cloud, nous pouvons voir des traces de ruban, tels que Eureka peut être intégré au ruban, et le composant Zuul qui fournit la fonction de passerelle peut également être intégré au ruban lors des demandes de transfert.
Du niveau de code, le ruban a les trois interfaces les plus importantes suivantes.
Tout d'abord, l'iloadbalancer, qui est également appelé équilibreur de charge. Grâce à cela, nous pouvons raisonnablement transmettre les demandes dans le projet en fonction de règles spécifiques. La classe de mise en œuvre commune est Basoadbalancer.
Deuxièmement, Irule, cette interface a plusieurs classes d'implémentation, telles que RandomRule et RoundRobinrule. Ces classes de mise en œuvre définissent spécifiquement des stratégies d'équilibrage de charge telles que «aléatoire» et «sondage», etc. Nous pouvons également réécrire les méthodes de cette interface pour personnaliser les stratégies d'équilibrage de charge.
Dans la classe BasEloadBalancer, nous pouvons configurer des politiques d'équilibrage de charge via la classe d'implémentation d'Irule, afin que l'équilibreur de charge puisse raisonnablement transmettre des demandes en fonction de cela.
Troisièmement, l'interface IPING, via cette interface, nous pouvons obtenir quels serveurs sont actuellement disponibles, et nous pouvons également personnaliser les règles pour déterminer si le serveur est disponible en réécrivant les méthodes de cette interface. Dans la classe BasEloadBalancer, nous pouvons également définir des politiques pour déterminer si le serveur est disponible via la classe d'implémentation IPING.
1 Iloadbalancer: Interface LoadBalancer
Dans Ribbon, nous pouvons également sélectionner des serveurs en fonction de politiques d'équilibrage de charge spécifiques via l'interface iloadbalancer.
Grâce à l'iloadbalancerdemo.java ci-dessous, jetons un coup d'œil à l'utilisation de base de cette interface. Cette classe est placée dans le projet RabbionBasicDemo créé dans la partie 4.2, et le code est le suivant.
// omettez le package et le code d'importation nécessaires classe publique IloadbalancerDemo {public static void main (String [] args) {// Créer l'objet iloadbalancer iloadbalancer loadBalancer = new BasEloadbalancer (); // Définir une liste de serveurs <server> MyServers = new ArrayList <Server> (); // Créer deux objets de serveur Server S1 = nouveau serveur ("Ekserver1", 8080); Server S2 = nouveau serveur ("Ekserver2", 8080); // Mettez deux objets de serveur dans la liste Type MyServers MyServers.Add (S1); MyServers.Add (S2); // Mettez MyServers dans l'équilibreur de charge chargeurBalancer.AddServers (MyServers); // initier 10 appels dans la boucle pour (int i = 0; i <10; i ++) {// Utilisez des règles d'équilibrage de charge par défaut pour obtenir le serveur d'objets de type serveur S = LoadBalancer.ChooseServer ("Default"); // Sortie d'adresse IP et de numéro de port System.out.println (s.Gethost () + ":" + s.getport ()); }}}Dans la ligne 5, nous créons un objet LoadBalancer de Type Basoadbalancer, et Baseloadbalancer est la classe de mise en œuvre de l'interface de l'équilibreur de chargement iloadbalancer.
Dans les lignes 6 à 13, nous créons deux objets de type serveur et les mettons dans MyServers. Dans la ligne 15, nous mettons l'objet MyServers de type liste dans l'équilibreur de charge.
Dans la boucle pour les lignes 17 à 22, nous avons simulé la sélection du serveur 10 fois via l'équilibreur de charge. Plus précisément, dans la ligne 19, nous sélectionnons le serveur avec les règles d'équilibrage de charge par défaut via la méthode ChoiceServer de LoadBalancer. Dans la ligne 21, nous utilisons l'action "Imprimer" pour simuler l'action réelle "Utilisation de l'objet serveur pour gérer les demandes".
Les résultats en cours d'exécution du code ci-dessus sont les suivants. Nous pouvons voir que l'équilibreur de charge LoadBalancer distribue 10 demandes à 2 serveurs, et nous pouvons en effet voir l'effet de "l'équilibrage de charge".
Deuxièmement, Irule, cette interface a plusieurs classes d'implémentation, telles que RandomRule et RoundRobinrule. Ces classes de mise en œuvre définissent spécifiquement des stratégies d'équilibrage de charge telles que «aléatoire» et «sondage», etc. Nous pouvons également réécrire les méthodes de cette interface pour personnaliser les stratégies d'équilibrage de charge.
Dans la classe BasEloadBalancer, nous pouvons configurer des politiques d'équilibrage de charge via la classe d'implémentation d'Irule, afin que l'équilibreur de charge puisse raisonnablement transmettre des demandes en fonction de cela.
Troisièmement, l'interface IPING, via cette interface, nous pouvons obtenir quels serveurs sont actuellement disponibles, et nous pouvons également personnaliser les règles pour déterminer si le serveur est disponible en réécrivant les méthodes de cette interface. Dans la classe BasEloadBalancer, nous pouvons également définir des politiques pour déterminer si le serveur est disponible via la classe d'implémentation 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: Interface qui définit les règles d'équilibrage de charge
Dans Ribbon, nous pouvons définir des règles correspondantes pour l'équilibreur de charge en définissant la classe d'implémentation de l'interface Irule. Dans le tableau suivant, nous pouvons voir certaines classes d'implémentation couramment utilisées de l'interface Irule.
Le nom de la classe d'implémentation | Règles d'équilibrage des charges |
Aléatoire | Adopter une stratégie sélectionnée au hasard |
Roundrobinrule | Adopter une stratégie de sondage |
Retryrule | Lorsque vous utilisez cette stratégie, une action de réessayer est incluse |
DisponibilitéFilterrule | Il filtrera les serveurs avec plusieurs défaillances de connexion et une concurrence excessive |
Pondération | Définissez un poids pour chaque serveur en fonction du temps de réponse moyen et sélectionnez des serveurs avec un temps de réponse moyen plus petit en fonction de cette valeur de poids. |
Zoneavoidancerule | La priorité est donnée pour allouer la demande aux serveurs avec la même zone que la demande |
Dans le programme IRULEDEMO.JAVA suivant, jetons un coup d'œil à l'utilisation de base d'Irule.
// omettez le package et le code d'importation nécessaires classe publique IruleDemo {public static void main (String [] args) {// Veuillez noter que cela est utilisé pour Baseloadbalancer, pas Iloadbalancer Interface BasEloadBaler LoadBalancer = New BasEloadbalancer (); // Déclarer la politique d'équilibrage de la charge basée sur le sondage IRULE Rule = New RoundRobinrule (); // Définir la politique LoadBalancer.Setrule (règle); // Définissez 3 serveurs comme suit et placez-les dans une collection de listes de types de liste <Server> MyServers = new ArrayList <Sternver> (); Server S1 = nouveau serveur ("Ekserver1", 8080); Server S2 = nouveau serveur ("Ekserver2", 8080); Serveur S3 = nouveau serveur ("ekserver3", 8080); MyServers.Add (S1); MyServers.Add (S2); MyServers.Add (S3); // Définissez la liste du serveur LOCALBALANCER.ADDSERVERS (MyServers); // Sortie du résultat d'un équilibrage de charge pour (int i = 0; i <10; i ++) {server s = charlebalancer.chooseServer (null); System.out.println (s.Gethost () + ":" + s.getport ()); }}}Ce code est très similaire à l'iloadbalancerdemo.java dans l'article ci-dessus, mais il existe les différences suivantes.
1 Dans la ligne 5, nous définissons l'équilibreur de charge à travers la classe Basoadbalancer au lieu de l'interface car la classe contient la méthode SetRule.
2 Définissez un objet de règle en fonction de la règle de sondage à la ligne 7 et définissez-le dans l'équilibreur de charge à la ligne 9.
3 Dans la ligne 19, nous mettons l'objet de liste contenant 3 serveurs dans l'équilibreur de charge, au lieu des deux précédents. Puisqu'il est stocké ici à des fins de démonstration, nous allons installer un serveur "Ekserver3" qui n'existe pas du tout.
Après avoir exécuté le programme, nous pouvons voir qu'il y a 10 sorties, et elle étend en effet les noms de 3 serveurs en séquence selon la règle "d'interrogation". Si nous modifions le code sur la ligne 7 vers les éléments suivants, nous verrons la sortie "au hasard" au nom du serveur.
IRULE Rule = new RandomRule ();
3 Iping: l'interface pour déterminer si le serveur est disponible
Dans le projet, nous laissons généralement l'interface d'iloadbalancer déterminer automatiquement si le serveur est disponible (ces services sont encapsulés dans le code sous-jacent du ruban). De plus, nous pouvons également utiliser l'interface Iping dans le composant du ruban pour implémenter cette fonction.
Dans le code iRuleDemo.java suivant, nous démontrerons l'utilisation générale de l'interface IPING.
// omettre le package et l'importation de classe de code nécessaire Myping implémente iping {public boolean isalive (server server) {// Si le nom du serveur est ekserver2, return false if (server.Gethost (). Equals ("ekserver2")) {return false; } return true; }}La classe Myping définie à la ligne 2 implémente l'interface IPING et remplace la méthode Isalive dans la ligne 3.
Dans cette méthode, nous jugeons en fonction du nom du serveur. Plus précisément, si le nom est Ekserver2, il renvoie False, ce qui signifie que le serveur n'est pas disponible, sinon il renvoie True, ce qui signifie que le serveur actuel est disponible.
classe publique iRuleDemo {public static void main (String [] args) {Baseloadbalancer LoadBalancer = new BasEloadbalancer (); // Définissez l'objet Myping de iping type iping myping = new myping (); // Utilisez l'objet Myping LoadBalancer.Setping (Myping); // Créez trois objets de serveur et placez-les dans la liste d'équilibrage de charge <ver> MyServers = new ArrayList <Sistry> (); Server S1 = nouveau serveur ("Ekserver1", 8080); Server S2 = nouveau serveur ("Ekserver2", 8080); Serveur S3 = nouveau serveur ("ekserver3", 8080); MyServers.Add (S1); MyServers.Add (S2); MyServers.Add (S3); loadbalancer.addservers (MyServers); // demande le serveur plusieurs fois via une boucle pour (int i = 0; i <10; i ++) {server s = loadBalancer.ChooseServer (null); System.out.println (s.Gethost () + ":" + s.getport ()); }}}Dans la fonction principale à la ligne 12, nous créons un objet de type iping mon objet à la ligne 15, et mettons cet objet dans l'équilibreur de charge à la ligne 17. À travers le code des lignes 18 à 26, nous créons trois serveurs et les mettons également dans l'équilibreur de charge.
Dans la boucle pour la ligne 28, nous demandons et publions toujours le nom du serveur. Étant donné que l'équilibreur de charge contient ici un objet de type Iping, après avoir obtenu le serveur en fonction de la stratégie, il déterminera si le serveur est disponible en fonction de la méthode ISACTIVE dans Myping.
Étant donné que dans cette méthode, nous définissons que le serveur Ekserver2 n'est pas disponible, l'objet Balancer LoadBalancer n'enverra jamais la demande au serveur, c'est-à-dire dans le résultat de sortie, nous ne verrons pas la sortie de "Ekserver2: 8080".
À partir de cela, nous pouvons voir l'utilisation générale de l'interface Iping. Nous pouvons définir la logique de "juger si le serveur est disponible" en réécrivant la méthode Isalive. Dans les projets réels, la base du jugement n'est rien de plus que "si le serveur répond trop longtemps" ou "si le nombre de demandes envoyées au serveur est trop nombreux". Ces méthodes de jugement sont encapsulées dans l'interface Irule et sa classe d'implémentation, donc dans les scénarios généraux, nous utilisons l'interface IPING.
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.