主流微服务注册中心浅析和对比

开源产品受开发者热捧，是由于其代码透明、能够参与共建、有社区进行交流和学习，固然更重要的是开源产品的接入成本低。我的开发者或者中小型公司每每会将开源产品做为选型首选。

开发者经过阅读源代码，理解产品的功能设计和架构设计，同时也能够经过本地部署来测试性能，随之而来的是对各种开源产品的对比，用以选型。不过当前关于微服务注册中心的对比，大多聚焦在功能上的对比，对架构或者性能的深刻探讨，比较少见。

另外一方面，做为默默支持的产品，服务注册中心每每隐藏在服务框架背后。优秀的服务框架每每会支持多种配置中心，可是注册中心的选择依然与服务框架强关联，广泛的状况是一种服务框架会带一个默认的服务注册中心。这样虽然免去了用户在选型上的烦恼，可是单个注册中心的局限性，致使用户使用多个服务框架时，必须部署多套彻底不一样的注册中心，这些注册中心之间的数据协同是一个问题。

本文来自Nacos社区，做者是 Nacos PMC 朱鹏飞，做者力求公正和客观的去看待主流微服务注册中心的各个维度。本文不只仅包含常见服务注册中心产品的对比，也试图从Nacos的经验和调研中总结并阐述服务注册中心产品设计上应该去遵循和考虑的要点，文章篇幅较长，若您有不一样的见解，欢迎在文末留言，或到Nacos @GitHub 提issue。

前言

服务发现是一个古老的话题，当应用开始脱离单机运行和访问时，服务发现就诞生了。目前的网络架构是每一个主机都有一个独立的IP地址，那么服务发现基本上都是经过某种方式获取到服务所部署的IP地址。DNS协议是最先将一个网络名称翻译为网络IP的协议，在最初的架构选型中，DNS+LVS+Nginx基本能够知足全部的RESTful服务的发现，此时服务的IP列表一般配置在Nginx或者LVS。后来出现了RPC服务，服务的上下线更加频繁，人们开始寻求一种可以支持动态上下线而且推送IP列表变化的注册中心产品。

ZooKeeper是一款经典的服务注册中心产品（虽然它最初的定位并不在于此），在很长一段时间里，它是国人在提起RPC服务注册中心时内心想到的惟一选择，这很大程度上与Dubbo在中国的普及程度有关。Consul和Eureka都出现于2014年，Consul在设计上把不少分布式服务治理上要用到的功能都包含在内，能够支持服务注册、健康检查、配置管理、Service Mesh等。而Eureka则借着微服务概念的流行，与SpringCloud生态的深度结合，也获取了大量的用户。去年开源的Nacos，则携带着阿里巴巴大规模服务生产经验，试图在服务注册和配置管理这个市场上，提供给用户一个新的选择。

当市面上有多种类似功能的产品出现时，人们每每但愿知道这些产品相比较的优劣。产品自己的定位会决定它包含了哪些功能，而产品架构的设计，则会影响产品的性能和可用性等。开源产品的一个优点是开发人员能够去阅读源代码，理解产品的功能设计和架构设计，同时也能够经过本地部署来测试性能，随之而来的是各类产品的对比文章。不过当前关于注册中心的对比，每每停留在表面的功能对比上，对架构或者性能并无很是深刻的探讨。

另外一个现象是服务注册中心每每隐藏在服务框架背后，做为默默支持的产品。优秀的服务框架每每会支持多种配置中心，可是注册中心的选择依然强关联与服务框架，一种广泛的状况是一种服务框架会带一个默认的服务注册中心。这样虽然免去了用户在选型上的烦恼，可是单个注册中心的局限性，致使用户使用多个服务框架时，必须部署多套彻底不一样的注册中心，这些注册中心之间的数据协同也是一个问题。

本文是一篇来自Nacos项目组的文章，虽然是来自Nacos，咱们依然力求公正和客观的去看待服务发现全部产品的各个维度。本文不只仅包含常见服务注册中心产品的对比，还试图从咱们的经验和调研中总结和阐述服务注册中心产品设计上应该去遵循和考虑的要点。

数据模型

注册中心的核心数据是服务的名字和它对应的网络地址，当服务注册了多个实例时，咱们须要对不健康的实例进行过滤或者针对实例的一些特征进行流量的分配，那么就须要在实例上存储一些例如健康状态、权重等属性。随着服务规模的扩大，渐渐的又须要在整个服务级别设定一些权限规则、以及对全部实例都生效的一些开关，因而在服务级别又会设立一些属性。再日后，咱们又发现单个服务的实例又会有划分为多个子集的需求，例如一个服务是多机房部署的，那么可能须要对每一个机房的实例作不一样的配置，这样又须要在服务和实例之间再设定一个数据级别。

