Dubbo负载平衡

负载平衡计谋与设置细节

Dubbo 内置了 client-based 负载平衡机制，如下是当前支持的负载平衡算法，团结上文提到的主动服务发现机制，斲丧端会主动使用 Weighted Random LoadBalance 加权随机负载平衡计谋 选址调用。
如果要调解负载平衡算法，以下是 Dubbo 框架内置的负载平衡计谋：
算法特性备注设置值Weighted Random LoadBalance加权随机默认算法，默认权重类似random (默认)RoundRobin LoadBalance加权轮询鉴戒于 Nginx 的平滑加权轮询算法，默认权重类似roundrobinLeastActive LoadBalance最少活泼优先 + 加权随机背后是能者多劳的头脑leastactiveShortest-Response LoadBalance最短相应优先 + 加权随机更加关注相应速率shortestresponseConsistentHash LoadBalance同等性哈希确定的入参，确定的提供者，实用于有状态哀求consistenthashP2C LoadBalancePower of Two Choice随机选择两个节点后，继承选择“毗连数”较小的谁人节点。p2cAdaptive LoadBalance自顺应负载平衡在 P2C 算法底子上，选择二者中 load 最小的谁人节点adaptive全局设置

Dubbo 框架的默认计谋是 random 加权随机负载平衡。如果要调解计谋，只必要设置 loadbalance 相应取值即可，每种负载平衡计谋取值请拜见文档最上方表格。
为全部服务调用指定全局设置：

1. dubbo:
2.   consumer:
3.     loadbalance: roundrobin

复制代码

接口级设置

可以为每个服务指定差别的负载平衡计谋。
在 provider 端设置，作为 consumer 侧默认值

1. @DubboService(loadbalance = "roundrobin")
2. public class DemoServiceImpl implements DemoService {}

复制代码

在 consumer 端设置，具备更高优先级

1. @DubboReference(loadbalance = "roundrobin")
2. private DemoService demoService;

复制代码

方法级设置

也可以指定方法(method)级别的负载平衡计谋。
在 Spring Boot 开发模式下，设置 method 级别参数有以下几种方式：
JavaConfig

1. @Configuration
2. public class DubboConfiguration {
3.     @Bean
4.     public ServiceBean demoService() {
5.             MethodConfig method = new MethodConfig();
6.                 method.setName("sayHello");
7.                 method.setLoadbalance("roundrobin");
9.         ServiceBean service = new ServiceBean();
10.         service.setInterface(DemoService.class);
11.         service.setRef(new DemoServiceImpl());
12.         service.addMethod(method)
13.         return service;
14.     }
15. }

复制代码

1. @Autowire
2. private DemoService demoService;
4. @Configuration
5. public class DubboConfiguration {
6.     @Bean
7.     public ReferenceBean demoService() {
8.             MethodConfig method = new MethodConfig();
9.                 method.setName("sayHello");
10.                 method.setLoadbalance("roundrobin");
12.         ReferenceBean<DemoService> reference = new ReferenceBean<>();
13.                 reference.setInterface(DemoService.class);
14.                 reference.addMethod(method);
15.         return reference;
16.     }
17. }

复制代码

dubbo.properties

1. dubbo.reference.org.apache.dubbo.samples.api.DemoService.sayHello.loadbalance=roundrobin

复制代码

同等性哈希设置

默认接纳第一个参数作为哈希 key，如果必要切换参数，可以指定 hash.arguments 属性

1. ReferenceConfig<DemoService> referenceConfig = new ReferenceConfig<DemoService>();
2. // ... init
3. Map<String, String> parameters = new HashMap<String, String>();
4. parameters.put("hash.arguments", "1");
5. parameters.put("sayHello.hash.arguments", "0,1");
6. referenceConfig.setParameters(parameters);
7. referenceConfig.setLoadBalance("consistenthash");
8. referenceConfig.get();

复制代码

自顺应负载平衡设置

