RPC框架的负载均衡机制解析

1 需求

流量高峰，突现线上服务可用率降低，排查发现，因为其中有几台机器较旧。当时最早申请的一批容器配置较低，缩容时留下了几台，当流量达到高峰时，这几台容器由于负载太高，扛不住压力。

业务部门问题：

当时给出方案：在治理平台调低这几台机器权重，访问流量就减少了。

但业务说：当他们发现服务可用率降低时，业务请求已受影响，再如此解决，需要时间，那这段时间里业务可能已有损失。紧接提出需求：RPC框架有智能负载机制？能及时自动控制服务节点接收到的访问量？

需求合理，这也是普遍问题。确实，虽服务治理平台能动态控制线上服务节点接收的访问量，但当业务方发现部分机器负载过高或响应变慢时再调整节点权重，可能已经影响到线上服务可用率。

2 负载均衡

当我们的一个服务节点无法支撑现有访问量，会部署多节点组成集群。通过负载均衡，将请求分发给这个集群下的节点，共同分担请求压力。

负载均衡示意图：

负载均衡主要分为：

软负载

在一台或多台服务器上安装负载均衡的软件，如LVS、Nginx

硬负载

通过硬件设备来实现的负载均衡，如F5服务器等。

负载均衡的算法主要有随机法、轮询法、最小连接法等。刚才介绍的负载均衡主要应用在Web服务，Web服务的域名绑定负载均衡的地址，通过负载均衡将用户的请求分发到一个个后端服务上。

3 RPC负载均衡 V.S 传统Web服务负载均衡

为什么不通过DNS来实现“服务发现”？

为什么不采用添加负载均衡设备或者TCP/IP四层代理，域名绑定负载均衡设备的IP或者四层代理IP的方式？

因为面临如下问题：

1. 搭建负载均衡设备或TCP/IP四层代理，需额外成本
2. 请求流量都经过负载均衡设备，多经过一次网络传输，额外浪费性能
3. 负载均衡添加节点和摘除节点，一般要手动添加，当大批量扩容和下线时，会有大量的人工操作，“服务发现”在操作上是个问题
4. 我们在服务治理的时候，针对不同接口服务、服务的不同分组，负载均衡策略需可配，如果大家都经过这一个负载均衡设备，就不容易根据不同场景来配置不同负载均衡策略

4 RPC的负载均衡

全由RPC框架自身实现，RPC的服务调用者会与“注册中心”下发的所有服务节点建立长连接，在每次发起RPC调用时，服务调用者都会通过配置的负载均衡插件，自主选择一个服务节点，发起RPC调用请求。

RPC框架负载均衡示意图：

负载均衡机制完全是由RPC框架自身实现的，不依赖任何负载均衡设备，自然不会发生负载均衡设备的单点问题，服务调用方的负载均衡策略也可配，可通过控制权重，对负载均衡进行治理。

所以，如何动态、智能控制线上服务节点所接收到的请求流量？

关键就在RPC框架的负载均衡上。设计一种自适应的负载均衡策略。

5 如何设计自适应的负载均衡？

服务调用者发起请求时，会通过配置的负载均衡插件，自主选择服务节点。是不是只要调用者知道每个服务节点处理请求的能力，再依次判断要打给它多少流量即可？

5.1 服务调用者节点如何判定一个服务节点的处理能力

采用一种打分策略，服务调用者收集与之建立长连接的每个服务节点的指标数据，如服务节点的负载指标、CPU核数、内存大小、请求处理的耗时指标（如请求平均耗时、TP99、TP999）、服务节点的状态指标（如正常、亚健康）。

通过这些指标，计算出一个分数，比如总分10分，如果CPU负载达到70%，就减它3分，当然了，减3分只是个类比，需要减多少分是需要一个计算策略。

5.2 如何根据指标打分

年终考核专业能力、沟通能力和工作态度，这三项占比30%、30%、40%，我给一个员工的评分是10、8、8，那他的综合分数就是这样计算的：1030%+830%+8*40%=8.6分。

给服务节点打分一样，为每个指标都设置一个指标权重占比，然后再根据这些指标数据，计算分数。

服务调用者给每个服务节点都打完分之后，会发送请求，那这时候我们又该如何根据分数去控制给每个服务节点发送多少流量呢？

配合随机权重的负载均衡策略去控制，通过最终指标分数修改服务节点最终权重。如给一个服务节点8分（满分10分），服务节点权重100，最终权重80（100*80%）。服务调用者发请求时，通过随机权重策略选择服务节点，这节点接收到的流量就是其他正常节点的80%（这里假设其他节点默认权重都是100，且指标正常，10分）。

5.3 自适应的负载均衡整体的设计方案

RPC自适应负载均衡示意图：

5.4 关键步骤

