Nacos 2.0 正式发布| 性能测试报告已出，请注意查收

Nacos 项目从 2008 年开始，开始在阿里巴巴内部孵化。近年来受 Eureka、Consul 等项目的影响，Nacos 越来越受欢迎。

目前 Nacos 支持主流微服务开发语言&主流服务框架和配置管理框架，比如支持 Duboo、SpringCloud、SCA，还对接了一些云原生的组件如 coreDNS。

客户端语言方面目前支持 Java/go/python 等主流语言，最近刚发布的正式版本还支持 C# 和 C++。

最近 Nacos 大动作频出，Nacos 2.X 版本迎来了首秀，在 1.X 的架构基础上新增了对长连接模型的支持。通信层目前通过 grpc 实现了长连接 RPC 调用和推送能力，使用长链接大幅度减少了 1.x 轮询心跳频繁导致 JVM Full GC。

上一篇文章《支持 gRPC 长链接，深度解读 Nacos 2.0 架构设计及新模型》，已经详细介绍了长连接模型带来的优势，但并没有详细给出压测数据，这一篇文章会详细介绍各个场景下，Nacos 2.0 的性能优势。

由于 Nacos 由服务发现和配置管理两大模块构成，业务模型略有差异，下面是一组具体压测指标。

Nacos2.0 服务发现的性能提升

服务发现场景我们主要关注客户端数，服务数实例数，及服务订阅者数在大规模场景下，服务端在同步，推送及稳定状态时的性能表现。同时还关注在有大量服务在进行上下线时，系统的性能表现。

容量及稳定性测试

该场景主要关注随着服务规模和客户端实例规模上涨，系统的性能表现情况。

可以看到 2.0.0 版本在 10W 级客户端规模下，能够稳定支撑，在达到稳定状态后，CPU 的损耗非常低。虽然在最初的注册阶段，有瞬时的大量注册和推送，存在一定的推送超时，但是由于重试机制的存在，可以保证最终的一致性。

反观 1.X 版本，在 10W、5W 级客户端下，服务端完全处于 Full GC 状态，推送完全失败，集群不可用；在 2W 客户端规模下，服务端运行状态正常，但由于心跳处理不及时，大量服务反复进行摘除和注册，达不到稳定状态，CPU 一直很高。1.2W 客户端规模下，可以稳定运行，但稳态时 CPU 消耗是更大规模下 2.0 的 3 倍以上。

频繁变更测试

该场景主要关注业务大规模发布，服务频繁推送条件下，不同版本的吞吐和失败率。

频繁变更时，2.0 和 1.X 在达到稳定状态后，均能稳定支撑，其中 2.0 由于不再有瞬时的推送风暴，因此推送失败率归 0，而 1.X 的 UDP 推送的不稳定性导致了有极小部分推送出现了超时，需要重试推送。

Nacos2.0 配置管理的性能提升

配置是读多写少的场景，瓶颈主要在单台监听的客户端数量以及配置的推送获取上，因此配置管理的压测，主要针对在单台服务端的连接容量以及大量推送场景。

连接容量测试

该场景主要关注不同客户端规模下的系统压力。

Nacos2.0 最高单机能够支撑 4.2w 个配置客户端连接，在连接建立的阶段，有大量订阅请求需要处理，因此 CPU 消耗较高，但达到稳态后，CPU 的消耗会变得很低。几乎没有消耗。

反观 Nacos1.X， 在客户端 6000 时，稳定状态的 CPU 一直很高，且 GC 频繁，主要原因是长轮训是通过 hold 请求来保持连接，每 30s 需要回一次 Response 并且重新发起连接和请求。需要做大量的上下文切换，同时还需要持有所有 Request 和 Response。当规模达到 1.2w 客户端时，已经无法达到稳态，所以无法支撑这个量级的客户端数。

频繁推送测试

该场景关注不同推送规模下的系统表现。

在频繁推送场景，两个版本都存在 6000 个客户端连接。明显可以发现 2.0 版本的性能损耗要远低于 1.X 版本。在 3000tps 的推送场景下，优化程度接近 3 倍。

Nacos2.0 性能结论

针对服务发现场景，Nacos2.0 能够在 10W 级规模下，稳定运行；相比 Nacos1.X 版本的 1.2W 规模，提升约 10 倍。

针对配置管理场景，Nacos2.0 单机最高能够支撑 4.2W 个客户端连接；相比 Nacos1.X，提升了 7 倍。且推送时的性能明显高于 1.X。

Nacos2.0 兼容性说明

服务发现

由于服务发现的数据模型发生了比较重大的改变，因此以下功能暂时未支持。

• 查看当前集群 leader（将废弃）
• 批量更新实例元数据(Beta，不支持)
• 批量删除实例元数据(Beta，不支持)

配置中心

