本文基于Spring Cloud Edgware.SR6版本，从功能和架构上解析Eureka，让大家对Eureka有一个较为清晰的认识（本文默认大家对分布式微服务有一个初步的概念和理解，本文不涉及或少量涉及源码）。
官方概念这里就不贴了，个人理解，Eureka是Spring Cloud分布式微服务架构的服务治理方案之一，提供服务注册，服务发现，服务维护和治理，注册中心集群等功能。
Eureka中维护一份服务列表，当客户端（服务提供者或服务消费者）注册服务实例到Eureka，Eureka会将其实例信息维护到列表中，这叫创建租约；租约的有效时间默认是30秒，客户端需要每隔一段时间发送一次心跳告知Eureka自己的服务正常有效，这叫续约。
Eureka是服务注册中心，但当注册中心集群时，Eureka也做为客户端，向其它注册中心注册自己，同时获取其它注册中心的维护的服务列表，当有新的客户端注册进来时，Eureka会通知其它的注册中心，异步更新服务列表，达到高可用的目的。Eureka默认会开启如下配置，如果作为单个注册中心或本地测试，可以关闭。
eureka:
client:
# 不向Eureka注册自己
registerWithEureka: false
# 不获取服务列表
fetchRegistry: false
客户端正常下线时，会通知Eureka，Eureka就从服务列表中将其剔除。如果客户端非正常下线（比如宕机，系统崩溃）无法通知到Eureka，Eureka会定时检查自己的服务列表，发现有服务的租约超过有效时间，也会认为服务失效而剔除。
Eureka默认配置会开启一个保护机制，当一段时间内有超过15%的服务失效时，Eureka不会剔除这些服务，而是继续维护在服务列表，直到客户端重新发送心跳。Eureka有一个心跳次数阀值系数=0.85（可以通过配置修改），客户端默认心跳间隔=30秒，1分钟内总心跳数=客户端实例数*2，1分钟内心跳阀值=1分钟内总心跳数*0.85，当1分钟内有效客户端实例的心跳总数<心跳阀值，Eureka就会因为保护机制而继续维护在服务列表，因此客户端需要有重试和熔断机制。
Eureka和ZooKeeper
Eureka和ZooKeeper，虽然都是服务集群治理的实现方案，但是区别也是比较明显的。CAP理论中，C(consistency)数据一致性，A(availability)可用性，P(partition-tolerance)分区容错性，Eureka强调AP，通过缓存和异步同步达到最终一致性，ZooKeeper更兼顾CP，当节点失效就会剔除。
个人更倾向Eureka，不管是服务注册和发现，还是注册中心集群，只需要引入依赖包，添加配置和注解，就可以达到效果，同时不得不佩服Spring Boot和Spring Cloud的强大。但是，如果是ZooKeeper转使用Eureka，可能会因为其内部的缓存和保护机制感到别扭，此处贴上本人的配置，可以减少缓存时效，提高缓存刷新频率，强制关闭客户端的话，大概30秒Eureka就会剔除服务（Eureka默认情况下大概要4分钟才会剔除服务），供大家参考
Eureka注册中心配置（YML）
eureka:
server:
# 检查失效服务剔除时间间隔
evictionIntervalTimerInMs: 2000
# 关闭保护机制
enableSelfPreservation: false
Eureka客户端（properties）
#服务实例租约有效时间 eureka.instance.lease-expiration-duration-in-seconds=15 #服务实例续约间隔时间（心跳间隔） eureka.instance.lease-renewal-interval-in-seconds=5 #客户端更新服务列表间隔时间 eureka.client.registryFetchIntervalSeconds=5