1. 添加服务指标收集器，并将其作为插件，默认有运行时状态指标收集器、请求耗时指标收集器
2. 运行时状态指标收集器收集服务节点CPU核数、CPU负载以及内存等指标，在服务调用者与服务提供者的心跳数据中获取
3. 请求耗时指标收集器收集请求耗时数据，如平均耗时、TP99、TP999
4. 可以配置开启哪些指标收集器，并设置这些参考指标的指标权重，再根据指标数据和指标权重来综合打分
5. 通过服务节点的综合打分与节点的权重，最终计算出节点的最终权重，之后服务调用者会根据随机权重的策略，来选择服务节点

6 总结

RPC框架不是依赖一个负载均衡设备或负载均衡服务器来实现负载均衡，而由RPC框架本身实现，服务调用者可自主选择服务节点，发起服务调用：

• RPC框架无需依赖专门负载均衡设备，节约成本
• 减少了与负载均衡设备间额外的网络传输，提升了传输效率；并且均衡策略可配，便于服务治理

自适应负载均衡，通过它，就能根据服务调用者依赖的服务集群中每个节点的自身状态，智能控制发送给每个服务节点的请求流量，防止因某个服务节点负载过高、请求处理过慢而影响到整个服务集群的可用率。

自适应的负载均衡关键点就是调用端收集服务端每个节点的指标数据，再根据各方面的指标数据进行计算打分，最后根据每个节点的分数，将更多的流量打到分数较高的节点上。

7 FAQ

以 Dubbo 为例，常用负载均衡： 1.基于权重随机算法 2.基于最少活跃调用数算法 3.基于 hash 一致性 4.基于加权轮询算法

Dubbo 默认使用权重随机。

轮询算法与随机算法相对来说编码比较简单，适用于集群中各个节点提供服务能力等同且无状态的场景。两个方法将服务节点性能当成一样，但是实际复杂环境，服务节点处能力不一样。这就需要我们有比重分发请求，于是加入权重属性，就有了权重的随机算法与加权轮询算法。

另外如果某个服务节点出现问题，服务处理缓慢。轮询算法与随机算法还会持续的将请求发分到服务节点，进一步加重服务节点情况。这是一个比较大的缺点。

最少活跃调用数算法，将会记录服务节点的活跃数，活跃数越少，表明该服务提供者效率越高，单位时间内可处理更多的请求，可以有效改善上面说的情况。

hash 一致性算法，适用于服务有状态的的场景，但是实很少需要有状态的场景，该算法比较少使用。

grpc官方并未提供服务发现注册的功能实现，但为不同语言的gRPC代码实现提供可扩展的命名解析和负载均衡接口。基本原理：服务启动后，grpc客户端向命名服务器发名称解析请求，名称会解析为一或多个ip地址，每个ip地址会标识它是服务器地址还是负载均衡地址，以及标识要使用的那个客户端的负载均衡策略或服务配置。客户端实例化负载均衡策略，如解析返回的地址是负载均衡器的地址，则客户端将使用扩展的负载均衡策略，反之客户端使用服务器配置请求的负载均衡策略。负载均衡策略为每个服务器地址创建一个子通道，当有rpc请求时，负载均衡策略决定那个子通道即grpc服务器将接收请求，当可用服务器为空时客户端的请求将被阻塞。

• 好处，灵活，支持扩展，可以扩展满足自己需求的策略
• 缺点，需自己集成，对技术人员有一定的要求

如果系统包含一些处理时间较长的请求，例如下载一个大数据量的报表，这种请求会大大提高该服务提供者的平均请求耗时，而发现这种耗时会存在时延，调用者仍然发送了很多请求到该服务器，这种情况怎么看?可以考虑背压。

路由策略和负载均衡的结果都是选择一个合适的服务节点，那这两个有什么区别呢？

路由一般是规则设定，一般都是路由之后，负载再生效。

1：随机 2：轮询（又分一般轮询、加权轮询、动态加权轮询） 3：哈希（又分一般哈希，一致性哈希、加虚拟节点的一致性哈希） 4：能力负载（根据响应时间，根据可用率等来动态智能调节） 5：智能负载均衡策略，核心在于及时

从心跳检测，到路由策略，再到本节。有个问题。心跳检测我理解，让服务提供方消耗少量的性能，来评估性能并判定是健康还是亚健康。后来说到有一个检测服务专门做这件事，然后推给服务调用方。这里又说是服务调用方，直接心跳检测。如果调用方直接调用心跳检测，对服务调用方来说检测及时。但对于提供方来说，随着调用方的增多会增加性能的损耗，如果用注册中心，感知不及时。怎么处理比较好呢？一般都是怎么做？

“冷暖自知”，调用方比第三方更准确知道对方状态

CPU 核数、CPU 负载以及内存等指标 有什么比较好的获取方式吗？ 计算 每个服务节点的权重 这个是周期性统计计算然后在负载均衡器中更新吗？

周期实现起来，最简单，即定时任务。

是不是每个rpc调用方，也就是客户端都存在一个智能负载均衡？那就是每个rpc调用方都能掌握全局的负载信息了，要不然无法做负载均衡？其实还是对"负载均衡由rpc框架来做"不理解，这个rpc框架是每个rpc调用方都会有一份吗？

负载均衡一般都需要内置在rpc里面，用于也可以进行扩展。