• 完全兼容 1.X 客户端所有 API 接口方法
• 完全实现 2.X 客户端所有 API 接口方法
• 完全兼容所有配置中心相关 openAPI

控制台

• 完全兼容配置中心相关页面及功能
• 完全兼容权限控制相关页面及功能
• 完全兼容命名空间相关页面及功能
• 完全兼容集群管理相关页面及功能
• 完全兼容服务发现相关页面及功能

Nacos 生态

随着 Nacos 三年的发展，几乎支持了所有的 RPC 框架和微服务生态，并且引领云原生微服务生态发展。

Nacos 是整个微服务生态中非常核心的组件，它可以无缝和 K8s 服务发现体系互通，通过 MCP/XDS 协议与 Istio 通信，将 Nacos 服务下发 Sidecar；同样也可以和 CoreDNS 联合，将 Nacos 服务通过域名模式暴露给下游调用。

Nacos 目前已经和各类微服务 RPC 框架融合进行服务发现；另外可以协助高可用框架 Sentinel 进行各类管理规则的控制和下发。

如果只使用 RPC 框架，有时候并不足够简单，因为部分 RPC 框架比如 gRPC 和 Thrift，还需要自行启动 Server 并告知 client 该调用哪个 IP。这时候就需要和应用框架进行融合，比如 SCA、Dapr 等；当然也可以通过 Envoy Sidecar 来进行流量控制，应用层的RPC就不需要知道服务 的 IP 列表了。

最后，Nacos 还可以和各类微服务网关打通，实现接入层的分发和微服务调用。

Nacos 在阿里的实践

目前 Nacos 已经完成了自研、开源、商业化三位一体的建设，阿里内部的钉钉、考拉、饿了么、优酷等业务域已经全部采用云产品 MSE 中的 Nacos 服务，并且与阿里和云原生的技术栈无缝整合。下面我们以钉钉为例简单做一下介绍。

Nacos 运行在微服务引擎 MSE https://cn.aliyun.com/product/aliware/mse 上，MSE 提供了全托管的 Nacos 集群，可以进行日常运维和多集群管理等操作；业务的各类 Dubbo3 或 HSF 服务在启动时，通过 Dubbo3 自身注册到 Nacos 集群中；然后 Nacos 通过 MCP 协议将服务信息同步到 Istio 和 Ingress-Envoy 网关。

用户流量从北向进入集团的 VPC 网络中，先通过一个统一接入 Ingress-Tengine 网关，他可以将域名解析并路由到不同的机房、单元等。本周我们也同步更新了 Tengine 2.3.3（https://github.com/alibaba/tengine/releases/tag/2.3.3）版本，内核升级到 Nginx Core 1.18.0 ，支持 Dubbo 协议 ，支持 DTLSv1 和 DTLSv1.2，支持 Prometheus 格式，从而提升阿里云微服务生态完整性、安全性、可观测性。

通过统一接入层网关后，用户请求会通过 Ingress-Envoy 微服务网关，转发到对应的微服务中，并进行调用。如果需要调用到其他网络域的服务，会通过 Ingress-Envoy 微服务网关将流量导入到对应的 VPC 网络中，从而打通不同安全域、网络域和业务域的服务。微服务之间的相互调用，会通过 Envoy Sidecar 或传统的微服务自订阅的方式进行。最终，用户请求在各个微服务的互相调用中，完成并返回给用户。

Nacos 2.X 的规划

Nacos2.X 将在 2.0 解决性能问题的基础上，通过插件化实现新的功能并改造大量旧功能，使得 Nacos 能够更方便，更易于拓展。

总结

Nacos2.0 作为一个跨代版本，彻底解决了 Nacos1.X 的性能问题，将性能提升了 10 倍。并且通过抽象和分层让架构更加简单，通过插件化更好的扩展，让 Nacos 能够支持更多场景，融合更广生态。相信 Nacos2.X 在后续版本迭代后，会更加易用，解决更多微服务问题，并向着 Mesh 化进行更深入地探索。

加入我们

Kirito 邀请你加入我们团队，阿里云招聘政策优化，放低了工作年限的要求，除原先的 P7 外，现在也开始大量招聘 P6 岗位，加入我们共建云原生中间件。

阿里云云原生中间件团队负责分布式软件基础设施。在这里，你会参与到全球最顶级的开源项目（如 Apache Dubbo、RocketMQ、Nacos、Arthas、Tengine、Istio、Envoy）和阿里云核心商业化产品（微服务引擎 MSE、消息队列 MQ、服务网格 ASM）的研发工作中，为阿里云上万家企业提供如微服务引擎、服务网格、消息服务等分布式基础服务，加速企业上云的进程和创新速度。同时，云原生中间件团队也服务着阿里集团众多核心业务和场景，是支撑双十一狂欢节的最核心团队之一。

社招简历投递：jingfeng.xjf@alibaba-inc.com

招聘咨询微信：xiayimiaoshenghua