二、注册中心选型

1. zk和eureka的区别

zk：CP设计(强一致性)，目标是一个分布式的协调系统，用于进行资源的统一管理。

当主节点crash后，需要进行leader的选举，在这个期间内，zk服务是不可用的（当然消费者可以缓存zk上注册的节点），并且在写数据时，同步到从节点阶段也是不可用的。

eureka：AP设计（高可用），目标是一个服务注册发现系统，专门用于微服务的服务发现注册。Eureka各个节点都是平等的，不是主从架构。几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。

而Eureka的客户端在向某个Eureka注册时如果发现连接失败，会自动切换至其他节点，只
要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的节点信息可能不是最新的（不保证强一致性）

同时当eureka的服务端发现85%以上的服务都没有心跳的话，它就会认为自己的网络出了问题，就不会从服务列表中删除这些失去心跳的服务，同时eureka的客户端也会缓存服务信息。eureka对于服务注册发现来说是非常好的选择。
 

2.为何企业级项目弃用eruke

1.Eureka 2.0宣布闭源

在选型微服务注册中心时，一定要长远考虑，SpringCloud提供了Eureka作为服务注册中心，我们可以开箱即用，但是，对于服务注册中心随着业务需求的不断变化，对服务注册中心提出了更高要求，如果不能同步跟上业务的脚步或者没有专业的维护团队，将会是很糟糕的。

看到“Eureka 2.0 开源工作宣告停止，继续使用风险自负”。

这意味着如果开发者继续使用作为 2.x 分支上现有工作 repo 一部分发布的代码库和工件，则将自负风险，对此，专家建议开发者尽快将相关业务迁移到 Consul/ZooKeeper/Etcd 等工具上。

所以Eureka就不太适合了，

2.已停止的微服务不注销或注销有延迟

 在使用Eureka Client时，可能会发现当微服务（Eureka Client）已经停止了，而注册中心仍然显示该服务处于正常状态，或者过段时间才会注销。然而，这种情况在实际应用中是大家不太希望看见的，希望一旦服务发生异常或宕机，注册中心应该理解体现出来。

     这是由于Eureka Server注销无效节点周期、自我保护模式的因素造成的，因此会出现服务不注销或注销有延迟。解决办法如下：

1.Eureka Server关闭自我保护模式机制
关闭自我保护模式，并配置注销无效节点周期时间间隔。

# 默认值为true。设为false, 关闭自我保护， 从而保证会注销微服务
eureka.server.enable-self-preservation=false# 清理间隔（单位毫秒，默认是60 * 1000）。根据需求将时间间隔设置短些，例如：设置1秒，一旦down掉，则会立即注销
eureka.server.eviction-interval-timer-in-ms=1000

参考： https://github.com/spring-cloud/spring-cloud-netflix/issues/1322

2.Eureka Client主动注销

当Client端开启健康检查时，可以适当的按需配置续约更新时间和到期时间。这样做只能在一定程度上缓解注销延迟的程度，但不能真正解决立即注销，可以在进行微服务(Eureka Client)异常或关机时，主动调用 Eureka Rest API来注销该服务，注销接口：http://localhost:8761/eureka/apps的DELETE 请求方式。

# 默认值为false。设为true，开启健康检查（需要spring-boot-starter-actuator 依赖）
eureka.client.healthcheck.enabled=true# 续约更新时间间隔（默认是30秒）
eureka.instance.lease-renewal-interval-in-seconds=?# 续约到期时间（默认90秒）
eureka.instance.lease-expiration-duration-in-seconds=?