《RPC实战与核心原理》学习笔记Day10

11 | 负载均衡：节点负载差距这么大，为什么收到的流量还一样？

什么是负载均衡？

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

负载均衡有哪些类型？

负载均衡分为软负载和硬负载两种，软负载就是在一台或多台服务器上安装负载均衡软件，如LVS、Nginx等；硬负载就是通过硬件设备来实现负载均衡，例如F5服务器等。

有哪些常见的负载均衡算法？
常见的负载均衡算法包括：

• 基于权重的随机算法
• 基于最小活跃用数算法
• 基于Hash一致性算法
• 基于加权轮询算法

Dubbo默认采用基于权重的随机算法。

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

示意图如下。

RPC的负载均衡策略一般包括随机权重、Hash、轮询等。

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

所谓自适应的负载均衡，就是指负载均衡组件可以根据服务节点的可处理能力，动态调整服务节点的权重，将请求转发给合适的服务节点，从而保证整个系统的稳定性。

我们可以采用一种打分策略，服务调用者收集与之建立长连接的每个服务节点的指标数据，例如服务节点的负载指标、CPU核数、内存大小、请求处理的平均耗时、服务节点的健康状态等。我们可以为这些指标设置不同的权重，之后就可以计算每个服务节点动态分值。

在得到服务节点的动态分值后，我们把分值作为服务节点的权重，采用随机权重的负载均衡策略去分发请求，这样我们就可以完成一个自适应的负载均衡。

整体设计方案如下。

关键步骤如下：

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

12 | 异常重试：在约定的时间内安全可靠地重试

什么是RPC框架的重试机制？

当调用端发起的请求失败时，RPC框架自身可以进行重试，再重新发送请求，用户可以自行设置是否开启重试以及重试的次数。
调用端发起RPC请求时，会经过负载均衡，选择一个节点，之后它会向这个节点发送请求信息。当消息发送失败或收到异常消息时，我们就可以捕获异常，根据异常触发重试，重新通过负载均衡选择一个节点发送请求信息，并且记录请求的重试次数，当重试次数达到用户配置的重试次数时，就返回给调用端动态代理一个失败异常。

如何在约定的时间内安全可靠的重试？

首先，服务的业务逻辑需要是幂等的，这是我们可以重试的前提。

其次，在每次重试后，都需要重置一下请求的超时时间，因为连续的异常重试可能会导致请求处理时间过长造成超时。

再次，当我们发起服务重试时，负载均衡选择节点时，需要去掉重试之前出现过问题的节点，这样可以提高重试的成功率。

最后，我们可以在RPC框架中配置业务异常相关的白名单，这样当白名单中的业务异常类型被触发时，也可以进行服务重试。