只必要在 consumer 或 provider 端将 loadbalance 设置为 p2c 大概 adaptive 即可。
自顺应负载平衡与限流团体先容

本文所说的柔性服务重要是指consumer端的负载平衡和provider端的限流两个功能。在之前的dubbo版本中，

• 负载平衡部分更多的思量的是公平性原则，即consumer端尽大概划一的从provider中作出选择，在某些环境下体现并不敷理想。
  
• 限流部分只提供了静态的限流方案，必要用户对provider端设置静态的最大并发值，然而该值的公道选取对用户来讲并不容易。
  

我们针对这些存在的题目举行了改进。
负载平衡

使用先容

在原来的dubbo版本中，有五种负载平衡的方案供选择，他们分别是 Random、ShortestResponse、RoundRobin、LeastActive 和 ConsistentHash。此中除 ShortestResponse 和 LeastActive 外，其他的几种方案重要是思量选择时的公平性和稳固性。
对于 ShortestResponse 来说，其计划目标是从全部备选的 provider 中选择 response 时间最短的以进步体系团体的吞吐量。然而存在两个题目：

• 在大多数的场景下，差别provider的response时长没有非常显着的区别，此时该算法会退化为随机选择。
  
• response的时间黑白偶然也并不能代表呆板的吞吐本事。对于 LeastActive 来说，其以为应该将流量尽大概分配到当前并发处置处罚使命较少的呆板上。但是其同样存在和 ShortestResponse 类似的题目，即这并不能单独代表呆板的吞吐本事。
  

基于以上分析，我们提出了两种新的负载平衡算法。一种是同样基于公平性思量的单纯 P2C 算法，另一种是基于自顺应的方法 adaptive，其试图自顺应的权衡 provider 端呆板的吞吐本事，然后将流量尽大概分配到吞吐本事高的呆板上，以进步体系团体的性能。
总体结果

对于负载平衡部分的有效性实验在两个差别的环境下举行的，分别是提供端呆板设置比力平衡和提供端呆板设置差距较大的环境。

使用方法

Dubbo Java 实现的使用方法 与原来的负载平衡方法类似。只必要在consumer端将"loadbalance"设置为"p2c"大概"adaptive"即可。
代码布局

负载平衡部分的算法实现只必要在原来负载平衡框架内继承 LoadBalance接口即可。
原理先容

P2C算法

Power of Two Choice 算法简单但是经典，重要思绪如下：

• 对于每次调用，从可用的provider列表中做两次随机选择，选出两个节点providerA和providerB。
  
• 比力providerA和providerB两个节点，选择其“当前正在处置处罚的毗连数”较小的谁人节点。
  

adaptive算法

代码的github所在
相干指标

• cpuLoad 
  
  。该指标在provider端呆板得到，并通过invocation的attachment转达给consumer端。
  
• rt rt为一次rpc调用所用的时间，单位为毫秒。
  
• timeout timeout为本次rpc调用超时剩余的时间，单位为毫秒。
  
• weight weight是设置的服务权重。
  
• currentProviderTime provider端在盘算cpuLoad时的时间，单位是毫秒
  
• currentTime currentTime为末了一次盘算load时的时间，初始化为currentProviderTime，单位是毫秒。
  
• multiple 
  
  
  
• lastLatency 
  
  
  
• beta 平滑参数，默以为0.5
  
• ewma lastLatency的平滑值
  
  
  
• inflight inflight为consumer端还未返回的哀求的数目。 
  
  
  
• load 对于备选后端呆板x来说，若间隔前次被调用的时间大于2*timeout，则其load值为0。 否则,
  
  
  

算法实现

依然是基于P2C算法。

• 从备选列表中做两次随机选择，得到providerA和providerB
  
• 比力providerA和providerB的load值，选择较小的谁人。
  

自顺应限流

