spring-cloud(五）-客户端负载均衡Ribbon

spring-cloud(五）-客户端负载均衡Ribbon

spring-cloud版本：2.6.6
java版本：8
LB（Load Balance，负载均衡）是一种集群技术，它将特定的业务（网络服务、网络流量等）分担给多台网络设备（包括服务器、防火墙等）或多条链路，从而提高了业务处理能力，保证了业务的高可靠性。

负载均衡技术具有一下优势：

（1）高性能：负载均衡技术将业务较均衡的分担到多台设备或链路上，从而提高了整个系统的性能；

（2）可扩展性：负载均衡技术可以方便的增加集群中设备或链路的数量，在不降低业务质量的前提下满足不断增长的业务需求；

（3）高可靠性：单个甚至多个设备或链路法神故障也不会导致业务中断，提高了整个系统的可靠性；

（4）可管理性：大量的管理共组都集中在使用负载均衡技术的设备上，设备集群或链路集群只需要维护通过的配置即可；

（5）透明性：对用户而言，集群等于一个或多个高可靠性、高性能的设备或链路，用户感知不到，也不关心具体的网络结构，增加或减少设备或链路数量都不会影响正常的业务。

1、关系图

2、创建父工程把eureka高可用集群的几个项目导进去

3、创建controller类添加如下内容

4、创建eureka-ribbon-client

5、修改application.yml

补充

1.配置文件内容 eureka.client.register-with-eureka:由于该应用为注册中心，所以设置为false，代表不向注册中心注册自己。
eureka.client.fetch-registry:由于注册中心的职责就是维护服务实例，它并不需要去检索实例，所以也设置为为false。
eureka.client.serviceUrl.defaultZone:注册中心地址
eureka.instance.lease-renewal-interval-in-seconds=30:定义服务续约任务的调用间隔时间，默认为30秒
eureka.instance.lease-expiration-duration-in-seconds=90:用于定义服务时效时间，默认为90秒
2.基础架构 Eureka服务治理基础架构的三个核心要素。

服务注册中心:Eureka提供的服务端，提供服务注册与发现的功能
服务提供者:提供服务的应用，可以是SpringBoot应用，也可以是其他技术平台且遵循Eureka通信机制的应用。
服务消费者:消费者应用从服务注册中心获取服务列表，从而使消费者可以知道去何处调用其所需要的服务(很多时候服务提供者既是服务提供者也是服务消费者)
3.服务治理机制 服务提供者 (1)服务注册 “服务提供者”在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。Eureka Server
接收到这个REST请求之后，将元数据信息存储在一个双层结构Map中，其中第一层的key是服务名，第二层的key是具体服务的实例名。
在服务注册是，需要确认一下
eureka.client.register-with-eureka=true参数是否正确，该值默认为true。若设置为false将不会启动注册操作。

(2)服务同步

比方说两个服务提供者分别注册到两个不同的服务注册中心上，也就是说，它们的信息分别被两个服务注册中心所维护。此时，由于服务注册中心之间因为互相注册为服务，当服务提供者发送注册请求到一个服务注册中心是，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心中的任意一台获取到。

(3)服务续约 在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server:”我还活着”,以防止Eureka
Server的”剔除任务”将该服务实例从服务列表中排除出去，我们称该操作作为服务续约。

服务消费者 (1)获取服务
当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka
Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。
获取服务是服务消费者的基础，所以必须确保eureka.client.fetch-registry=true参数没有被修改成false,该值默认为true。若希望修改缓存清单的更新时间，可以通过eureka.client.registry-fetch-interval-seconds=30参数进行修改，该参数默认值为30，单位为秒。

(2)服务调用
服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有了这些服务实例的详细信息，所以客户端可以根据自己的需求决定具体调用哪个实例，在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。
对于访问实例的选择，Eureka中有Region和Zone的概念，一个Region中可以包含多个Zone，每个服务客户端需要被注册到一个Zone中，所以每个客户端对应一个Region和一个Zone。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方，若访问不到，就访问其他的Zone。

(3)服务下线
在系统运行过程中比如会面临关闭或重启服务的某个实例的情况，在服务关闭期间，我们自然不希望客户端会继续关闭了的实例。所以在客户端程序中，当服务实例进行正常的关闭操作，它会触发一个服务下线的REST请求给Eureka
Server，告诉服务注册中心:”我要下线了”。服务端在接收到请求之后，将该服务状态置为下线，并把该下线事件传播出去。