我又当搬运工了，该博文为参考简书阿里云云栖号-主流微服务注册中心浅析和对比文章，小伙伴可直接去查看。

各类注册中心比较

注册中心比较.png

  由上图可见，每家开源的注册中心都有优缺点，所以在我们进行技术选型时得根据自己项目的业务来进行选择，不能说看现在什么注册中心用的人比较多就用它，我下面简单写了几条进行注册中心选择时可参考的条件。

注册中心选择参考条件

1.数据模型

  注册中心的核心数据是服务的名字和它对应的网络地址，当服务注册了多个实例时，我们需要对不健康的实例进行过滤或者针对实例的一些特征进行流量的分配，那么就需要在实例上存储一些例如健康状态、权重等属性。随着服务规模的扩大，渐渐的又需要在整个服务级别设定一些权限规则、以及对所有实例都生效的一些开关，于是在服务级别又会设立一些属性。再往后，我们又发现单个服务的实例又会有划分为多个子集的需求，例如一个服务是多机房部署的，那么可能需要对每个机房的实例做不同的配置，这样又需要在服务和实例之间再设定一个数据级别。
  Zookeeper没有针对服务发现设计数据模型，它的数据是以一种更加抽象的树形K-V组织的，因此理论上可以存储任何语义的数据。而Eureka或者Consul都是做到了实例级别的数据扩展，这可以满足大部分的场景，但是无法满足大规模和多环境的服务数据存储。Nacos的数据模型，则是一种服务-集群-实例的三层模型

2.数据一致性

  数据一致性是分布式系统永恒的话题。目前存在的两种一致性选型：目前来看基本可以归为两家：一种是基于Leader的非对等部署的单点写一致性，一种是对等部署的多写一致性。
  当我们选用服务注册中心的时候，并没有一种协议能够覆盖所有场景，例如当注册的服务节点不会定时发送心跳到注册中心时，强一致协议看起来是唯一的选择，因为无法通过心跳来进行数据的补偿注册，第一次注册就必须保证数据不会丢失。而当客户端会定时发送心跳来汇报健康状态时，第一次的注册的成功率并不是非常关键（当然也很关键，只是相对来说我们容忍数据的少量写失败），因为后续还可以通过心跳再把数据补偿上来，此时Paxos协议的单点瓶颈就会不太划算了，这也是Eureka为什么不采用Paxos协议而采用自定义的Renew机制的原因。

3.负载均衡

  负载均衡严格的来说，并不算是传统注册中心的功能。一般来说服务发现的完整流程应该是先从注册中心获取到服务的实例列表，然后再根据自身的需求，来选择其中的部分实例或者按照一定的流量分配机制来访问不同的服务提供者，因此注册中心本身一般不限定服务消费者的访问策略。Eureka、Zookeeper包括Consul，本身都没有去实现可配置及可扩展的负载均衡机制，Eureka的负载均衡是由ribbon来完成的，而Consul则是由Fabio做负载均衡。

4.健康检查

  Zookeeper和Eureka都实现了一种TTL的机制，就是如果客户端在一定时间内没有向注册中心发送心跳，则会将这个客户端摘除。

5.易用性

  易用性包括多方面的工作，例如API和客户端的接入是否简单，文档是否齐全易懂，控制台界面是否完善等。Zookeeper的易用性是比较差的，Zookeeper的客户端使用比较复杂，没有针对服务发现的模型设计以及相应的API封装，需要依赖方自己处理。对多语言的支持也不太好，同时没有比较好用的控制台进行运维管理。而Eureka和Nacos就拥有控制台可以查看实例信息，但是Eureka的控制台不支持服务的相关的管理操作。想要对实例进行操作得通过API调用Eureka Server接口

6.性能与容量

  虽然大部分用户用到的性能不高，但是他们仍然希望选用的产品的性能越高越好。影响读写性能的因素很多：一致性协议、机器的配置、集群的规模、存量数据的规模、数据结构及读写逻辑的设计等等。在服务发现的场景中，我们认为读写性能都是非常关键的，但是并非性能越高就越好，因为追求性能往往需要其他方面做出牺牲
  Zookeeper的容量，从存储节点数来说，可以达到百万级别。不过如上面所说，这并不代表容量的全部，当大量的实例上下线时，Zookeeper的表现并不稳定，同时在推送机制上的缺陷，会引起客户端的资源占用上升，从而性能急剧下降。
  Eureka在服务实例规模在5000左右的时候，就已经出现服务不可用的问题，甚至在压测的过程中，如果并发的线程数过高，就会造成Eureka crash。不过如果服务规模在1000上下，几乎目前所有的注册中心都可以满足。毕竟我们看到Eureka作为SpringCloud的注册中心，在国内也没有看到很广泛的对于容量或者性能的问题报告。
  Nacos在开源版本中，服务实例注册的支撑量约为100万，服务的数量可以达到10万以上