1. Fundo
A arquitetura do algoritmo de pesquisa e recomendação fornece serviços para todos os negócios de pesquisa e recomendação do JD.com e retorna os resultados do processamento ao upstream em tempo real. Cada subsistema do departamento implementou limitação de corrente adaptável baseada em CPU, mas a chamada do cliente para o servidor ainda é RR polling, que não considera as diferenças de desempenho das máquinas downstream e não pode maximizar o uso da CPU geral do cluster Fim do problema de desequilíbrio da CPU.
O método de balanceamento de carga desenvolvido pelo departamento de publicidade da JD para seus cenários de negócios é uma grande referência. O algoritmo RALB (Remote Aware Load Balance) que eles propuseram pode melhorar a eficiência de recursos da CPU de máquinas de cluster de serviço downstream, evitar efeitos de shortboard da CPU e permitir máquinas com bom desempenho para lidar com mais tráfego. Aplicamos suas ideias centrais ao nosso sistema e obtivemos bons resultados.
A estrutura deste artigo é a seguinte:
1. Introdução ao RALB
◦ O princípio do algoritmo é brevemente introduzido.
2. Verificação funcional
◦Aplique a tecnologia de balanceamento de carga RALB ao sistema de arquitetura de recomendação de pesquisa para verificação funcional.
3. Teste de rendimento
◦ Comparar principalmente as tecnologias de balanceamento de carga RALB e RR. Verificou-se que não há diferença significativa no throughput entre os clusters sem limite de corrente e com limite de corrente total. No caso da limitação de corrente parcial RR, há uma diferença no rendimento entre os dois, e existe um ponto de máxima diferença no rendimento. Para RALB, é um ponto de virada do limite de fluxo ilimitado para o limite de fluxo total no lado do servidor, e quase não há caso de limite de fluxo parcial.
4. Teste de limite
◦Ao simular várias condições de contorno, o sistema foi testado para verificar a estabilidade e confiabilidade do RALB.
5. Função iniciada
◦ O modo de balanceamento de carga RALB está totalmente ativado em todos os clusters do lado do servidor. Pode-se observar que, antes e depois do lançamento, o QPS no lado do servidor torna-se gradativamente estratificado, e a CPU no lado do servidor tende gradualmente a ser unificada.
2. Introdução ao RALB
O RALB é um algoritmo de balanceamento de carga de alto desempenho direcionado ao balanceamento de CPU.
2.1 Objetivos do algoritmo
1. Ajuste o uso da CPU no lado do servidor, para que as CPUs de cada nó sejam relativamente equilibradas e evite a limitação de corrente do cluster acionada pelo uso excessivo da CPU
2. O QPS tem uma relação linear com o uso da CPU, e ajustar o QPS pode atingir a meta de uso equilibrado da CPU
2.2 Princípio do algoritmo
2.2.1 Etapas do algoritmo
1. Ao alocar o tráfego, distribua de acordo com o peso (algoritmo aleatório com peso, wr)
2. Colete o uso da CPU: o servidor retorna o uso da CPU (média de 1s) para o cliente por meio do RPC
3. Ajuste de peso: ajuste o peso regularmente (a cada 3s) de acordo com o uso da CPU (valor médio na janela) do cluster e de cada nó para equilibrar a CPU de cada nó
2.2.2 Dependência do índice
| número de série | índice | efeito | fonte |
|---|---|---|---|
| 1 | IP | Lista de IPs disponíveis | Descoberta de registro de serviço e módulos de mascaramento de falhas para manutenção |
| 2 | saúde em tempo real | O status de disponibilidade de IP muda em tempo real, fornecendo as condições de limite do algoritmo | Manutenção da função de verificação de integridade da estrutura RPC |
| 3 | Histórico de saúde | Valor do histórico de integridade, usado para avaliar as condições de limite, como falha e recuperação de ip | Valor histórico do indicador 2 |
| 4 | Alvo dinâmico (uso da CPU) | Forneça a base de destino mais direta para o algoritmo de equalização | Estatísticas de tempo do lado do servidor, estrutura RPC retorna por meio de RPC |
| 5 | peso | Distribuição de carga em tempo real baseada em | atualização do algoritmo |
2.2.3 Algoritmo de ajuste de peso
2.2.4 Processamento de limites
Limite 1: Dentro da janela de feedback (3s), se o IP downstream não for acessado, seu valor médio de CPU é 0, e o algoritmo de ajuste de peso considerará o nó com excelente desempenho, aumentando assim o peso
Limite 2: Quando a rede falha, a estrutura RPC define o nó com falha como indisponível e a CPU e o peso são 0; depois que a rede é restaurada, a estrutura RPC define o IP como disponível, mas o nó com peso 0 não pode compartilhar o tráfego, resultando no nó permanecerá indisponível
Processamento: A atualização do peso é acionada por um cronômetro e o status disponível do nó é registrado. Quando o nó se recupera de indisponível para disponível, um peso baixo é dado para recuperar gradualmente
2.3 A chave para o pouso
Seja rápido e estável, evite impasses e avalanches em qualquer situação e, especialmente, lide com condições limítrofes
Pontos do algoritmo:
1. A atualização de cada fator dependente na fórmula mantém um significado independente e um mecanismo de atualização para manter a confiabilidade e a simplicidade do algoritmo
◦A atualização da lista de IPs é garantida conjuntamente pela descoberta de registro do serviço e o framework RPC
◦ CPU de atualização de RPC
2. Preste atenção ao significado do valor limite, que precisa distinguir valores contínuos
◦CPU = 0, significa desconhecido, não significa bom desempenho da CPU
◦w = 0, o que significa que nenhum tráfego será alocado, e será 0 apenas quando estiver indisponível; se estiver disponível, deve haver pelo menos um valor menor para garantir que o RPC ainda possa ser acionado e, em seguida, o peso pode ser atualizado
3. Peso da atualização do algoritmo, não depende do gatilho RPC, mas deve ser atualizado regularmente
3. Verificação da função
3.1 Preparação do teste de pressão
| Módulo | IP | CPU |
|---|---|---|
| Cliente | 10.173.102.36 | 8 |
| lado do servidor | 11.17.80.238 | 8 |
| 18.11.159.191 | 8 | |
| 11.17.191.137 | 8 |
3.2 Dados de medição de pressão
| índice | balanceamento de carga RR | Balanceamento de carga RALB |
|---|---|---|
| SWC | ||
| CPU | **** |
|
| TP99 |
Devido à pequena diferença no desempenho da máquina, o efeito da CPU do teste de pressão não é óbvio. Para tornar o efeito da CPU mais óbvio, uma carga inicial é aplicada ao nó "11.17.80.238" (ou seja, quando há sem tráfego, a taxa de uso da CPU é de 12,5%)
| índice | Balanceamento de carga LA | balanceamento de carga RR | Balanceamento de carga RALB |
|---|---|---|---|
| SWC | |||
| CPU | |||
| TP99 |
3.3 Conclusão do teste de pressão
Após o teste de pressão, RR e LA têm o problema de desequilíbrio da CPU, o que causará um efeito de placa curta devido à diferença de desempenho dos recursos da máquina e não atingirá o objetivo de utilizar totalmente os recursos.
O RALB usa a CPU como meta de balanceamento, portanto, ajustará o QPS executado pelo nó em tempo real de acordo com a CPU do nó e, em seguida, atingirá a meta de balanceamento da CPU. A verificação funcional está disponível e o desempenho da CPU atende expectativas.
4. Teste de rendimento
4.1 Alvo de medição de pressão
RALB é um algoritmo de balanceamento de carga que usa o uso da CPU como um indicador dinâmico. Ele pode resolver o problema de desequilíbrio da CPU, evitar o efeito de placa curta da CPU e permitir que máquinas com bom desempenho lidem com mais tráfego. Portanto, esperamos que a estratégia de balanceamento de carga RALB possa atingir um certo grau de melhoria na taxa de transferência em comparação com a estratégia de polling RR.
4.2 Preparação do teste de pressão
Existem 100 máquinas no lado do servidor para teste, e o lado do servidor usa limitação de corrente adaptável de CPU pura, e o limite de limitação de corrente é definido como 55%.
4.3 Dados de medição de pressão
Por meio do teste de pressão nos dois modos de balanceamento de carga de RALB e RR, a taxa de transferência do lado do servidor muda com a tendência do tráfego e compara o impacto das duas estratégias de balanceamento de carga na taxa de transferência do cluster.
4.3.1 RALB
4.3.1.1 Dados de rendimento
A tabela a seguir são os dados de taxa de transferência do lado do servidor, que são enviados para o lado do cliente pelo teste e o modo de balanceamento de carga é definido como RALB. Às 18:17, a situação do lado do servidor estava próxima do limite atual. Durante toda a fase de teste de estresse, foram testadas três situações de fluxo irrestrito, restrição parcial de fluxo e restrição total de fluxo.
| tempo | 17:40 | 17:45 | 17:52 | 18:17 | 18:22 |
|---|---|---|---|---|---|
| fluxo total | 2270 | 1715 | 1152 | 1096 | 973 |
| lidar com o tráfego | 982 | 1010 | 1049 | 1061 | 973 |
| Tráfego limitado | 1288 | 705 | 103 | 35 | 0 |
| Taxa de limitação de corrente | 56,74% | 41% | 8,9% | 3,2% | 0% |
| Uso médio da CPU | 55% | 55% | 54% | 54% | 49% |
4.3.1.2 Monitoramento de Indicadores
O tráfego recebido pela máquina do lado do servidor é distribuído de acordo com o desempenho e a CPU permanece balanceada.
| SWC | CPU |
|---|---|
4.3.2 RR
4.3.2.1 Dados de transferência
A tabela a seguir são os dados de taxa de transferência do lado do servidor, que são enviados para o lado do cliente pelo teste, e o modo de balanceamento de carga é definido como RR. O tráfego geral no lado do servidor às 18h46 é próximo ao tráfego geral no lado do servidor às 18h17. O que se segue se concentrará na comparação dos dados nesses dois momentos críticos.
| tempo | 18:40 | 18:46 | 19:57 | 20:02 | 20:04 | 20:09 |
|---|---|---|---|---|---|---|
| fluxo total | 967 | 1082 | 1149 | 1172 | 1263 | 1314 |
| lidar com o tráfego | 927 | 991 | 1024 | 1036 | 1048 | 1047 |
| Tráfego limitado | 40 | 91 | 125 | 136 | 216 | 267 |
| Taxa de limitação de corrente | 4,18% | 8,4% | 10,92% | 11,6% | 17,1% | 20,32% |
| Uso médio da CPU | 45%（部分限流） | 51%（部分限流） | 53%（部分限流） | 54%（接近全部限流） | 55%（全部限流） | 55%（全部限流） |
4.3.2.2 指标监控
Server端收到的流量均衡，但是CPU有差异。
| QPS | CPU |
|---|---|
4.4 压测分析
4.4.1 吞吐曲线
根据4.3节的压测数据，进行Server端吞吐曲线的绘制，对比RALB和RR两种负载均衡模式下的吞吐变化趋势。
import matplotlib.pyplot as plt
import numpy as np
x = [0,1,2,3,4,5,6,7,8,9,9.73,10.958,11.52,17.15,22.7]
y = [0,1,2,3,4,5,6,7,8,9,9.73,10.61,10.49,10.10,9.82]
w = [0,1,2,3,4,5,6,7,8,9.674,10.823,11.496,11.723,12.639,13.141,17.15,22.7]
z = [0,1,2,3,4,5,6,7,8,9.27,9.91,10.24,10.36,10.48,10.47,10.10,9.82]
plt.plot(x, y, 'r-o')
plt.plot(w, z, 'g-o')
plt.show()
4.4.2 曲线分析
| 负载均衡策略 | RALB | RR |
|---|---|---|
| 阶段一：所有机器未限流 | 接收QPS=处理QPS，表现为y =x 的直线 | 接收QPS=处理QPS，表现为y =x 的直线 |
| 阶段二：部分机器限流 | 不存在RALB根据下游CPU进行流量分配，下游根据CPU进行限流，理论上来讲，下游的CPU永远保持一致。所有的机器同时达到限流，不存在部分机器限流的情况。 所以在图中，不限流与全部机器限流是一个转折点，没有平滑过渡的阶段。 | RR策略，下游的机器分配得到的QPS一致，由于下游根据CPU进行限流，所以不同机器限流的时刻有差异。 相对于RALB，RR更早地出现了限流的情况，并且在达到限流之前，RR的吞吐是一直小于RALB的。 |
| 阶段三：全部机器限流 | 全部机器都达到限流阈值55%之后，理论上，之后无论流量怎样增加，处理的QPS会维持不变。图中显示处理的QPS出现了一定程度的下降，是因为处理限流也需要消耗部分CPU | RR达到全部限流的时间要比RALB更晚。在全部限流之后，两种模式的处理的QPS是一致的。 |
4.5 压测结论
临界点：吞吐差异最大的情况，即RALB模式下非限流与全限流的转折点。
通过上述分析，可以知道，在RALB不限流与全部限流的临界点处，RR与RALB的吞吐差异最大。
此时，计算得出RALB模式下，Server集群吞吐提升7.06%。
五、边界测试
通过模拟各种边界条件，来判断系统在边界条件的情况下，系统的稳定性。
| 边界条件 | 压测情形 | 压测结论 |
|---|---|---|
| 下游节点限流 | CPU限流 | 惩罚因子的调整对于流量的分配有重要影响 |
| QPS限流 | 符合预期 | |
| 下游节点超时 | Server端超时每个请求，固定sleep 1s | 请求持续超时期间分配的流量基本为0 |
| 下游节点异常退出 | Server端进程被杀死直接kill -9 pid | 杀死进程并自动拉起，流量分配快速恢复 |
| 下游节点增减 | Server端手动Jsf上下线 | jsf下线期间不承接流量 |
| Server端重启stop + start | 正常反注册、注册方式操作Server端进程，流量分配符合预期 |
六、功能上线
宿迁机房Client端上线配置，在所有Server端集群全面开启RALB负载均衡模式。可以看出，上线前后，Server端的QPS逐渐出现分层，Server端的CPU逐渐趋于统一。
| 上线前后Server端QPS分布 | 上线前后Server端的CPU分布 |
|---|---|
参考资料
1.负载均衡技术
2.深入浅出负载均衡
作者：京东零售 胡沛栋
来源：京东云开发者社区