阿里的 Nacos 2.0 正式发布，性能大幅提升 10 倍！

大家好，我是D哥

点击关注下方公众号，Java面试资料 都在这里

Nacos 项目起源于阿里巴巴内部的五彩石项目，从 2008 年开始，就已经在内部孵化了。近年来受 Eureka、Consul 等项目的影响，Nacos 越来越受欢迎！

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

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

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

# 1.X架构存在的问题

接下来看一下 Nacos1.X 架构所面临的几个比较重要的问题。

一句话总结，心跳多，无效查询多，心跳续约感知变化慢，连接消耗大，资源空耗严重。

图片

1、心跳数量多，导致 TPS 居高不下

通过心跳续约，当服务规模上升时，特别是类似 Dubbo 的接口级服务较多时，心跳及配置元数据的轮询数量众多，导致集群 TPS 很高，系统资源高度空耗。

2、通过心跳续约感知服务变化，时延长

心跳续约需要达到超时时间才会移除并通知订阅者，默认为 15 s，时延较长，时效性差。若改短超时时间，当网络抖动时，会频繁触发变更推送，对客户端服务端都有更大损耗。

3、UDP 推送不可靠，导致 QPS 居高不下

由于 UDP 不可靠，因此客户端测需要每隔一段时间进行对账查询，保证客户端缓存的服务列表的状态正确，当订阅客户端规模上升时，集群 QPS 很高，但大多数服务列表其实不会频繁改变，造成无效查询，从而存在资源空耗。

4、基于 HTTP 短连接模型，TIME_WAIT 状态连接过多

HTTP 短连接模型，每次客户端请求都会创建和销毁 TCP 链接，TCP 协议销毁的链接状态是 WAIT_TIME，完全释放还需要一定时间，当 TPS 和 QPS 较高时，服务端和客户端可能有大量的 WAIT_TIME 状态链接，从而会导致 connect time out 错误或者 Cannot assign requested address 的问题。

5、配置模块的 30 秒长轮询引起的频繁 GC

配置模块使用 HTTP 短连接阻塞模型来模拟长连接通信，但是由于并非真实的长连接模型，因此每 30 秒需要进行一次请求和数据的上下文切换，每一次切换都有引起造成一次内存浪费，从而导致服务端频繁 GC。

# Nacos 2.x 架构的优缺点

前面简要介绍了 Nacos 2.x 的架构和新模型的工作方式，接下来我们分析一下这样的改动有哪些优缺点。

图片

优点

1. 客户端不再需要定时发送实例心跳，只需要有一个维持连接可用 keepalive 消息即可。重复 TPS 可以大幅降低。
2. TCP 连接断开可以被快速感知到，提升反应速度。
3. 长连接的流式推送，比 UDP 更加可靠；nio 的机制具有更高的吞吐量，而且由于可靠推送，可以加长客户端用于对账服务列表的时间，甚至删除相关的请求。重复的无效 QPS 可以大幅降低。
4. 长连接避免频繁连接开销，可以大幅缓解 TIME_ WAIT 问题。
5. 真实的长连接，解决配置模块 GC 问题。
6. 更细粒度的同步内容，减少服务节点间的通信压力。

缺点

没有银弹的方案，新架构也会引入一些新问题

1. 内部结构复杂度上升，管理连接状态，连接的负载均衡需要管理。
2. 数据由原来的无状态，变为与连接绑定的有状态数据，流程链路更长。
3. RPC 协议的观测性不如 HTTP。即使 gRPC 基于 HTTP2.0 Stream 实现，仍然不如直接使用 HTTP 协议来的直观。

# 性能提升

Nacos 2.x 服务发现性能测试都是针对重点功能，通过对 3 节点规模集群进行压测，可以看到接口性能负载和容量，以及对比相同/类似场景下 Nacos1.X 版本的提升。

• 压测时服务及实例容量达到百万级，集群运行持续稳定，达到预期；（该场景没有计算频繁变更导致的频繁推送内容，仅单纯计算容量上线，附带推送的真实场景将在下轮压测报告中给出）
• 注册/注销实例 TPS 达到 26000 以上，总体较 Nacos1.X 提升至少 2 倍，接口达到预期；
• 查询实例 TPS 能够达到 30000 以上，总体较 Nacos1.X 提升 3 倍左右，接口达到预期；

# 兼容性

配置中心

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

服务发现

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

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

控制台

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

Spring Cloud Alibaba 适配

由于目前 Spring cloud alibaba 2.2.5 版本内置的 nacos-client 为 1.4.1，可通过指定 nacos-client 方式，提前使用 Nacos2.0 长连接功能。

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>2.2.5.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>com.alibaba.nacos</groupId>
            <artifactId>nacos-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
    <version>2.2.5.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>com.alibaba.nacos</groupId>
            <artifactId>nacos-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>2.0.0</version>
</dependency>

最后，期待大家抢先体验，帮助发现修复 bug，改善社区，贡献智慧，参与 Nacos 开源社区建设！Nacos 项目起源于阿里巴巴内部的五彩石项目，从 2008 年开始，就已经在内部孵化了。近年来受 Eureka、Consul 等项目的影响，Nacos 越来越受欢迎！

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

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

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

热门推荐：