为什么需要负载均衡
俗话说在生产队薅羊毛不能逮着一只羊薅，在微服务领域也是这个道理。面对一个庞大的微服务集群，如果你每次发起服务调用都只盯着那一两台服务器，在大用户访问量的情况下，这几台被薅羊毛的服务器一定会不堪重负。
负载均衡要干什么事情
负载均衡有两大门派，服务端负载均衡和客户端负载均衡。我们先来聊聊这两个不同门派的使用场景，再来看看本节课的主角Spring Cloud Loadbalancer 属于哪门哪派。
服务端负载均衡
在服务集群内设置一个中心化负载均衡器，比如Nginx。发起服务间调用的时候，服务请求并不直接发向目标服务器，而是发给这个全局负载均衡器，它再根据配置的负载均衡策略将请求转发到目标服务。
优点：
- 服务端负载均衡应用范围非常广，它不依赖于服务发现技术，客户端并不需要拉取完整的服务列表；同时，发起服务调用的客户端也不用操心该使用什么负载均衡策略。
劣势：
- 网络消耗
- 复杂度和故障率提升
Spring Cloud Loadbalancer 可以很好地弥补上面的劣势，那么它是如何做到的呢？
客户端负载均衡
Spring Cloud Loadbalancer 采用了客户端负载均衡技术，每个发起服务调用的客户端都存有完整的目标服务地址列表，根据配置的负载均衡策略，由客户端自己决定向哪台服务器发起调用。
优势：
- 网络开销小
- 配置灵活
劣势：
需要满足⼀个前置条件，发起服务调用的客户 端需要获取所有目标服务的地址，这样它才能使用负载均衡规则选取要调用的服务。也就是说，客户端负载均衡技术往往需要依赖服务发现技术来获取服务列表。
负载均衡需要解决两个最基本的问题:
第一个是从哪里选服务实例
在Spring Cloud的Eureka微服务系统中，维护微服务实例清单的是Eureka服务治理中心，而具体微服务实例会执行服务获取，获得微服务实例清单，缓存到本地，同时，还会按照一个时间间隔更新这份实例清单（因为实例清单也是在不断维护和变化的)。
第二个是如何选择服务实例
通过过负载均衡的策略从服务实例清单列表中选择具体实例。
注意：
Eurka和Loadbalancer 自然而然地到了一起，一个通过服务发现获取服务列表，
另一个使用负载均衡规则选出目标服务器，然后过着没羞没躁的生活。
什么是Spring Cloud Ribbon
Spring Cloud Ribbon是NetFlix发布的负载均衡器，它有助于Http和Tcp的客户端行为。可以根据负载均衡算法（轮询、随机或自定义）自动帮助消费者请求，默认就是轮询。
问题：
- 状态 -
停更进维- 替代方案 -
Spring Cloud Loadbalancer
什么是Spring Cloud LoadBalancer
但是由于Ribbon已经进入维护模式，并且Ribbon 2并不与Ribbon 1相互兼容，所以Spring Cloud全家桶在Spring Cloud Commons项目中，添加了Spring cloud Loadbalancer作为新的负载均衡器，并且做了向前兼容，就算你的项目中继续用 Spring Cloud Netflix 套装（包括Ribbon，Eureka，Zuul，Hystrix等等）让你的项目中有这些依赖，你也可以通过简单的配置，把Ribbon替换成Spring Cloud LoadBalancer。
