【微服务】Nacos 注册中心的设计原理
| 阿里云国内75折 回扣 微信号：monov8 |
| 阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6 |
目录
一、前言
服务发现是⼀个古老的话题当应用开始脱离单机运行和访问时服务发现就诞生了。目前的网络架构是每个主机都有⼀个独立的 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则携带着阿里巴巴大规模服务生产经验试图在服务注册和配置管理这个市场上提供给用户⼀个新的选择。
图 1 服务发现
开源产品的⼀个优势是开发人员可以去阅读源代码理解产品的功能设计和架构设计同时也可以通过本地部署来测试性能随之而来的是各种产品的对比文章。不过当前关于注册中心的对比往往停留在表面的功能对比上对架构或者性能并没有非常深入的探讨。
另⼀个现象是服务注册中心往往隐藏在服务框架背后作为默默支持的产品。优秀的服务框架往往会支持多种配置中心但是注册中心的选择依然强关联与服务框架⼀种普遍的情况是⼀种服务框架会带⼀个默认的服务注册中心。这样虽然免去了用户在选型上的烦恼但是单个注册中心的局限性导致用户使用多个服务框架时必须部署多套完全不同的注册中心这些注册中心之间的数据协同也是⼀个问题。
本文从各个角度深度介绍 Nacos 注册中心的设计原理并试图从我们的经验和调研中总结和阐述服务注册中心产品设计上应该去遵循和考虑的要点。
二、数据模型
注册中心的核心数据是服务的名字和它对应的网络地址当服务注册了多个实例时我们需要对不健康的实例进行过滤或者针对实例的⼀些特征进行流量的分配那么就需要在实例上存储⼀些例如健康状态、权重等属性。随着服务规模的扩大渐渐的又需要在整个服务级别设定⼀些权限规则、以及对所有实例都生效的⼀些开关于是在服务级别又会设立⼀些属性。再往后我们又发现单个服务的实例又会有划分为多个子集的需求例如⼀个服务是多机房部署的那么可能需要对每个机房的实例做不同的配置这样又需要在服务和实例之间再设定⼀个数据级别。
Zookeeper 没有针对服务发现设计数据模型它的数据是以⼀种更加抽象的树形 K-V 组织的因此理论上可以存储任何语义的数据。而 Eureka 或者 Consul 都是做到了实例级别的数据扩展这可以满足大部分的场景不过无法满足大规模和多环境的服务数据存储。Nacos 在经过内部多年生产经验后提炼出的数据模型则是⼀种服务-集群-实例的三层模型。如上文所说这样基本可以满足服务在所有场景下的数据存储和管理。
图 2 服务的分级模型
Nacos 的数据模型虽然相对复杂但是它并不强制你使用它里面的所有数据在大多数场景下你可以选择忽略这些数据属性此时可以降维成和 Eureka 和 Consul ⼀样的数据模型。
另外⼀个需要考虑的是数据的隔离模型作为⼀个共享服务型的组件需要能够在多个用户或者业务方使用的情况下保证数据的隔离和安全这在稍微大⼀点的业务场景中非常常见。另⼀方面服务注册中心往往会支持云上部署此时就要求服务注册中心的数据模型能够适配云上的通用模型。Zookeeper、Consul 和 Eureka 在开源层面都没有很明确的针对服务隔离的模型Nacos 则在⼀开始就考虑到如何让用户能够以多种维度进行数据隔离同时能够平滑的迁移到阿里云上对应的商业化产品。
图 3 服务的逻辑隔离模型
Nacos 提供了四层的数据逻辑隔离模型用户账号对应的可能是⼀个企业或者独立的个体这个数据⼀般情况下不会透传到服务注册中心。⼀个用户账号可以新建多个命名空间每个命名空间对应⼀个客户端实例这个命名空间对应的注册中心物理集群是可以根据规则进行路由的这样可以让注册中心内部的升级和迁移对用户是无感知的同时可以根据用户的级别为用户提供不同服务级别的物理集群。再往下是服务分组和服务名组成的二维服务标识可以满足接口级别的服务隔离。
Nacos 1.0.0 介绍的另外⼀个新特性是临时实例和持久化实例。在定义上区分临时实例和持久化实例的关键是健康检查的方式。临时实例使用客户端上报模式而持久化实例使用服务端反向探测模式。临时实例需要能够自动摘除不健康实例而且无需持久化存储实例那么这种实例就适用于类 Gossip 的协议。右边的持久化实例使用服务端探测的健康检查方式因为客户端不会上报心跳那么自然就不能去自动摘除下线的实例。
图 4 临时实例和持久化实例
在大中型的公司里这两种类型的服务往往都有。⼀些基础的组件例如数据库、缓存等这些往往不能上报心跳这种类型的服务在注册时就需要作为持久化实例注册。而上层的业务服务例如微服务或者 Dubbo 服务服务的 Provider 端支持添加汇报心跳的逻辑此时就可以使用动态服务的注册方式。
Nacos 2.0 中继续沿用了持久化及非持久化的设定但是有了⼀些调整。Nacos 1.0 中持久化及非持久化的属性是作为实例的⼀个元数据进行存储和识别。这导致同⼀个服务下可以同时存在持久化实例和非持久化实例。但是在实际使用中我们发现这种模式会给运维人员带来极大的困惑和运维复杂度与此同时从系统架构来看⼀个服务同时存在持久化及非持久化实例的场景也是存在⼀定矛盾的。这就导致该能力事实上并未被广泛使用。为了简化 Nacos 的服务数据模型降低运维人员的复杂度提升 Nacos 的易用性在 Nacos2.0 中将是否持久化的数据抽象至服务级别且不再允许⼀个服务同时存在持久化实例和非持久化实例实例的持久化属性继承自服务的持久化属性。
三、数据一致性
数据⼀致性是分布式系统永恒的话题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 重点是做了⼀些逻辑的优化和性能的调优。
图 5 Nacos ⼀致性协议
四、负载均衡
负载均衡严格的来说并不算是传统注册中心的功能。⼀般来说服务发现的完整流程应该是先从注册中心获取到服务的实例列表然后再根据自身的需求来选择其中的部分实例或者按照⼀定的流量分配机制来访问不同的服务提供者因此注册中心本身⼀般不限定服务消费者的访问策略。Eureka、Zookeeper 包括 Consul本身都没有去实现可配置及可扩展的负载均衡机制Eureka 的负载均衡是由 ribbon (最新的的SpringCloud官方自己单干)来完成的而 Consul 则是由 Fabio 做负载均衡。
图 6 客户端侧负载均衡
在阿里巴巴集团内部却是使用的相反的思路。服务消费者往往并不关心所访问的服务提供者的负载均衡它们只关心以最高效和正确的访问服务提供者的服务。而服务提供者则非常关注自身被访问的流量的调配这其中的第⼀个原因是阿里巴巴集团内部服务访问流量巨大稍有不慎就会导致流量异常压垮服务提供者的服务。因此服务提供者需要能够完全掌控服务的流量调配并可以动态调整。
服务端的负载均衡给服务提供者更强的流量控制权但是无法满足不同的消费者希望使用不同负载均衡策略的需求。而不同负载均衡策略的场景确实是存在的。而客户端的负载均衡则提供了这种灵活性并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当可能会导致服务提供者出现热点或者压根就拿不到任何服务提供者。
图 7 服务端侧负载均衡
抛开负载均衡到底是在服务提供者实现还是在服务消费者实现我们看到目前的负载均衡有基于权重、服务提供者负载、响应时间、标签等策略。其中 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 是不⼀样的。同时服务端健康检查无法摘除不健康实例这意味着只要注册过的服务实例如果不调用接口主动注销这些服务实例都需要去维持健康检查的探测任务而客户端则可以随时摘除不健康实例减轻服务端的压力。
图 8 Nacos 的健康检查
Nacos 既支持客户端的健康检查也支持服务端的健康检查同⼀个服务可以切换健康检查模式。我们认为这种健康检查方式的多样性非常重要这样可以支持各种类型的服务让这些服务都可以使用到 Nacos 的负载均衡能力。Nacos 下⼀步要做的是实现健康检查方式的用户扩展机制不管是服务端探测还是客户端探测。这样可以支持用户传入⼀条业务语义的请求然后由 Nacos 去执行做到健康检查的定制。
六、性能与容量
Zookeeper 精巧的设计不过这显然是因为有⼀系列的前提存在。首先 Zookeeper 的写逻辑就是进行 K-V 的写入内部没有聚合其次 Zookeeper 舍弃了服务发现的基本功能如健康检查、友好的查询接口它在支持这些功能的时候显然需要增加⼀些逻辑甚至弃用现有的数据结构最后Paxos 协议本身就限制了 Zookeeper 集群的规模3、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 版本进行压力测试后的结果总结针对容量、并发、扩展性和延时等进行了测试和统计。
图 9 Nacos 性能与容量报告
七、易用性
易用性也是用户比较关注的⼀块内容。产品虽然可以在功能特性或者性能上做到非常先进但是如果用户的使用成本极高也会让用户望而却步。易用性包括多方面的工作例如 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 集群在扩容之后性能上有很大问题。
集群扩展性的另⼀个方面是多地域部署和容灾的支持。当讲究集群的高可用和稳定性以及网络上的跨地域延迟要求能够在每个地域都部署集群的时候我们现有的方案有多机房容灾、异地多活、多数据中心等。
图 8 Nacos 的多机房部署和容灾
首先是双机房容灾基于 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 之间的数据同步。图 9 Nacos 的多数据中心方案
九、用户扩展性
在框架的设计中扩展性是⼀个重要的设计原则。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 的⼀些特色功能并没有在文中涉及这些特色功能其实也是 Nacos 区别与其他注册中心的重要方面包括 Nacos 支持的 DNS 协议打自定义标等能力。稍微熟悉 Nacos 的读者可能会注意到Nacos 的整体架构和 Consul 有⼀些类似但是事实上 Nacos 和 Consul 除了都是把配置管理和服务发现部署在⼀起其他地方基本上没有相似的地方我们将会在另外⼀篇文章中专门介绍与 Consul 的差异。Nacos 的架构和功能是由阿里巴巴内部十年的运行演进经验得来所以二者的比较也⼀定会让大家更加了解他们的定位和演进方向是完全不⼀样的。
Nacos 2.0 发布了 GA 版本后续将会以和社区共建的方式持续输出新的功能在服务发现和配置管理这两大领域继续深耕期待与大家⼀起建设出最好用的服务发现和配置管理平台。
💖 Spring家族及微服务系列文章
✨【微服务】SpringCloud中OpenFeign请求处理及负载均衡流程
✨【微服务】SpringCloud中Ribbon的WeightedResponseTimeRule策略
✨【微服务】SpringCloud中Ribbon的轮询(RoundRobinRule)与重试(RetryRule)策略
✨【微服务】SpringCloud中Ribbon集成Eureka实现负载均衡
✨【微服务】SpringCloud轮询拉取注册表及服务发现源码解析
✨【微服务】SpringBoot监听器机制以及在Nacos中的应用
✨【微服务】SpringCloud中使用Ribbon实现负载均衡的原理
✨【微服务】SpringBoot启动流程注册FeignClient