Zookeeper没有针对服务发现设计数据模型，它的数据是以一种更加抽象的树形K-V组织的，所以理论上能够存储任何语义的数据。而Eureka或者Consul都是作到了实例级别的数据扩展，这能够知足大部分的场景，不过没法知足大规模和多环境的服务数据存储。Nacos在通过内部多年生产经验后提炼出的数据模型，则是一种服务-集群-实例的三层模型。如上文所说，这样基本能够知足服务在全部场景下的数据存储和管理。

Nacos的数据模型虽然相对复杂，可是它并不强制你使用它里面的全部数据，在大多数场景下，你能够选择忽略这些数据属性，此时能够降维成和Eureka和Consul同样的数据模型。

另一个须要考虑的是数据的隔离模型，做为一个共享服务型的组件，须要可以在多个用户或者业务方使用的状况下，保证数据的隔离和安全，这在稍微大一点的业务场景中很是常见。另外一方面服务注册中心每每会支持云上部署，此时就要求服务注册中心的数据模型可以适配云上的通用模型。Zookeeper、Consul和Eureka在开源层面都没有很明确的针对服务隔离的模型，Nacos则在一开始就考虑到如何让用户可以以多种维度进行数据隔离，同时可以平滑的迁移到阿里云上对应的商业化产品。

Nacos提供了四层的数据逻辑隔离模型，用户帐号对应的多是一个企业或者独立的个体，这个数据通常状况下不会透传到服务注册中心。一个用户帐号能够新建多个命名空间，每一个命名空间对应一个客户端实例，这个命名空间对应的注册中心物理集群是能够根据规则进行路由的，这样可让注册中心内部的升级和迁移对用户是无感知的，同时能够根据用户的级别，为用户提供不一样服务级别的物理集群。再往下是服务分组和服务名组成的二维服务标识，能够知足接口级别的服务隔离。

Nacos 1.0.0介绍的另一个新特性是：临时实例和持久化实例。在定义上区分临时实例和持久化实例的关键是健康检查的方式。临时实例使用客户端上报模式，而持久化实例使用服务端反向探测模式。临时实例须要可以自动摘除不健康实例，并且无需持久化存储实例，那么这种实例就适用于类Gossip的协议。右边的持久化实例使用服务端探测的健康检查方式，由于客户端不会上报心跳，那么天然就不能去自动摘除下线的实例。

在大中型的公司里，这两种类型的服务每每都有。一些基础的组件例如数据库、缓存等，这些每每不能上报心跳，这种类型的服务在注册时，就须要做为持久化实例注册。而上层的业务服务，例如微服务或者Dubbo服务，服务的Provider端支持添加汇报心跳的逻辑，此时就可使用动态服务的注册方式。

数据一致性

数据一致性是分布式系统永恒的话题，Paxos协议的艰深更让数据一致性成为程序员大牛们吹水的常见话题。不过从协议层面上看，一致性的选型已经很长时间没有新的成员加入了。目前来看基本能够归为两家：一种是基于Leader的非对等部署的单点写一致性，一种是对等部署的多写一致性。当咱们选用服务注册中心的时候，并无一种协议可以覆盖全部场景，例如当注册的服务节点不会定时发送心跳到注册中心时，强一致协议看起来是惟一的选择，由于没法经过心跳来进行数据的补偿注册，第一次注册就必须保证数据不会丢失。而当客户端会定时发送心跳来汇报健康状态时，第一次的注册的成功率并非很是关键（固然也很关键，只是相对来讲咱们容忍数据的少许写失败），由于后续还能够经过心跳再把数据补偿上来，此时Paxos协议的单点瓶颈就会不太划算了，这也是Eureka为何不采用Paxos协议而采用自定义的Renew机制的缘由。

这两种数据一致性协议有各自的使用场景，对服务注册的需求不一样，就会致使使用不一样的协议。在这里能够发现，Zookeeper在Dubbo体系下表现出的行为，其实采用Eureka的Renew机制更加合适，由于Dubbo服务往Zookeeper注册的就是临时节点，须要定时发心跳到Zookeeper来续约节点，并容许服务下线时，将Zookeeper上相应的节点摘除。Zookeeper使用ZAB协议虽然保证了数据的强一致，可是它的机房容灾能力的缺少，没法适应一些大型场景。

