A fita é um componente responsável pelo equilíbrio de carga nos baldes da família Spring Cloud Netflix. É uma coleção de bibliotecas de classes. Através da fita, os programadores podem usar o balanceamento de carga "transparentemente" sem envolver detalhes específicos da implementação, sem precisar escrever muito código para implementar o balanceamento de carga em projetos.
Por exemplo, em um cluster contendo Eureka e Ribbon, um serviço (que pode ser entendido como um pacote JAR) é implantado em vários servidores. Quando vários usuários de serviço chamam o serviço ao mesmo tempo, essas solicitações simultâneas podem ser encaminhadas para cada servidor usando uma estratégia razoável.
De fato, ao usar vários outros componentes do Spring Cloud, podemos ver traços de fita, como Eureka, podem ser integrados à fita, e o componente Zuul que fornece a função de gateway também pode ser integrado à fita ao encaminhar solicitações.
No nível do código, a fita possui as três interfaces mais importantes a seguir.
Primeiro, o iloadbalancer, que também é chamado de balanceador de carga. Por meio disso, podemos razoavelmente encaminhar solicitações no projeto de acordo com regras específicas. A classe de implementação comum é BaseloadBalancer.
Segundo, Irule, essa interface possui várias classes de implementação, como randomrule e redond -robina. Essas classes de implementação definem especificamente estratégias de balanceamento de carga, como "aleatório" e "pesquisa", etc. Também podemos reescrever os métodos nessa interface para personalizar estratégias de balanceamento de carga.
Na classe BaseloadBalancer, podemos configurar políticas de balanceamento de carga através da classe de implementação do IRULE, para que o balanceador de carga possa razoavelmente encaminhar solicitações com base nisso.
Terceiro, a interface iping, através dessa interface, podemos obter quais servidores estão disponíveis no momento e também podemos personalizar as regras para determinar se o servidor está disponível reescrevendo os métodos nessa interface. Na classe BaseloadBalancer, também podemos definir políticas para determinar se o servidor está disponível através da classe de implementação IPPing.
1 iloadbalancer: interface LoadBalancer
Na faixa de opções, também podemos selecionar servidores com base em políticas específicas de balanceamento de carga através da interface iloadbalancer.
Através do iloadBalancerdemo.java abaixo, vamos dar uma olhada no uso básico dessa interface. Esta classe é colocada no projeto RabbionBasicDemo criado na Parte 4.2, e o código é o seguinte.
// omitir o pacote necessário e o código de importação public classe iloadBalancerdemo {public static void main (string [] args) {// Crie o objeto iloadBalancer iloadBalancer loadBalancer = new BaseloadBalancer (); // Defina uma lista de servidores <Server> myServers = new ArrayList <Verver> (); // Crie dois objetos servidores servidores S1 = novo servidor ("ekserver1", 8080); Servidor s2 = novo servidor ("ekserver2", 8080); // Coloque dois objetos do servidor no tipo de lista do MyServers objeto myServers.add (S1); myServers.add (S2); // coloca o MyServers no balanceador de carga loadbalancer.addsservers (myservers); // inicia 10 chamadas no loop for (int i = 0; i <10; i ++) {// Use regras de balanceamento de carga padrão para obter o servidor servidor servidor de objeto s = loadBalancer.chooseserver ("default"); // saída de endereço IP e número da porta System.out.println (s.gethost () + ":" + s.getport ()); }}}Na linha 5, criamos um objeto LoadBalancer do tipo BaseloadBalancer, e BaseloadBalancer é a classe de implementação da interface iloadbalancer de balanceador de carga.
Nas linhas 6 a 13, criamos dois objetos do tipo servidor e os colocamos em myservers. Na linha 15, colocamos o objeto MyServers do tipo lista no balanceador de carga.
No loop for nas linhas 17 a 22, simulamos a seleção do servidor 10 vezes através do balanceador de carga. Especificamente, na linha 19, selecionamos o servidor com as regras de balanceamento de carga padrão através do método do ChoiceServer do LoadBalancer. Na linha 21, usamos a ação de "impressão" para simular a ação real "usando o objeto do servidor para lidar com as solicitações".
Os resultados em execução do código acima são os seguintes. Podemos ver que o balanceador de carga do LoadBalancer distribui 10 solicitações para 2 servidores, e podemos realmente ver o efeito do "balanceamento de carga".
Segundo, Irule, essa interface possui várias classes de implementação, como randomrule e redond -robina. Essas classes de implementação definem especificamente estratégias de balanceamento de carga, como "aleatório" e "pesquisa", etc. Também podemos reescrever os métodos nessa interface para personalizar estratégias de balanceamento de carga.
Na classe BaseloadBalancer, podemos configurar políticas de balanceamento de carga através da classe de implementação do IRULE, para que o balanceador de carga possa razoavelmente encaminhar solicitações com base nisso.
Terceiro, a interface iping, através dessa interface, podemos obter quais servidores estão disponíveis no momento e também podemos personalizar as regras para determinar se o servidor está disponível reescrevendo os métodos nessa interface. Na classe BaseloadBalancer, também podemos definir políticas para determinar se o servidor está disponível através da classe de implementação IPPing.
EkServer2: 8080 EkServer1: 8080 EkServer2: 8080 EkServer1: 8080 Ekserver2: 8080 Ekserver1: 8080 ekserver2: 8080 ekserver1: 8080 ekserver2: 8080 Eks.
2 Irule: interface que define regras de balanceamento de carga
Na fita, podemos definir regras correspondentes para o balanceador de carga, definindo a classe de implementação da interface irule. Na tabela a seguir, podemos ver algumas classes de implementação comumente usadas da interface IRULE.
O nome da classe de implementação | Regras de balanceamento de carga |
Randomrule | Adote uma estratégia selecionada aleatoriamente |
RoundRobinRule | Adote uma estratégia de votação |
Repretílula | Ao usar esta estratégia, uma ação de tentativa é incluída |
Disponibilidade FilterRule | Ele filtrará servidores com múltiplas falhas de conexão e concorrência excessiva de solicitação |
PondedResponsetimerule | Defina um peso para cada servidor de acordo com o tempo médio de resposta e selecione servidores com menor tempo de resposta média com base nesse valor de peso. |
ZoneAvoidanceRule | É dada prioridade para alocar a solicitação aos servidores com a mesma zona que a solicitação |
No seguinte programa IRULEDEMO.JAVA, vamos dar uma olhada no uso básico do IRULE.
// omitir o pacote necessário e importar o código público Iruledemo {public static void main (string [] args) {// Observe que isso é usado para Baseloadbalancer, não a interface iloadbalancer BaseloadBalancer loadBalancer = novo BaseloadBalancer (); // Declare a política de balanceamento de carga com base na regra da Polling Irule = new RoundRobinRule (); // defina o policy loadBalancer.SetRule (regra); // Defina 3 servidores da seguinte maneira e os coloque em uma coleção de listas de tipos de listas <Verver> myServers = new ArrayList <Verver> (); Servidor s1 = novo servidor ("ekserver1", 8080); Servidor s2 = novo servidor ("ekserver2", 8080); Servidor s3 = novo servidor ("ekserver3", 8080); myServers.add (S1); myServers.add (S2); myServers.add (S3); // defina a lista do servidor loadBalancer.addServers (myServers); // emitir o resultado do balanceamento de carga para (int i = 0; i <10; i ++) {servidor s = loadBalancer.ChooseServer (nulo); System.out.println (s.gethost () + ":" + s.getport ()); }}}Este código é muito semelhante ao iloadbalancerdemo.java no artigo acima, mas existem as seguintes diferenças.
1 Na linha 5, definimos o balanceador de carga através da classe BaseloadBalancer em vez da interface porque a classe contém o método setRule.
2 Defina um objeto de regra com base na regra de votação na linha 7 e coloque -o no balanceador de carga na linha 9.
3 Na linha 19, colocamos o objeto da lista contendo 3 servidores no balanceador de carga, em vez dos dois anteriores. Como é armazenado aqui para fins de demonstração, colocaremos um servidor "Ekserver3" que não existe.
Após a execução do programa, podemos ver que existem 10 saídas e, de fato, está emitindo os nomes de 3 servidores em sequência de acordo com a regra de "pesquisa". Se alterarmos o código na linha 7 para o seguinte, veremos o nome do servidor "aleatoriamente".
Regra irule = new randomRule ();
3 Iping: a interface para determinar se o servidor está disponível
No projeto, geralmente deixamos a interface do IloadBalancer determinar automaticamente se o servidor está disponível (esses serviços são encapsulados no código subjacente da Ribbon). Além disso, também podemos usar a interface iping no componente da faixa de opções para implementar esta função.
No código IRULEDEMO.JAVA a seguir, demonstraremos o uso geral da interface IPing.
// omitir o pacote e a classe de importação necessários implementos myping iping {public boolean isalive (servidor servidor) {// se o nome do servidor for ekserver2, retorne false if (server.gethost (). Equals ("ekserver2")) {return false; } retornar true; }}A classe Myping definida na linha 2 implementa a interface iping e substitui o método isalivo na linha 3.
Neste método, julgamos com base no nome do servidor. Especificamente, se o nome for ekserver2, ele retorna false, o que significa que o servidor não está disponível, caso contrário, retorna true, o que significa que o servidor atual está disponível.
classe pública IRULEDEMO {public static void main (string [] args) {BaseloadBalancer loadBalancer = new BaseloadBalancer (); // Defina o objeto Myping de Ipping tipo iping myping = new Myping (); // Use o objeto Myping loadBalancer.setping (myping); // Crie três objetos do servidor e os coloque na lista de balanceres de carga <Verver> myServers = new ArrayList <Verver> (); Servidor s1 = novo servidor ("ekserver1", 8080); Servidor s2 = novo servidor ("ekserver2", 8080); Servidor s3 = novo servidor ("ekserver3", 8080); myServers.add (S1); myServers.add (S2); myServers.add (S3); loadBalancer.AddServers (MyServers); // Solicite o servidor várias vezes através de um loop for (int i = 0; i <10; i ++) {servidor s = loadBalancer.Chooseserver (null); System.out.println (s.gethost () + ":" + s.getport ()); }}}Na função principal da linha 12, criamos um objeto Myping de tipo IPing na linha 15 e colocamos esse objeto no balanceador de carga na linha 17. Através do código nas linhas de 18 a 26, criamos três servidores e os colocamos no balanceador de carga também.
No loop for loop 28, ainda solicitamos e produzimos o nome do servidor. Como o balanceador de carga aqui contém um objeto de tipo iping, depois de obter o servidor de acordo com a política, ele determinará se o servidor está disponível com base no método ISactive em Myping.
Como neste método, definimos que o servidor EkServer2 não está disponível, o objeto de carga do Balancer Load LouadBalancer nunca enviará a solicitação ao servidor, ou seja, no resultado da saída, não veremos a saída de "Ekserver2: 8080".
A partir disso, podemos ver o uso geral da interface iping. Podemos definir a lógica de "julgar se o servidor está disponível" reescrevendo o método isalivo. Em projetos reais, a base para julgamento nada mais é do que "se o servidor responde por muito tempo" ou "se o número de solicitações enviadas ao servidor é muitas". Esses métodos de julgamento são encapsulados na interface do irule e em sua classe de implementação; portanto, em cenários gerais, usamos a interface IPing.
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.