Artigo Diretório
No aprendizado diário, aprendemos apenas a usar o Apache Dubbo como uma estrutura de comunicação RPC, bem como a aplicação e os princípios do registro de serviços.Isso é apenas a ponta do iceberg. Na verdade, o Apache Dubbo é mais como um ecossistema. Ele fornece integração de muitos frameworks convencionais, como:
1. Suporta publicação de serviço de vários protocolos. O padrão é dubbo: /, e também pode oferecer suporte a rest: //, webservice: //, thrift: //, etc. · Apoiar uma variedade de centros de registro diferentes, como Nacos, ZooKeeper, Redis, e no futuro também apoiará Consul, Eureka, Etcd, etc.
2. Suporta várias tecnologias de serialização, como avro, fst, fastjson, hessian2, kryo, etc.
Além disso, o Apache Dubbo tem funções muito completas em governança de serviço, como tolerância a falhas de cluster, roteamento de serviço, balanceamento de carga, degradação de serviço, limitação de corrente de serviço, monitoramento de serviço e verificação de segurança.
(1) Tolerância a falhas de cluster
Na comunicação de rede distribuída, a tolerância a falhas é fundamental. O que é tolerância a falhas? Literalmente, é a capacidade do serviço de tolerar erros. Todos nós sabemos que haverá muitos fatores incertos na comunicação da rede que farão com que a solicitação falhe, como atrasos na rede, interrupções na rede e exceções de serviço. Quando o chamador do serviço (consumidor) chama a interface do provedor de serviço, se a solicitação falhar devido aos motivos acima mencionados, um mecanismo é necessário para o chamador do serviço lidar com isso. Dubbo fornece um mecanismo tolerante a falhas de cluster para lidar com esses erros normalmente.
(1) Modo tolerante a falhas O
Dubbo fornece 6 modos tolerantes a falhas por padrão, e o padrão é Cluster de Failover. Se esses 6 modos tolerantes a falhas não atenderem às suas necessidades reais, você também pode expandir por conta própria. Este também é o poder do Dubbo.Quase todas as funções fornecem extensões de plug-in.
[Cluster de Failover]: Troca automaticamente após a falha. Quando a chamada de serviço falha, ela muda para outras máquinas no cluster para tentar novamente. O número padrão de tentativas é 2, e o número de vezes pode ser modificado por meio do atributo retries = 2, mas um aumento no número de tentativas será causar um atraso de resposta mais longo. Esse modo tolerante a falhas geralmente é usado para operações de leitura, porque as operações transacionais causarão problemas de duplicação de dados.
[Failfast Cluster]: Falha rápida. Quando a chamada de serviço falha, um erro é relatado imediatamente, ou seja, apenas uma chamada é iniciada. Normalmente usado para algumas operações de gravação idempotentes, como adicionar novos dados, porque quando a chamada de serviço falha, é provável que a solicitação tenha sido processada com sucesso no lado do servidor, mas a resposta falhou devido a atrasos na rede, a fim de evitar o situação em que o resultado é incerto Este mecanismo tolerante a falhas pode ser usado para causar o problema de inserção repetida de dados.
[Cluster Failsafe]: À prova de falhas. Ou seja, quando ocorre uma exceção, a exceção é diretamente ignorada.
[Failback Cluster]: Responder automaticamente após a falha. Quando ocorre uma exceção na chamada de serviço, a solicitação com falha é registrada em segundo plano e retransmitida regularmente. Este modo é adequado para operações de notificação de mensagem para garantir que a solicitação seja enviada com sucesso.
[Cluster de bifurcação]: Chame vários serviços no cluster em paralelo e retorne contanto que um deles seja bem-sucedido. O número máximo de paralelos pode ser definido por garfos = 2.
[Cluster de transmissão]: Chamadas de transmissão para todos os provedores de serviço e qualquer erro de serviço indica que a chamada de serviço falhou. Esse mecanismo geralmente é usado para notificar todos os provedores de serviço para atualizar o cache ou as informações de recursos locais.
Método de
configuração O método de configuração é muito simples, basta adicionar um parâmetro à anotação @Service do serviço especificado. Observe que, a menos que especificado de outra forma, o código subsequente é baseado no código Dubbo Spring Cloud anterior. Adicionar o
parâmetro cluster = "failfast" à anotação @Service indica que o modo de tolerância a falhas do serviço atual é falha rápida.
Em aplicações práticas, a estratégia de tolerância a falhas da instrução de consulta recomenda o uso do cluster de failover padrão, e é recomendado adicionar, excluir e modificar operações para usar o cluster de failfast ou usar a estratégia de cluster de failover (tentativas = "O") para evitar a duplicação de dados e outros problemas ! Recomenda-se projetar a interface quando o método de interface de consulta for transformado em uma interface separada para fornecer consulta.
(2) Balanceamento de carga
O balanceamento de carga não deve ser um conceito estranho, no caso de um grande número de visitas, vamos aumentar o número de nós por meio de expansão horizontal para equilibrar o fluxo de solicitações, melhorando assim o desempenho geral do serviço. Simplificando, se o TPS de um nó de serviço for 100, então se for aumentado para um cluster de 5 nós, isso significa que o TPS de todo o cluster pode chegar a 500.
Quando um chamador de serviço se depara com um cluster de provedor de serviço composto por 5 nós, a solicitação deve ser distribuída para qual nó do cluster depende do algoritmo de balanceamento de carga, através do qual cada nó do servidor pode obter uma carga adequada para sua capacidade de processamento. O balanceamento de carga pode ser dividido em balanceamento de carga de hardware e balanceamento de carga de software.O balanceamento de carga de hardware mais comum é F5, e o balanceamento de carga de software principal atual é Nginx.
Existem 4 estratégias de balanceamento de carga fornecidas no Dubbo, e a estratégia de balanceamento de carga padrão é aleatória. Da mesma forma, se essas quatro estratégias não podem atender às necessidades reais, podemos estendê-las com base no mecanismo SPI em Dubbo.
[Random LoadBalance]: Algoritmo aleatório. Você pode definir um valor de peso maior para servidores com melhor desempenho. Quanto maior o valor de peso, maior a probabilidade de aleatoriedade.
[RoundRobin LoadBalance]: Sondagem. Defina a taxa de votação de acordo com o peso após a convenção.
[LeastActive LoadBalance]: O equilíbrio de carga menos ativo. Os nós com processamento mais lento receberão menos solicitações.
[ConsistentHash LoadBalance]: Hash consistente. As solicitações com os mesmos parâmetros são sempre enviadas ao mesmo provedor de serviços.
Método de configuração
Adicione o parâmetro loadbalance à anotação @Service:
@Service (cluster = "failfast", loadbalance = "roundrobin")
(3) Degradação do serviço
A degradação do serviço é uma estratégia de proteção do sistema.Quando a pressão de acesso ao servidor é alta, os serviços sem importância podem ser rebaixados de acordo com as condições comerciais atuais para garantir a operação normal dos serviços principais. O chamado downgrade é o desligamento temporário de algumas funções não essenciais durante períodos de alto tráfego. Por exemplo, durante a promoção Double 11, o Taobao encerrará funções como visualização de pedidos históricos e análises de produtos, liberando assim mais recursos para proteção. A maioria dos usuários pode concluir transações normalmente.
[Existem vários níveis de classificação de downgrade]:
1. Conforme seja automatizado ou não, pode ser dividido em downgrade automático e downgrade manual.
2. De acordo com a função, pode ser dividido em downgrade do serviço de leitura e downgrade do serviço de gravação.
O downgrade manual geralmente tem certos predecessores, como encerrar temporariamente certos serviços não essenciais, como avaliação e recomendação, antes da grande promoção de comércio eletrônico. E o rebaixamento automático vem mais do acionamento automático de "suavidade no fundo" quando ocorrem certas anormalidades no sistema, tais como:
[Degradação por falha]: O serviço remoto chamado "trava", a rede falha ou o serviço RPC retorna de forma anormal. Nesse caso, se o negócio permitir, você pode responder ao cliente definindo os dados do fundo.
[Downgrade do limite de corrente]: Não importa o tipo de sistema, o tráfego que ele suporta é limitado. Para proteger o sistema contra sobrecarga, o sistema limitará a corrente para o negócio principal. Quando o tráfego de solicitações atinge o limite, as solicitações subsequentes são interceptadas e podem entrar no sistema de enfileiramento, como 12306. Você também pode retornar diretamente para a página de downgrade, como retornar à página "Atividade muito quente, volte mais tarde".
Dubbo fornece uma configuração Mock para atingir a degradação do serviço, o que significa que quando o provedor de serviço falha em acessar a rede de forma anormal, o cliente não lança uma exceção, mas retorna os dados inferiores por meio da configuração degradada. As etapas de operação são as seguintes:
Crie a classe MockHelloService no projeto spring-cloud-dubbo-consumer. Esta classe só precisa implementar a interface degradada automaticamente e, em seguida, reescrever o método abstrato na interface para retornar os dados locais.
(4) Regras de vinculação do host
Vinculação do host significa o endereço IP publicado pelo serviço Dubbo. Por padrão, o Dubbo encontrará e vinculará o endereço IP do host na seguinte ordem:
1. Encontre o endereço IP configurado pelo atributo DUBBO_IP_TO_BIND na variável de ambiente.
2. Encontre o endereço IP configurado na propriedade dubbo.protocol.host.O padrão é vazio.Se não houver configuração ou o endereço IP for ilegal, continue a pesquisa.
3. Obtenha o endereço IP local através de LocalHost.getHostAddress. Se a aquisição falhar, continue a pesquisar.
4. Se o endereço do registro estiver configurado, use a comunicação Socket para conectar ao endereço do registro e use um loop for para passar socket.getLocalAddress () .getHostAddress () Faça a varredura de cada placa de rede para obter o endereço IP da placa de rede.
No processo acima, se um endereço IP legal for detectado em qualquer etapa, ele será retornado como o endereço IP de serviço exposto. Deve-se observar que o endereço IP obtido não é o endereço gravado no registro.Por padrão, o endereço IP gravado no registro é preferível ao endereço IP configurado na variável de ambiente DUBBO_IP_TO_REGISTRY. Quando este atributo não é configurado, o endereço IP obtido anteriormente será selecionado e gravado no registro.
Usando as regras de ligação de host padrão, pode haver casos em que o endereço IP obtido está incorreto, fazendo com que os consumidores de serviço se comuniquem com o endereço URL obtido no registro. Como a estratégia do Dubbo para detectar o endereço IP local é chamar LocalHost.getHostAddress primeiro, o princípio desse método é mapear o endereço IP obtendo o nome do host da máquina. Se ele apontar para um endereço IP errado, o endereço errado servir como um serviço O endereço publicado é registrado no nó ZooKeeper. Embora o serviço Dubbo possa ser iniciado normalmente, o consumidor do serviço não pode chamá-lo normalmente. De acordo com as regras de pesquisa de endereço IP no Dubbo, se você se deparar com essa situação, pode usar várias maneiras de resolvê-la:
1. Configure o nome da máquina correspondente ao mapeamento de endereço IP correto em / etc / hosts.
2. Adicione o atributo DUBBO_IP_TO_BIND ou DUBBO_IP_TO_REGISTRY à variável de ambiente e o valor Value é o endereço do host vinculado.
3. Defina o endereço do host por meio de dubbo.protocol.host.
Além de obter o endereço IP do host de ligação, a porta pública também precisa de atenção.O framework Dubbo fornece números de porta padrão para diferentes protocolos:
4. O número da porta padrão do protocolo Dubbo é 20880. O número da porta padrão do protocolo Webservice é 80.
No uso real, é recomendado especificar um número de porta para evitar conflitos com outras portas de serviço Dubbo.