SpringCloud 笔记 （三）---- Eureka通信过程

基础架构

服务注册中心：

Eureka提供的服务端，提供服务注册与发现的功能，也就是eureka-server

服务提供者：

提供服务的应用，可以使springboot应用，也可以是其他技术平台且遵循eureka通信机制的应用。它将自己提供的服务注册到Eureka,以供其他应用发现，即Hello-service应用

服务消费者：

从服务注册中心获取服务列表，从而使消费者可以知道去何处调用其所需要的服务，例如我们的实例使用了Ribbon来实现服务消费，后续会介绍Feign的消费方式。
很多时候，客户端即是服务提供者也是服务消费者。

服务治理机制

服务提供者

服务注册：

启动时发送REST请求方式注册到注册中心，注册中心接收到请求后，将元数据信息存储在一个双层结构Map中，第一层Key是服务名，第二层Key是实例名。
就如同我们实现的那样：

服务同步：

如同之前的高可用注册中心那样，服务可以分别注册到不同的注册中心里。因为此时注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。这样，同一个服务就可以被多个注册中心所维护。

服务续约：

注册完后，服务提供者会维护一个心跳用来告诉注册中心它还服务着，放置eureka-server的“剔除”将该服务实例从服务列表中排除出去，我们称该操作为服务续约。
可调整相关属性。例如：
eureka.instance.lease-renewal-interval-in-seconds=30
服务续约任务的调用间隔时间，默认30秒
eureka.instance.lease-expiration-duration-in-seconds=90
服务失效时间，默认90秒

服务消费者

获取服务

此时，服务注册中心已经注册了一个服务，并且该服务有两个实例。我们启动消费者的时候，它会发送一个REST请求给服务注册中心，获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单返回给客户端，同时该缓存清单会每隔30秒更新一次
获取服务是消费者的基础，所以必须确保eureka.client.fetch-registry=true没有被修改成false,默认为true.
缓存清单的更新时间可以修改：
eureka.client.registry-fetch-interval-seconds=30

服务调用

获取清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例，在ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。

服务下线

当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给EurekaServer,告诉服务注册中心它要下线，服务端接受到请求后，将该服务状态置为下线(DOWN)，并把该下线事件传播出去。

服务注册中心

失效剔除

有些时候，服务实例并不一定会正常下线，可能由于内存溢出，网络故障灯原因使得服务不能正常工作，而注册中心并未收到服务下线的请求。为了从服务列表中将这些无法提供服务的实例剔除，EurekaServer在启动时候会创建一个定时任务，默认每隔一段时间默认60秒将当前清单中超时（默认90秒）没有续约的服务剔除出去。

自我保护

当我们在本地调试基于Eureka的程序时，基本上都会碰到这样一个问题，在服务注册中心面板中出现类似下面的红色警告信息：

该警告就是出发了Eureka Server的自我保护机制。
服务注册到Eureka Server后，会维护一个心跳连接，告诉Eureka Server自己还服务着。在注册中心运行期间，会统计心跳失败的比例再15分钟之内是否低于85%，如果出现低于的情况（单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致），Eureka
Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调试失败的情况，所以客户端必须要有容错机制，比如可以使用请求重试，断路器等机制。
由于本地调试很容易触发注册中心的保护机制，会使得注册中心维护的服务实例不那么准确。所以，我们在本地进行开发的时候，可以使用eureka.server.enable-self-preservation=false参数来关闭保护机制，以确保注册中心可以将不可用的实例正确剔除。