与负载平衡运行在consumer端差别的是，限流功能运行在provider端。其作用是限定provider端处置处罚并发使命时的最大数目。从理论上讲，服务端呆板的处置处罚本事是存在上限的，对于一台服务端呆板，当短时间内出现大量的哀求调用时，会导致处置处罚不实时的哀求积存，使呆板过载。在这种环境下大概导致两个题目：

• 由于哀求积存，终极全部的哀求都必须等候较长时间才气被处置处罚，从而使整个服务瘫痪。
  
• 服务端呆板长时间的过载大概有宕机的风险。
  

因此，在大概存在过载风险时，拒绝掉一部分哀求反而是更好的选择。在之前的 Dubbo 版本中，限流是通过在 provider 端设置静态的最大并发值实现的。但是在服务数目多，拓扑复杂且处置处罚本事会动态变革的局面下，该值难以通过盘算静态设置。
基于以上缘故原由，我们必要一种自顺应的算法，其可以动态调解服务端呆板的最大并发值，使其可以在包管呆板不外载的条件下，尽大概多的处置处罚吸取到的哀求。因此，我们参考相干理论与算法实践底子上，在 Dubbo 框架内实现了两种自顺应限流算法，分别是基于启发式平滑的HeuristicSmoothingFlowControl 和基于窗口的 AutoConcurrencyLimier。
代码的github所在
使用先容

总体结果

自顺应限流部分的有效性实验我们在提供端呆板设置尽大概大的环境下举行，而且为了凸显结果，在实验中我们将单次哀求的复杂度进步，将超时时间尽大概设置的大，而且开启斲丧端的重试功能。
 

使用方法

要确保服务端存在多个节点，而且斲丧端开启重试计谋的条件下，限流功能才气更好的发挥作用。
Dubbo Java 实现的自顺应限流开启方法 与静态的最大并发值设置类似，只需在provider端将"flowcontrol"设置为"autoConcurrencyLimier"大概"heuristicSmoothingFlowControl"即可。
代码布局

• FlowControlFilter：在provider端的filter负责根据限流算法的结果来对provider端举行限流功能。
  
• FlowControl：根据dubbo的spi实现的限流算法的接口。限流的详细实现算法必要继承自该接口并可以通过dubbo的spi方式使用。
  
• CpuUsage：周期性获取cpu的相干指标
  
• HardwareMetricsCollector：获取硬件指标的相干方法
  
• ServerMetricsCollector：基于滑动窗口的获取限流必要的指标的相干方法。比如qps等。
  
• AutoConcurrencyLimier：自顺应限流的详细实现算法。
  
• HeuristicSmoothingFlowControl：自顺应限流的详细实现方法。
  

原理先容

HeuristicSmoothingFlowControl

相干指标

• alpha alpha为可担当的延时的上升幅度，默以为0.3
  
• minLatency 在一个时间窗口内的最小的Latency值。
  
• noLoadLatency noLoadLatency是单纯处置处罚使命的延时，不包罗列队时间。这是服务端呆板的固有属性，但是并不是刻舟求剑的。在HeuristicSmoothingFlowControl算法中，我们根据呆板CPU的使用率来确定呆板当前的noLoadLatency。当呆板的CPU使用率较低时，我们以为minLatency便是noLoadLatency。当CPU使用率适中时，我们平滑的用minLatency来更新noLoadLatency的值。当CPU使用率较高时，noLoadLatency的值不再改变。
  
• maxQPS 一个时间窗口周期内的QPS的最大值。
  
• avgLatency 一个时间窗口周期内的Latency的均匀值，单位为毫秒。
  
• maxConcurrency 盘算得到的当前服务提供端的最大并发值。 
  
  
  

算法实现

当服务端收到一个哀求时，起首判断CPU的使用率是否凌驾50%。如果没有凌驾50%，则担当这个哀求举行处置处罚。如果凌驾50%，分析当前的负载较高，便从HeuristicSmoothingFlowControl算法中得到当前的maxConcurrency值。如果当前正在处置处罚的哀求数目凌驾了maxConcurrency，则拒绝该哀求。


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金