作者 | 风卿

微服务引擎 MSE 专业版发布，支持 Nacos2.0，相比基础版，专业版具有更高的 SLA 保障，性能提升十倍，99.95%可用性，配置能力进一步增强。新用户首购8折。

前言

MSE 从 2020年1月发布 Nacos1.1.3 版本引擎，支持在公有云环境全托管的方式使用 Nacos 作为注册中心。2020年7月发布 Nacos1.2.1 版本支持元配置数据管理，支持微服务应用在运行时动态修改配置信息和路由规则等。随着用户的深入使用，Nacos1.X 版本的性能问题也渐渐暴露出来。通过对 1.X版本的内核改造，Nacos2.0 专业版性能提升 10倍，基本能满足用户对微服务场景的性能要求。

除了性能的提升，专业版具有更高的 SLA 保障，并且在配置数据上具有更高的安全性，同时通过 MCP 协议与 Istio 生态打通，作为 Istio 的注册中心。

MSE Nacos1.X基础版架构

整体 1.X 架构可以粗略分为五层，分别是接入层、通信层、功能层、同步层和持久化层。

• 用户通过接入层访问 Nacos，比如 SDK、SCA、Dubbo、Console，Nacos 也提供了 HTTP 协议的 open API 访问方式。
• 通信层包含 HTTP 和 UDP，Nacos 主要通过 HTTP 进行通信，少部分服务推送功能会用到 UDP。
• 功能层目前有 Naming 和 Config 两大部分，分别提供服务发现和配置管理能力。
• 同步层包含 AP 模式的 Distro 协议（服务注册）和 CP 模式的 Raft 协议（服务元信息），以及配置通知的 Notify 同步方式。
• Nacos 的数据持久化有用到 Mysql、Derby 和本地文件，配置数据、用户信息、权限数据存储在 Mysql 或者 Derby 中，持久化的服务数据则存放在本地文件。

MSE Nacos1.X基础版架构问题

目前 1.X 的架构存在几个问题：

• 每个服务实例都通过心跳续约，在 Dubbo 场景每个接口对应一个服务，当 Dubbo 的应用接口数较多时需要心跳续约 TPS 会很高。
• 心跳续约感知时延长，需要达到续约超时时间才能删除实例，一般需要 15S，时效性较差。
• 通过 UDP 推送变更数据不可靠，需要客户端定时进行数据全量对账保证数据的正确性，大量无效查询，整体服务的 QPS 很高。
• 通信方式基于 HTTP 短链接的方式，当 Nacos 侧释放连接会进入 TIME_WAIT 状态，当 QPS 较高时会有连接耗尽导致报错的风险，当然这里通过 SDK 引入 HTTP 连接池能缓解，但不能根治。
• 配置的长轮询方式会导致相关数据进入 JVM Old 区申请和释放内存，引起频繁的 CMS GC。

MSE Nacos2.0专业版架构及新模型

1.X 架构的问题核心点在于连接模型上，2.0 架构升级为长连接模型，在通信层通过 gRPC 和 RSocket 实现长连接数据传输和推送能力，在连接层新增加请求处理器、流控和负载均衡等功能。

2.0 架构解决的问题：

• 应用 POD 按照长连接维度进行心跳续约，不需要按照实例级，大大降低重复请求；
• 长连接断开时可以快速感知到，不用等待续约超时时长就可以移除实例；
• NIO 流式推送机制相对于 UDP 更可靠，并且可以降低应用对账数据频率；
• 没有连接反复创建的开销，大幅降低 TIME_WAIT 连接多问题；
• 长连接也解决了配置模块长轮询 CMS GC 问题。

2.0 架构带来的问题：

• 相对于 Tomcat HTTP 短连接模型，长连接模型需要自己管理连接状态，增加了复杂性；
• 长连接 gRPC 基于 HTTP2.0 Stream，相对于 HTTP 的 open API 可观测性和易用性降低了。

2.0 架构整体来说降低了资源开销，提高了系统吞吐量，在性能上有大幅提升，但同时也增加了复杂度。

MSE Nacos2.0专业版性能

Nacos 分为服务发现模块和配置管理模块，这里先对服务发现场景进行性能测试：使用 200 台施压机，每个施压机模拟 500 个客户端，每个客户端注册 5 个服务，订阅 5 个服务，最高可以提供 10W 个长连接、50W 个服务实例和订阅者压测场景。

服务发现压测主要压变更态和稳定态两种场景：

• 变更态：施压机施压阶段会大量连接 Nacos 注册和订阅服务，这个阶段服务端的压力相对会比较大，需要看整体注册和订阅是否最终完全成功。
  
  
• 稳定态：当施压机请求都成功之后就会进入稳定状态，客户端和服务端之间只需要维持长连接心跳即可，这个阶段服务端的压力会比较小。如果在变更态服务端的压力过大会发生请求超时、连接断开等问题，不能进入稳定态。

服务发现也会在 MSE 上对低版本做升级，对比升级前后的性能变化曲线，这样的性能对比更直观。配置管理模块在实际使用中是写少读多的场景，主要瓶颈点在单台机器性能上，压测场景主要基于单台机器的读性能和连接支撑数。

使用 200台 施压机，每台施压机可以模拟 200个 客户端，每个客户端订阅 200个 配置，发起配置订阅和读配置请求。