Nacos由于要支持多种服务类型的注册，并可以具备机房容灾、集群扩展等必不可少的能力，在1.0.0正式支持AP和CP两种一致性协议并存。1.0.0重构了数据的读写和同步逻辑，将与业务相关的CRUD与底层的一致性同步逻辑进行了分层隔离。而后将业务的读写（主要是写，由于读会直接使用业务层的缓存）抽象为Nacos定义的数据类型，调用一致性服务进行数据同步。在决定使用CP仍是AP一致性时，使用一个代理，经过可控制的规则进行转发。

目前的一致性协议实现，一个是基于简化的Raft的CP一致性，一个是基于自研协议Distro的AP一致性。Raft协议没必要多言，基于Leader进行写入，其CP也并非严格的，只是能保证一半所见一致，以及数据的丢失几率较小。Distro协议则是参考了内部ConfigServer和开源Eureka，在不借助第三方存储的状况下，实现基本大同小异。Distro重点是作了一些逻辑的优化和性能的调优。

负载均衡

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

在阿里巴巴集团内部，倒是使用的相反的思路。服务消费者每每并不关心所访问的服务提供者的负载均衡，它们只关心以最高效和正确的访问服务提供者的服务。而服务提供者，则很是关注自身被访问的流量的调配，这其中的第一个缘由是，阿里巴巴集团内部服务访问流量巨大，稍有不慎就会致使流量异常压垮服务提供者的服务。所以服务提供者须要可以彻底掌控服务的流量调配，并能够动态调整。

服务端的负载均衡，给服务提供者更强的流量控制权，可是没法知足不一样的消费者但愿使用不一样负载均衡策略的需求。而不一样负载均衡策略的场景，确实是存在的。而客户端的负载均衡则提供了这种灵活性，并对用户扩展提供更加友好的支持。可是客户端负载均衡策略若是配置不当，可能会致使服务提供者出现热点，或者压根就拿不到任何服务提供者。

抛开负载均衡究竟是在服务提供者实现仍是在服务消费者实现，咱们看到目前的负载均衡有基于权重、服务提供者负载、响应时间、标签等策略。其中Ribbon设计的客户端负载均衡机制，主要是选择合适现有的IRule、ServerListFilter等接口实现，或者本身继承这些接口，实现本身的过滤逻辑。这里Ribbon采用的是两步负载均衡，第一步是先过滤掉不会采用的服务提供者实例，第二步是在过滤后的服务提供者实例里，实施负载均衡策略。Ribbon内置的几种负载均衡策略功能仍是比较强大的，同时又由于容许用户去扩展，这能够说是一种比较好的设计。

基于标签的负载均衡策略能够作到很是灵活，Kubernetes和Fabio都已经将标签运用到了对资源的过滤中，使用标签几乎能够实现任意比例和权重的服务流量调配。可是标签自己须要单独的存储以及读写功能，无论是放在注册中心自己或者对接第三方的CMDB。

在Nacos 0.7.0版本中，咱们除了提供基于健康检查和权重的负载均衡方式外，还新提供了基于第三方CMDB的标签负载均衡器，具体能够参考CMDB功能介绍文章。使用基于标签的负载均衡器，目前能够实现同标签优先访问的流量调度策略，实际的应用场景中，能够用来实现服务的就近访问，当您的服务部署在多个地域时，这很是有用。使用这个标签负载均衡器，能够支持很是多的场景，这不是本文要详细介绍的。虽然目前Nacos里支持的标签表达式并不丰富，不过咱们会逐步扩展它支持的语法。除此之外，Nacos定义了Selector，做为负载均衡的统一抽象。关于Selector，因为篇幅关系，咱们会有单独的文章进行介绍。

理想的负载均衡实现应该是什么样的呢？不一样的人会有不一样的答案。Nacos试图作的是将服务端负载均衡与客户端负载均衡经过某种机制结合起来，提供用户扩展性，并给予用户充分的自主选择权和轻便的使用方式。负载均衡是一个很大的话题，当咱们在关注注册中心提供的负载均衡策略时，须要注意该注册中心是否有我须要的负载均衡方式，使用方式是否复杂。若是没有，那么是否容许我方便的扩展来实现我需求的负载均衡策略。

健康检查

