客户端负载均衡 Loadbalancer

acos 通过服务发现拿到了所有的可用服务节点列表，但服务请求只能发给一个节点，你知道服务调用是根据什么规则选择目标节点的吗？

负载均衡的作用：了解负载均衡的两大门派，它们分别是网关层负载均衡和客户端负载均衡。你还会理解客户端负载均衡在微服务架构中的优势；

Loadbalancer 工作原理：了解 Loadbalancer 如何运用 @Loadbalanced 注解进行加载；

自定义负载均衡策略：了解 Loadbalancer 的自定义扩展点，在实战项目中实现金丝雀测试。

道理是这个道理，但实现起来就有两条不同的路径。负载均衡有两大门派，服务端负载均衡和客户端负载均衡。我们先来聊聊这两个不同门派的使用场景，再来看看本节课的主角 Loadbalancer 属于哪门哪派。

网关层负载均衡

网关层负载均衡也被称为服务端负载均衡，就是在服务集群内设置一个中心化负载均衡器，比如 API Gateway 服务。发起服务间调用的时候，服务请求并不直接发向目标服务器，而是发给这个全局负载均衡器，它再根据配置的负载均衡策略将请求转发到目标服务。我把这个过程画成了下面这张流程图。

 

 网关层负载均衡的应用范围非常广，它不依赖于服务发现技术，客户端并不需要拉取完整的服务列表；同时，发起服务调用的客户端也不用操心该使用什么负载均衡策略。

不过，网关层负载均衡的劣势也很明显。

网络消耗：多了一次客户端请求网关层的网络开销，在线上高并发场景下这层调用会增加 10ms～20ms 左右的服务响应时间。别小瞧了这十几毫秒的时间，在超高 QPS 的场景下，性能损耗也会被同步放大，降低系统的吞吐量；

 复杂度和故障率提升：需要额外搭建内部网关组件作为负载均衡器，增加了系统复杂度，而多出来的那一次的网络调用无疑也增加了请求失败率。

 Spring Cloud Loadbalancer 可以很好地弥补上面的劣势，那么它是如何做到的呢？

客户端负载均衡

Spring Cloud Loadbalancer 采用了客户端负载均衡技术，每个发起服务调用的客户端都存有完整的目标服务地址列表，根据配置的负载均衡策略，由客户端自己决定向哪台服务器发起调用。

客户端负载均衡的优势很明显。

网络开销小：由客户端直接发起点对点的服务调用，没有中间商赚差价； 

配置灵活：各个客户端可以根据自己的需要灵活定制负载均衡策略。

不过呢，如果想要应用客户端负载均衡，那么还需要满足一个前置条件，发起服务调用的客户端需要获取所有目标服务的地址，这样它才能使用负载均衡规则选取要调用的服务。也就是说，客户端负载均衡技术往往需要依赖服务发现技术来获取服务列表。

所以，Nacos 和 Loadbalancer 自然而然地走到了一起，一个通过服务发现获取服务列表，另一个使用负载均衡规则选出目标服务器。

了解了负载均衡的作用之后，我们来看看 Loadbalancer 的工作原理。

Loadbalancer 工作原理

@Loadbalanced 注解，这个注解就是开启负载均衡功能的玄机。

@Bean
@LoadBalanced
public WebClient.Builder register() {
    return WebClient.builder();
}

Loadbalancer 组件通过 @Loadbalanced 注解对 WebClient 动了一番手脚，在启动过程中利用了自动装配器机制，分三步偷偷摸摸地向 WebClient 中塞了一个特殊的 Filter（过滤器），通过过滤器实现了负载均衡功能。

 

Builder filter(ExchangeFilterFunction filter);

接下来，我们深入源码，看看 Loadbalancer 是如何通过注解将过滤器添加到 WebClient 对象中的，这个过程分为三步。 

第一步，声明负载均衡过滤器。ReactorLoadBalancerClientAutoConfiguration 是一个自动装配器类，我们在项目中引入了 WebClient 和 ReactiveLoadBalancer 类之后，自动装配流程就开始忙活起来了。在这个过程中，它会初始化一个实现了 ExchangeFilterFunction 的实例，在后面的步骤中，该实例将作为过滤器被注入到 WebClient。

下面是