Eureka的功能特性及相关配置

1.服务提供者
1.1服务注册
服务提供者启动时，会通过rest请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。Eureka Server接收到请求后，将元数据信息存储在一个双层结构的Map中，其中与第一层的key是服务名，第二层的key是具体的服务实例名
eureka.client.register-with-eureka=false 是否向注册中心注册自己 默认 true
eureka.client.fetch-registry=false 是否去检索注册中心的服务 默认 true

1.2服务续约
在注册完服务后，服务提供者会维护一个心跳用来持续高速Eureka Server“我还活着”，以防止Eureka Server的“剔除任务”将该服务实例从服务列表中排除出去
eureka.instance.lease-renewal-interval-in-seconds=30 定义服务续约任务的调用间隔时间 默认30s
eureka.instance.lease-expiration-duration-in-seconds=90 定义服务失效的时间 默认90s

1.3服务下线
当服务实例进行正常的关闭操作时，会触发一个服务下线的rest请求给Eureka Server ，告诉注册中心：”我要下线了“，服务端在接收请求后，将该服务置为下线（DOWN），并把下线时间传播出去（通知服务消费者）

2.服务消费者
2.1获取服务
eureka.client.fetch-registry=ture 是否检索注册中心的服务，获取服务则必须设置为true 默认为true
eureka.client.registry.fetch.interval.seconds=30 当启动服务消费者时，会发送一个rest请求给注册中心，来获取上面注册的服务清单；为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时缓存清单会每隔30秒更新一次

2.2服务调用
服务消费者获取服务清单后，通过服务名可以获取具体提供服务的实例名和该实例的元数据信息。有了这些元数据信息，客户端可以根据自己的需要决定具体调用哪个实例。对于访问实例的选择，Eureka中有Region和Zone两个概念，一个Region中可以包含多个Zone,每个服务客户端需要被注册到一个Zone钟，所以每个客户端对应一个Region和一个Zone。在进行服务调用时，优先访问同处一个Zone的服务提供方，若访问不到，再访问其他Zone的服务提供者。

3.服务注册中心
3.1服务同步
当两个服务提供者注册到注册中心集群，它们的信息被注册中心集群维护（此时注册中心之间互相注册为服务）当服务提供者发送服务注册请求到一个注册中心时，他会将该请求转发给集群中相连的其他注册中心，从而实现注册中心的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心的任意一台获取到。

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

3.3自我保护
服务注册到注册中心后，会维护一个心跳连接，告诉Eureka Server自己还活着。Eureka Server 在运行期间会统计心跳失败比例在15分钟内是是否低于85%，如果出现低于的情况（单机调试很容易满足，实际在生产环境中通常是由于网络不稳定导致的），会将当前的实例注册信息保护起来，让这些实例不过期，尽可能保护注册信息。而在这段保护期间内，实例若出现问题，那么客户端会拿到实际已经不存在的服务实例，会出现调用失败的情况，这时客户端就必须要有容错机制，比如请求重试，熔断器等
注：在单机调试时，服务注册中心信息面板经常会出现如下提示：

 

这就是由于触发了Eureka Server的自我保护机制
可以使用eureka.server.enable-self-preservation=false参数来关闭保护机制