SpringCloud之服务治理机制

服务提供者

服务注册：

服务提供者在启动的时候通过发送Rest请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。Eureka Server在收到这个请求后，将元数据信息存储在一个双层结构Map中，第一层的key是服务名，第二层的key是具体服务的实例名。

服务同步：

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

服务续约：

服务提供者在注册完后，会定期向注册中心发送一个“心跳"来告诉Eureka Server自己还存活着，以防被Eureka Servertichu踢出服务列表。

eureka.instance.lease-renewal-interval-in-seconds= 30 这个参数是定义服务续约的调用间隔时间，默认为30秒。

eureka.instance.lease-expiration-duration-in-seconds= 90 这个参数是定义服务失效时间，默认为90秒。

服务消费者

服务注册：

通过@EnableDiscoveryClient注解启动，将自身注册为服务消费客户端。

获取服务：

发送REST请求给服务注册中心，服务注册中心会返回给服务消费者一个只读的服务清单。该缓存清单默认是30秒更新一次。

eureka.client.registry-fetch-interval-seconds= 30 这个参数用来修改缓存清单更新的时间间隔，时间单位为秒。

服务调用：

服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息，服务消费者可以根据需要调用哪个实例。在Ribbon中默认采用轮询的方式进行调用，从而实现客户端的负载均衡。

服务注册中心

失效剔除：

当某个服务提供者出现网络故障、内存溢出等各种原因而不能正常工作，服务中心并未受到”服务下线“的请求。为了能及时将这些无法提供服务的实例剔除，Eureka Server在启动的时候会创建一个定时任务，默认是60秒一次，将没有续约也就是没有发送”心跳“的服务剔除出去。

自我保护：

我们在本地调试Eureka程序的时候，基本上都会碰到一个红色的警告信息：

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

这是Eureka Server启动了自我保护机制，自我保护机制的工作机制是如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，在开发环境因为不会有网络故障等原因，所以很容易出现这个警告。启动自我保护后此时会出现以下几种情况：

1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。

2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。

3、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。

因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像Zookeeper那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。

eureka.server.enable-self-preservation= false 可以通过这个配置设置为false来关闭自我保护机制，默认识开启的，且建议在生产环境开启自我保护。