Zookeeper和Eureka都实现了一种TTL的机制，就是若是客户端在必定时间内没有向注册中心发送心跳，则会将这个客户端摘除。Eureka作的更好的一点在于它容许在注册服务的时候，自定义检查自身状态的健康检查方法。这在服务实例可以保持心跳上报的场景下，是一种比较好的体验，在Dubbo和SpringCloud这两大致系内，也被培养成用户心智上的默认行为。Nacos也支持这种TTL机制，不过这与ConfigServer在阿里巴巴内部的机制又有一些区别。Nacos目前支持临时实例使用心跳上报方式维持活性，发送心跳的周期默认是5秒，Nacos服务端会在15秒没收到心跳后将实例设置为不健康，在30秒没收到心跳时将这个临时实例摘除。

不过正如前文所说，有一些服务没法上报心跳，可是能够提供一个检测接口，由外部去探测。这样的服务也是普遍存在的，并且以咱们的经验，这些服务对服务发现和负载均衡的需求一样强烈。服务端健康检查最多见的方式是TCP端口探测和HTTP接口返回码探测，这两种探测方式由于其协议的通用性能够支持绝大多数的健康检查场景。在其余一些特殊的场景中，可能还须要执行特殊的接口才能判断服务是否可用。例如部署了数据库的主备，数据库的主备可能会在某些状况下切换，须要经过服务名对外提供访问，保证当前访问的库是主库。此时的健康检查接口，可能就是一个检查数据库是不是主库的MYSQL命令了。

客户端健康检查和服务端健康检查有一些不一样的关注点。客户端健康检查主要关注客户端上报心跳的方式、服务端摘除不健康客户端的机制。而服务端健康检查，则关注探测客户端的方式、灵敏度及设置客户端健康状态的机制。从实现复杂性来讲，服务端探测确定是要更加复杂的，由于须要服务端根据注册服务配置的健康检查方式，去执行相应的接口，判断相应的返回结果，并作好重试机制和线程池的管理。这与客户端探测，只须要等待心跳，而后刷新TTL是不同的。同时服务端健康检查没法摘除不健康实例，这意味着只要注册过的服务实例，若是不调用接口主动注销，这些服务实例都须要去维持健康检查的探测任务，而客户端则能够随时摘除不健康实例，减轻服务端的压力。

Nacos既支持客户端的健康检查，也支持服务端的健康检查，同一个服务能够切换健康检查模式。咱们认为这种健康检查方式的多样性很是重要，这样能够支持各类类型的服务，让这些服务均可以使用到Nacos的负载均衡能力。Nacos下一步要作的是实现健康检查方式的用户扩展机制，无论是服务端探测仍是客户端探测。这样能够支持用户传入一条业务语义的请求，而后由Nacos去执行，作到健康检查的定制。

性能与容量

虽然大部分用户用到的性能不高，可是他们仍然但愿选用的产品的性能越高越好。影响读写性能的因素不少：一致性协议、机器的配置、集群的规模、存量数据的规模、数据结构及读写逻辑的设计等等。在服务发现的场景中，咱们认为读写性能都是很是关键的，可是并不是性能越高就越好，由于追求性能每每须要其余方面作出牺牲。Zookeeper在写性能上彷佛能达到上万的TPS，这得益于Zookeeper精巧的设计，不过这显然是由于有一系列的前提存在。首先Zookeeper的写逻辑就是进行K-V的写入，内部没有聚合；其次Zookeeper舍弃了服务发现的基本功能如健康检查、友好的查询接口，它在支持这些功能的时候，显然须要增长一些逻辑，甚至弃用现有的数据结构；最后，Paxos协议自己就限制了Zookeeper集群的规模，三、5个节点是不能应对大规模的服务订阅和查询的。

在对容量的评估时，不只要针对企业现有的服务规模进行评估，也要对将来3到5年的扩展规模进行预测。阿里巴巴的中间件在内部支撑着集团百万级别服务实例，在容量上遇到的挑战能够说不会小于任何互联网公司。这个容量不只仅意味着总体注册的实例数，也同时包含单个服务的实例数、总体的订阅者的数目以及查询的QPS等。Nacos在内部淘汰Zookeeper和Eureka的过程当中，容量是一个很是重要的因素。

Zookeeper的容量，从存储节点数来讲，能够达到百万级别。不过如上面所说，这并不表明容量的所有，当大量的实例上下线时，Zookeeper的表现并不稳定，同时在推送机制上的缺陷，会引发客户端的资源占用上升，从而性能急剧降低。

