一、负载均衡有两大门派，服务端负载均衡和客户端负载均衡

网关层负载均衡

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

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

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

2.复杂度和故障率提升：需要额外搭建内部网关组件作为负载均衡器，增加了系统复杂度，而多出来的那一次的网络调用无疑也增加了请求失败率。Spring Cloud Loadbalancer 可以很好地弥补上面的劣势

客户端负载均衡

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

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

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

2.配置灵活：各个客户端可以根据自己的需要灵活定制负载均衡策略。不过呢，如果想要应用客户端负载均衡，那么还需要满足一个前置条件，发起服务调用的客户端需要获取所有目标服务的地址，这样它才能使用负载均衡规则选取要调用的服务。也就是说，客户端负载均衡技术往往需要依赖服务发现技术来获取服务列表。所以，Nacos 和 Loadbalancer 自然而然地走到了一起，一个通过服务发现获取服务列表，另一个使用负载均衡规则选出目标服务器。

二、Loadbalancer 工作原理

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

Loadbalancer 提供了两种内置负载均衡策略。

RandomLoadBalancer：在服务列表中随机挑选一台服务器发起调用，属于拼人品系列；

RoundRobinLoadBalancer：通过内部保存的一个 position 计数器，按照次序从上到下依次调用服务，每次调用后计数器 +1，属于排好队一个个来系列。

三、思考

有Nignx和API網關，是否還需要微服務的網關呢

答案：需要的，微服务网关和nginx扮演的角色不一样，nginx作为高性能反向代理，性能上是完爆任何微服务网关的，而且Nignx和api网关只负责网关->微服务的链路，但是基于服务发现构建的微服务架构里，微服务之间互相调用是不经过网关的

微服务网关，往往扮演的角色是在外部网关和内部微服务之间的桥梁，通常不会作为最外层网关直接承接外部用户流量