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

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

微服务引擎 MSE 专业版发布，支持 Nacos 2.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加解密插件。

    com.alibaba.nacos

    nacos-client

    1.4.2

    com.alibaba.nacos

    nacos-client-mse-extension

    1.0.1

初始化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", 6000);

总结

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

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

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。