深入浅出讲解MSE Nacos 2.0新特性

简介： 随着云原生时代的到来，微服务已经成为应用架构的主流，Nacos也凭借简单易用、稳定可靠、性能卓越的核心竞争力成为国内微服务领域首选的注册中心和配置中心；Nacos2.0更是把性能做到极致，让业务快速发展的用户再也不用担心性能问题；同时阿里云MSE也提供Nacos2.0托管服务，一键开通享受阿里十年沉淀微服务所有能力！

作者|风卿

前言

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再加密存储配置数据，然后解密之后再展示明文，使用流程和之前明文存储一致