1 需求
流量高峰，突现线上服务可用率降低，排查发现，因其中有几台机器较旧。当时最早申请的一批容器配置较低，缩容时留下几台，当流量达到高峰，这几台容器因负载太高，扛不住压力。
业务部门问题：
当时方案：在治理平台调低这几台机器权重，访问流量就减少了。
但业务说：当他们发现服务可用率降低时，业务请求已受影响，再如此解决，需要时间，这段时间里业务可能已有损失。紧接提出需求：RPC框架有智能负载机制？能及时自动控制服务节点接收到的访问量？
需求合理，也是普遍问题。虽服务治理平台能动态控制线上服务节点接收的访问量，但当业务方发现部分机器负载过高或响应变慢时再调整节点权重，可能已影响线上服务可用率。
2 LB
当一个服务节点无法支撑现有访问量，会部署多节点组成集群。通过LB将请求分发给该集群下的节点，共同分担请求压力。
2.1 LB示意图
负载均衡主要分为：
2.2 软负载
在一或多台服务器安装LB软件，如LVS、Nginx。
2.3 硬负载
通过硬件设备实现的LB，如F5服务器。
LB算法主要有随机法、轮询法、最小连接法等。刚才介绍的LB主要应用在Web服务，Web服务的域名绑定LB的地址，通过LB将用户请求分发到一个个后端服务。
3 RPC LB V.S 传统Web服务LB
为啥不通过DNS实现“服务发现”？为啥不采用添加LB设备或TCP/IP四层代理，域名绑定LB设备的IP或四层代理IP的方式？
因为面临问题：
- 搭建LB设备或TCP/IP四层代理，需额外成本
- 请求流量都经过LB设备，多经过一次网络传输，额外浪费性能
- LB添加、摘除节点，一般要手动添加，当大批量扩容和下线时，会有大量人工操作，“服务发现”在操作上是问题
- 服务治理时，针对不同接口服务、服务的不同分组，LB策略需可配，如都经过这一LB设备，就不易根据不同场景配置不同LB策略
4 RPC的LB
全由RPC框架自身实现，RPC的服务调用者（后文简称为caller）会与“注册中心”下发的所有服务节点建立长连接，在每次发起RPC调用时，caller都会通过配置的负载均衡插件，自主选择一个服务节点，发起RPC调用请求。
4.1 RPC框架LB示意图
LB机制完全由RPC框架自身实现，不依赖任何LB设备，自然不会发生LB设备的单点问题，服务调用方的LB策略也可配，可通过控制权重，对LB进行治理。
咋动态、智能控制线上服务节点所接收到的请求流量？关键就在RPC框架的LB。设计一种自适应LB策略。
5 咋设计自适应的LB？
caller发起请求时，会通过配置的LB插件，自主选择服务节点。是不是只要调用者知道每个服务节点处理请求的能力，再依次判断要打给它多少流量就行了？
5.1 服务caller节点咋判定一个服务节点的处理能力？
采用打分策略，caller收集与之建立长连接的每个服务节点的指标数据，如：
- 服务节点的负载指标
- CPU核数
- 内存大小
- 请求处理的耗时指标（如请求平均耗时、TP99、TP999）
- 服务节点的状态指标（如正常、亚健康）
- ...
通过这些指标，计算出一个分数，如总分10分，若CPU负载达70%，就减它 3 分，当然了，具体减几分需要一个结合业务特点的计算策略。
5.2 咋根据指标打分？
年终考核专业能力、沟通能力和工作态度分别占比30%、30%、40%，我给一个员工评分10、8、8，那他综合分数计算：1030% 830% 8*40%=8.6分。
给服务节点打分一样，为每个指标都设置一个指标权重占比，然后再根据这些指标数据，计算分数。
Q：caller给每个服务节点都打分后，会发送请求，这时我们咋根据分数去控制给每个服务节点发送多少流量呢？
A：配合随机权重的LB策略去控制，通过最终指标分数修改服务节点最终权重。如给一个服务节点8分（满分10分），服务节点权重100，最终权重80（100*80%）。caller发请求时，通过随机权重策略选择服务节点，该节点接收到的流量就是其他正常节点的80%（这里假设其他节点默认权重都100，且指标正常，10分）。
5.3 自适应的LB整体设计方案
RPC自适应负载均衡示意图：
5.4 关键步骤
- 添加服务指标收集器，并将其作为插件，默认有运行时状态指标收集器、请求耗时指标收集器
- 运行时状态指标收集器收集服务节点CPU核数、CPU负载以及内存等指标，在caller与服务提供者（后文简称为provider）的心跳数据中获取
- 请求耗时指标收集器收集请求耗时数据，如平均耗时、TP99、TP999
- 可以配置开启哪些指标收集器，并设置这些参考指标的指标权重，再根据指标数据和指标权重来综合打分
- 通过服务节点的综合打分与节点的权重，最终计算出节点的最终权重，之后caller会根据随机权重的策略，来选择服务节点
6 总结
RPC框架不是依赖一个LB设备或LB服务器来实现LB，而是由RPC框架本身实现，caller可自主选择服务节点，发起服务调用：
- RPC框架无需依赖专门LB设备，节约成本
- 减少了与LB设备间额外的网络传输，提升传输效率
- LB策略可配，便于服务治理
自适应LB，通过它，就能根据caller依赖的服务集群中每个节点的自身状态，智能控制发送给每个服务节点的请求流量，防止因某个服务节点负载过高、请求处理过慢而影响到整个服务集群的可用率。
自适应LB关键，就是调用端收集服务端每个节点的指标数据，再根据各方面指标数据计算打分，最后根据每个节点的分数，将更多流量打到分数较高的节点。
7 FAQ
Q：常用的LB算法？
A：以Dubbo为例说明
- 基于权重随机算法（默认）
- 基于最少活跃调用数算法
- 基于 hash 一致性
- 基于加权轮询算法（又分一般轮询和动态加权轮询）
- 能力负载（根据响应时间，根据可用率等来动态智能调节）
- 智能负载均衡策略，核心是及时
轮询算法、随机算法，编码简单，适用于集群中各节点提供服务能力等同且无状态的场景。两个方法将服务节点性能当成一样，但实际复杂环境，服务节点处能力不一。需要我们有比重地分发请求，于是加入权重属性，即有权重的随机算法、加权轮询算法。
若某服务节点异常，服务处理缓慢。轮询算法、随机算法还会持续将请求发分到服务节点，进一步加重服务节点情况。这是个较大缺点。
最少活跃调用数算法，记录服务节点的活跃数，活跃数越少，表明该provider效率越高，单位时间内可处理更多的请求，可有效改善上面的case。
哈希（又分一般哈希，一致性哈希、加虚拟节点的一致性哈希）。hash一致性算法，适用于服务有状态的的场景，但是实很少需要有状态的场景，该算法比较少使用。
Q：grpc官方并未提供服务发现注册的功能实现，但为不同语言的gRPC代码实现提供可扩展的命名解析和负载均衡接口。
A：基本原理：服务启动后，grpc客户端向命名服务器发名称解析请求，名称会解析为一或多个ip地址，每个ip地址会标识它是服务器地址还是负载均衡地址，以及标识要使用的那个客户端的负载均衡策略或服务配置。客户端实例化负载均衡策略，如解析返回的地址是负载均衡器的地址，则客户端将使用扩展的负载均衡策略，反之客户端使用服务器配置请求的负载均衡策略。负载均衡策略为每个服务器地址创建一个子通道，当有rpc请求时，负载均衡策略决定那个子通道即grpc服务器将接收请求，当可用服务器为空时客户端的请求将被阻塞。
- 好处，灵活，支持扩展，可以扩展满足自己需求的策略
- 缺点，需自己集成，对技术人员有一定的要求
Q：若系统包含一些处理时间较长的请求，如下载一个大数据量报表，这种请求会大大提高该provider平均请求耗时，而发现这种耗时会存在时延，caller仍发送了很多请求到该服务器，这种情况咋看?
A：可考虑背压。
Q：路由策略和负载均衡的结果都是选择一个合适的服务节点，这俩有啥区别？
A：路由一般是规则设定，一般都是路由之后，负载再生效。
Q：心跳检测，我理解是让服务提供方消耗少量的性能，来评估性能并判定是健康还是亚健康。后来说到有个检测服务专门做这件事，然后推给服务调用方。这里又说是caller直接心跳检测。若caller直接调用心跳检测，对caller来说检测及时。但对provider，随caller增多会增加性能损耗，若用注册中心，感知不及时。咋处理较好呢？
A：“冷暖自知”，caller比第三方更准确知道对方的状态。
Q：CPU 核数、CPU 负载以及内存等指标 有什么比较好的获取方式吗？计算每个服务节点的权重 这个是周期性统计计算然后在负载均衡器中更新吗？
A：周期实现起来，最简单，即定时任务。
Q：是不是每个RPC调用方，也就是客户端都存在一个智能LB？那就是每个RPC调用方都能掌握全局的负载信息，要不然无法做LB？其实还是对"负载均衡由RPC框架来做"不理解，这个RPC框架是每个RPC调用方都有一份吗？
A：LB一般都要内置在RPC里，用户也可进行扩展。
