11 | 负载均衡：节点负载差距这么大，为什么收到的流量还一样？
上一讲我讲解了「多场景的路由选择」，其核心就是「如何根据不同的场景控制选择合适的目标机器」。今天我们来聊一个新的话题，看看在 RPC 中如何实现负载均衡。
一个需求
在进入主题之前，我想先和你分享一个需求，这是我们公司的业务部门给我们提的。
他们反馈的问题是这样的：有一次碰上流量高峰，他们突然发现线上服务的可用率降低了，经过排查发现，是因为其中有几台机器比较旧了。当时最早申请的一批容器配置比较低，缩容的时候留下了几台，当流量达到高峰时，这几台容器由于负载太高，就扛不住压力了。业务问我们有没有好的服务治理策略？
服务节点(配置较低的容器)负载过高服务节点服务调用者服务节点
image.jpeg
这个问题其实挺好解决的，我们当时给出的方案是：在治理平台上调低这几台机器的权重，这样的话，访问的流量自然就减少了。
但业务接着反馈了，说：当他们发现服务可用率降低的时候，业务请求已经受到影响了，这时再如此解决，需要时间啊，那这段时间里业务可能已经有损失了。紧接着他们就提出了需求，问：RPC 框架有没有什么智能负载的机制？能否及时地自动控制服务节点接收到的访问量？
这个需求其实很合理，这也是一个比较普遍的问题。确实，虽说我们的服务治理平台能够动态地控制线上服务节点接收的访问量，但当业务方发现部分机器负载过高或者响应变慢的时候再去调整节点权重，真的很可能已经影响到线上服务的可用率了（人工干预的时效性较低差。
看到这儿，你有没有想到什么好的处理方案呢？接下来，我们就以这个问题为背景，一起看看 RPC 框架的负载均衡。
什么是负载均衡？
我先来简单地介绍下负载均衡。当我们的一个服务节点无法支撑现有的访问量时，我们会部署多个节点，组成一个集群，然后通过负载均衡，将请求分发给这个集群下的每个服务节点，从而达到多个服务节点共同分担请求压力的目的。
服务节点服务节点负载均衡域名请求服务节点服务节点
image.jpeg
负载均衡主要分为软负载和硬负载，软负载就是在一台或多台服务器上安装负载均衡的软件，如 LVS、Nginx 等，硬负载就是通过硬件设备来实现的负载均衡，如 F5 服务器等。负载均衡的算法主要有随机法、轮询法、最小连接法等。
我刚才介绍的负载均衡主要还是应用在 Web 服务上，Web 服务的域名绑定负载均衡的地址，通过负载均衡将用户的请求分发到一个个后端服务上。