Eureka在服务实例规模在5000左右的时候，就已经出现服务不可用的问题，甚至在压测的过程当中，若是并发的线程数太高，就会形成Eureka crash。不过若是服务规模在1000上下，几乎目前全部的注册中心均可以知足。毕竟咱们看到Eureka做为SpringCloud的注册中心，在国内也没有看到很普遍的对于容量或者性能的问题报告。

Nacos在开源版本中，服务实例注册的支撑量约为100万，服务的数量能够达到10万以上。在实际的部署环境中，这个数字还会由于机器、网络的配置与JVM参数的不一样，可能会有所差异。图9展现了Nacos在使用1.0.0版本进行压力测试后的结果总结，针对容量、并发、扩展性和延时等进行了测试和统计。

完整的测试报告能够参考Nacos官网:
https://nacos.io/en-us/docs/nacos-naming-benchmark.html
https://nacos.io/en-us/docs/nacos-config-benchmark.html

易用性

易用性也是用户比较关注的一块内容。产品虽然能够在功能特性或者性能上作到很是先进，可是若是用户的使用成本极高，也会让用户望而却步。易用性包括多方面的工做，例如API和客户端的接入是否简单，文档是否齐全易懂，控制台界面是否完善等。对于开源产品来讲，还有一块是社区是否活跃。在比较Nacos、Eureka和Zookeeper在易用性上的表现时，咱们诚邀社区的用户进行全方位的反馈，由于毕竟在阿里巴巴集团内部，咱们对Eureka、Zookeeper的使用场景是有限的。从咱们使用的经验和调研来看，Zookeeper的易用性是比较差的，Zookeeper的客户端使用比较复杂，没有针对服务发现的模型设计以及相应的API封装，须要依赖方本身处理。对多语言的支持也不太好，同时没有比较好用的控制台进行运维管理。

Eureka和Nacos相比较Zookeeper而言，已经改善不少，这两个产品有针对服务注册与发现的客户端，也有基于SpringCloud体系的starter，帮助用户以很是低的成本无感知的作到服务注册与发现。同时还暴露标准的HTTP接口，支持多语言和跨平台访问。Eureka和Nacos都提供官方的控制台来查询服务注册状况。不过随着Eureka 2.0宣布中止开发，Eureka在针对用户使用上的优化后续应该不会再有比较大的投入，而Nacos目前依然在建设中，除了目前支持的易用性特性之外，后续还会继续加强控制台的能力，增长控制台登陆和权限的管控，监控体系和Metrics的暴露，持续经过官网等渠道完善使用文档，多语言SDK的开发等。

从社区活跃度的角度来看，目前因为Zookeeper和Eureka的存量用户较多，不少教程以及问题排查均可以在社区搜索到，这方面新开源的Nacos还须要随着时间继续沉淀。

集群扩展性

集群扩展性和集群容量以及读写性能关系紧密。当使用一个比较小的集群规模就能够支撑远高于现有数量的服务注册及访问时，集群的扩展能力暂时就不会那么重要。从协议的层面上来讲，Zookeeper使用的ZAB协议，因为是单点写，在集群扩展性上不具有优点。Eureka在协议上来讲理论上能够扩展到很大规模，由于都是点对点的数据同步，可是从咱们对Eureka的运维经验来看，Eureka集群在扩容以后，性能上有很大问题。

集群扩展性的另外一个方面是多地域部署和容灾的支持。当讲究集群的高可用和稳定性以及网络上的跨地域延迟要求可以在每一个地域都部署集群的时候，咱们现有的方案有多机房容灾、异地多活、多数据中心等。

首先是双机房容灾，基于Leader写的协议不作改造是没法支持的，这意味着Zookeeper不能在没有人工干预的状况下作到双机房容灾。在单机房断网状况下，使机房内服务可用并不难，难的是如何在断网恢复后作数据聚合，Zookeeper的单点写模式就会有断网恢复后的数据对帐问题。Eureka的部署模式自然支持多机房容灾，由于Eureka采用的是纯临时实例的注册模式：不持久化、全部数据均可以经过客户端心跳上报进行补偿。上面说到，临时实例和持久化实例都有它的应用场景，为了可以兼容这两种场景，Nacos支持两种模式的部署，一种是和Eureka同样的AP协议的部署，这种模式只支持临时实例，能够完美替代当前的Zookeeper、Eureka，并支持机房容灾。另外一种是支持持久化实例的CP模式，这种状况下不支持双机房容灾。

