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中，持久化的服务数据则存放在本地文件
Nacos1.X基础版架构问题
目前1.X的架构存在几个问题：
- 每个服务实例都通过心跳续约，在Dubbo场景每个接口对应一个服务，当Dubbo的应用接口数较多时需要心跳续约TPS会很高。
- 心跳续约感知时延长，需要达到续约超时时间才能删除实例，一般需要15S，时效性较差
- 通过UDP推送变更数据不可靠，需要客户端定时进行数据全量对账保证数据的正确性，大量无效查询，整体服务的QPS很高
- 通信方式基于HTTP短链接的方式，Nacos侧释放连接会进入TIME_WAIT状态，当QPS较高时会有连接耗尽导致报错的风险，当然这里通过SDK引入HTTP连接池能缓解，但不能根治
- 配置的长轮询方式会导致相关数据进入JVM Old区申请和释放内存，引起频繁的CMS GC
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架构整体来说降低了资源开销，提高了系统吞吐量，在性能上有大幅提升，但同时也增加了复杂度