深入浅出讲解 MSE Nacos 2.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