在服务发现场景对比基础版和专业版在 2C4G、4C8G 和 8C16G 规格下的性能数据情况：这里最大的TPS和实例数都是服务能保证高可用稳定运行的数据，大概会是最大值的一半或者三分之二，也就是说挂一台机器也可以正常运行。

稳定运行时支持规模提升7倍，实际上最大支持规模提升7-10倍。

还有一个场景是对 3节点 2C4G MSE Nacos 升级前后的对比，主要分为三个阶段：

• 第一个阶段客户端使用 1.X 版本，MSE Nacos 使用基础版，实例数从 0->6000->10000，最后到 14000 最大值无法继续增大，Server CPU 达到 80-90%，客户端不断报错，接着降低实例数到 6000；

• 第二阶段升级 MSE Nacos 基础版到专业版，实例数到达 14000 无法继续增大，性能压测性能曲线差异不大；

• 第三阶段在保持实例数为 14000 的状态下，分批升级客户端到 2.0版本，CPU 指标曲线不断下降至 20% 左右，并且整体处于稳定态无报错。

从升级前后的性能曲线感受 MSE Nacos2.0 专业版性能有提升较大。最后整体的压测情况，相较于基础版，专业版服务发现性能提升 10倍，配置管理提升 7倍。

MSE Nacos平滑升级专业版

对于新用户可以直接创建专业版实例，老用户则可以通过 MSE"实例变更"一键升级。MSE 会在后台对 POD 升级，由于 V1V2 数据结构不一样，在一开始的时候 Nacos 数据默认是双写的，在升级过程中数据会从 V1 同步到 V2，升级完成后数据会从 V2 同步 V1，最后 MSE 会关闭双写逻辑，整体流程都是自动。

SLB 的服务端口最后也会增加 GRPC 9848 端口，此时应用 SDK 可以从1.X版本升级到 2.0版本，整体客户端服务端升级到 2.0架构。

版本之间的兼容性情况，整体的兼容原则是高版本的服务端兼容低版本客户端，但是高版本客户端不一定能访问低版本服务端：

• 1.X 客户端可以访问基础版，也可以访问专业版
• 2.0 客户端可以访问专业版，但是不能访问基础版。

Nacos配置安全管理

之前公众号里分享配置权限控制，整体 MSE Nacos 通过阿里云 RAM 主子账号体系来做权限控制，这期我主要讲一下 Nacos 的配置加密功能。

用户在使用配置数据时可能会将用户信息、数据库密码等敏感信息存放到 Nacos 中，而 Nacos 存储配置数据都是明文传输、明文存储的，在数据库内容泄漏或者传输层抓包时会导致敏感配置数据项泄漏，整体安全风险非常高。

常用的 HTTPS 协议能解决传输安全，但解决不了存储安全，这里直接在客户端进行加密，这样在传输和存储的过程中数据都是加密的。

这里使用第三方加密系统（如阿里云 KMS）加强加密的安全性，为了加密速度快使用对称加密（AES 算法），由于密钥要随着密文传输，同时对密钥进行加密，整体采用二级加密的方式。

SDK 在发布数据时会先从 KMS 中拿到密钥和加密后的密钥，然后使用密钥对数据进行加密，接着将加密数据和加密后的密钥传输到 Nacos 存储。SDK 会从 Nacos 获取加密数据和加密后的密钥，然后通过加密后的密钥从 KMS 获取明文密钥，接着通过明文密钥对加密数据进行解密获取明文数据，解决了整体传输和存储中的数据安全问题。

为了兼容老逻辑，并且只有敏感数据需要加密，Nacos 只对固定前缀 DataId 的数据进行加密，并且在开源侧通过 SPI 插件化实现，让用户自己能扩展。用户可以通过 SDK 和 MSE 控制台对敏感数据进行加解密，整体 SDK 和 MSE 控制台都会先访问 KMS 再加密存储配置数据，然后解密之后再展示明文，使用流程和之前明文存储一致。

用户使用 SDK 接入开启加解密功能需要 SDK 在 1.4.2 版本及以上，同时需要引入 MSE 内部实现的 nacos-client-mse-extension 加解密插件。

<dependency>    <groupId>com.alibaba.nacos</groupId>    <artifactId>nacos-client</artifactId>    <version>1.4.2</version>  </dependency>  <dependency>    <groupId>com.alibaba.nacos</groupId>    <artifactId>nacos-client-mse-extension</artifactId>    <version>1.0.1</version>  </dependency>

初始化 SDK 时需要填入子账号 AK/SK，并授权 KMS 加解密权限，具体细节可以参考创建和使用配置加密

Properties properties = new Properties();  properties.put("serverAddr", "mse-xxxxxx-p.nacos-ans.mse.aliyuncs.com");  properties.put("accessKey", "xxxxxxxxxxxxxx");  properties.put("secretKey", "xxxxxxxxxxxxxx");  properties.put("keyId", "alias/acs/mse");  properties.put("regionId", "cn-hangzhou");  ConfigService configService = NacosFactory.createConfigService(properties);  String content = configService.getConfig("cipher-kms-aes-256-dataid", "group", 6

总结

MSE Nacos 2.0 专业版相较于基础版在性能、可用性和安全性上都有较大提升，基础版建议用于测试环境，对于生产环境建议使用专业版。对于用户身份、密码等配置敏感信息建议都开启权限控制能力并且加密保存加强数据安全。

更多 MSE 特性，欢迎进钉钉群交流，MSE 微服务引擎用户交流群（二群）

群号：34754806