在谈到异地多活时，很巧的是，不少业务组件的异地多活正是依靠服务注册中心和配置中心来实现的，这其中包含流量的调度和集群的访问规则的修改等。机房容灾是异地多活的一部分，可是要让业务可以在访问服务注册中心时，动态调整访问的集群节点，这须要第三方的组件来作路由。异地多活每每是一个包含全部产品线的整体方案，很难说单个产品是否支持异地多活。

多数据中心其实也算是异地多活的一部分。从单个产品的维度上，Zookeeper和Eureka没有给出官方的多数据中心方案。Nacos基于阿里巴巴内部的使用经验，提供的解决方案是才有Nacos-Sync组件来作数据中心之间的数据同步，这意味着每一个数据中心的Nacos集群都会有多个数据中心的全量数据。Nacos-Sync是Nacos生态组件里的重要一环，不只会承担Nacos集群与Nacos集群之间的数据同步，也会承担Nacos集群与Eureka、Zookeeper、Kubernetes及Consul之间的数据同步。

用户扩展性

在框架的设计中，扩展性是一个重要的设计原则。Spring、Dubbo、Ribbon等框架都在用户扩展性上作了比较好的设计。这些框架的扩展性每每由面向接口及动态类加载等技术，来运行用户扩展约定的接口，实现用户自定义的逻辑。在Server的设计中，用户扩展是比较审慎的。由于用户扩展代码的引入，可能会影响原有Server服务的可用性，同时若是出问题，排查的难度也是比较大的。设计良好的SPI是可能的，可是由此带来的稳定性和运维的风险是须要仔细考虑的。在开源软件中，每每经过直接贡献代码的方式来实现用户扩展，好的扩展会被不少人不停的更新和维护，这也是一种比较好的开发模式。Zookeeper和Eureka目前Server端都不支持用户扩展，一个支持用户扩展的服务发现产品是CoreDNS。CoreDNS总体架构就是经过插件来串联起来的，经过将插件代码以约定的方式放到CoreDNS工程下，从新构建就能够将插件添加到CoreDNS总体功能链路的一环中。

那么这样的扩展性是不是有必要的呢？举一个上文提到过的例子，假如要添加一种新的健康检查方式，链接数据库执行一条MySQL命令，一般的方式是在代码里增长MySQL类型的健康检查方法、构建、测试而后最终发布。可是若是容许用户上传一个jar包放到Server部署目录下的某个位置，Server就会自动扫描并识别到这张新的健康检查方式呢？这样不只更酷，也让整个扩展的流程与Server的代码解耦，变得很是简单。因此对于系统的一些功能，若是可以经过精心的设计开放给用户在运行时去扩展，那么为何不作呢？毕竟增长扩展的支持并不会让原有的功能有任何损失。

全部产品都应该尽可能支持用户运行时扩展，这须要Server端SPI机制设计的足够健壮和容错。Nacos在这方面已经开放了对第三方CMDB的扩展支持，后续很快会开放健康检查及负载均衡等核心功能的用户扩展。目的就是为了可以以一种解耦的方式支持用户各类各样的需求。

尾声

本文并无把完整介绍Nacos的全部功能，包括Nacos支持的DNS协议，打自定义标等能力。Consul也并无在本文作重点比较，由于Consul其实是和Nacos比较类似的产品，虽然Consul目前的主要发展方向放在了Service Mesh，可是Consul最初支持的服务发现和配置管理，也是Nacos的两大功能。与Consul的详细比较将会经过另一篇文章单独介绍，虽然Nacos在Consul以后以与之类似的部署架构开源，但这并不意味着Nacos在功能和架构上也模仿Consul，Nacos的架构和功能是由阿里巴巴内部十年的运行演进经验得来，因此两者的比较也必定会让你们更加了解他们的定位和演进方向是彻底不同的。

为了能让你们对注册中心产品总体的差别有一个快速的总览，咱们制做了下面这个表格：

Nacos已经在4月10号发布GA版本，后续将会以和社区共建的方式，持续输出新的功能，在服务发现和配置管理这两大领域继续深耕，期待与你们一块儿建设出最好用的服务发现和配置管理平台。

本文做者：朱鹏飞，Github ID: nkorange，Nacos PMC，Nacos 注册中心等模块主要贡献者，阿里巴巴中间件高级开发工程师。

---

本文做者：中间件小哥

阅读原文

本文为云栖社区原创内容，未经容许不得转载。