ZooKeeper、Eureka、Consul 、Nacos，微服务注册中心怎么选？(1)

• 负载均衡：当存在多个服务提供者时，如何均衡各个提供者的负载？

• 集成：在服务提供端或者调用端，如何集成注册中心？

• 运行时依赖：引入注册中心之后，对应用的运行时环境有何影响？

• 可用性：如何保证注册中心本身的可用性，特别是消除单点故障？

主流注册中心产品

========

软件产品特性并非一成不变，如果发现功能特性有变更，欢迎评论指正

• Consul是支持自动注销服务实例， 请见文档：https://www.consul.io/api-docs/agent/service，在check的 DeregisterCriticalServiceAfter 这个参数-- 感谢@超帅的菜鸟博主提供最新信息

• 新版本的Dubbo也扩展了对 Consul 的支持。参考: https://github.com/apache/dubbo/tree/master/dubbo-registry

Apache Zookeeper -> CP

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。

从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。

但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。

因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能