RPC系列四、负载均衡

一、案例讨论

有一次碰上流量高峰，突然发现线上服务的可用率降低了，经过排查发现，是因为其中有几台机器比较旧了。当时最早申请的一批容器配置比较低，缩容的时候留下了几台，当流量达到高峰时，这几台容器由于负载太高，就扛不住压力了。有没有好的服务治理策略？RPC 框架有没有什么智能负载的机制？能否及时地自动控制服务节点接收到的访问量？

 二、负载均衡

简单地介绍下负载均衡。当我们的一个服务节点无法支撑现有的访问量时，我们会部署多个节点，组成一个集群，然后通过负载均衡，将请求分发给这个集群下的每个服务节点，从而达到多个服务节点共同分担请求压力的目的。

负载均衡主要分为软负载和硬负载，

1、软负载

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

2、硬负载

通过硬件设备来实现的负载均衡，如 F5 服务器等。负载均衡的算法主要有随机法、轮询法、最小连接法等。 

1、RPC 框架中的负载均衡

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

RPC 负载均衡策略一般包括随机权重、Hash、轮询。当然，这还是主要看 RPC 框架自身的实现。其中的随机权重策略应该是最常用的一种了，通过随机算法，基本可以保证每个节点接收到的请求流量是均匀的

同时还可以通过控制节点权重的方式，来进行流量控制。比如我们默认每个节点的权重都是 100，但当我们把其中的一个节点的权重设置成 50 时，它接收到的流量就是其他节点的 1/2。 

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

2、自适应负载均衡

RPC 的负载均衡完全由 RPC 框架自身实现，服务调用者发起请求时，会通过配置的负载均衡插件，自主地选择服务节点。那是不是只要调用者知道每个服务节点处理请求的能力，再根据服务处理节点处理请求的能力来判断要打给它多少流量，当一个服务节点负载过高或响应过慢时，就少给它发送请求，反之则多给它发送请求。

（1）那服务调用者节点又该如何判定一个服务节点的处理能力呢？

这里我们可以采用一种打分的策略，服务调用者收集与之建立长连接的每个服务节点的指标数据，如服务节点的负载指标、CPU 核数、内存大小、请求处理的耗时指标（如请求平均耗时、TP99、TP999）、服务节点的状态指标（如正常、亚健康）。通过这些指标，计算出一个分数，比如总分 10 分，如果 CPU 负载达到 70%，就减它 3 分，当然了，减 3 分只是个类比，需要减多少分是需要一个计算策略的。

（2）如果根据这些指标来打分？

这就有点像公司对员工进行年终考核。假设要考核专业能力、沟通能力和工作态度，这三项的占比分别是 30%、30%、40%，给一个员工的评分是 10、8、8，那他的综合分数就是这样计算的：10*30%+8*30%+8*40%=8.6 分。

可以为服务器的每个指标都设置一个指标权重占比，然后再根据这些指标数据，计算分数。

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

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

到这儿，一个自适应的负载均衡我们就完成了，整体的设计方案如下图所示：

1）添加服务指标收集器，并将其作为插件，默认有运行时状态指标收集器、请求耗时指标收集器。

2）运行时状态指标收集器收集服务节点 CPU 核数、CPU 负载以及内存等指标，在服务调用者与服务提供者的心跳数据中获取。

3）请求耗时指标收集器收集请求耗时数据，如平均耗时、TP99、TP999 等。

4）可以配置开启哪些指标收集器，并设置这些参考指标的指标权重，再根据指标数据和指标权重来综合打分。

5） 通过服务节点的综合打分与节点的权重，最终计算出节点的最终权重，之后服务调用者会根据随机权重的策略，来选择服务节点。