前不久，在3月20号，Nacos 2.0.0 正式发布了！我简单看了下官方的介绍，可能nacos未来逐渐会成为各大公司作为服务治理和配置中心的主要中间件。
Nacos 简介：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
通俗点讲，Nacos 就是一把微服务双剑：注册中心 + 配置中心，由阿里巴巴于 2018 年开源。
Nacos 2.0.0
概述
一图看清naocs
架构模型
1.X架构：
Nacos 1.X 大致分为5层， 分别是接入、通信、功能、同步和持久化。
1.X服务模型
1.X架构存在的问题
一句话总结，心跳多，无效查询多，心跳续约感知变化慢，连接消耗大，资源空耗严重。
1、 心跳数量多，导致TPS居高不下
通过心跳续约，当服务规模上升时，特别是类似Dubbo的接口级服务较多时，心跳及配置元数据的轮询数量众多，导致集群TPS很高，系统资源高度空耗。
2、 通过心跳续约感知服务变化，时延长
心跳续约需要达到超时时间才会移除并通知订阅者，默认为15s，时延较长，时效性差。若改短超时时间，当网络抖动时，会频繁触发变更推送，对客户端服务端都有更大损耗。
3、 UDP推送不可靠，导致QPS居高不下
由于UDP不可靠，因此客户端测需要每隔一段时间进行对账查询，保证客户端缓存的服务列表的状态正确，当订阅客户端规模上升时，集群QPS很高，但大多数服务列表其实不会频繁改变，造成无效查询，从而存在资源空耗。
4、基于HTTP短连接模型，TIME_WAIT状态连接过多
HTTP短连接模型，每次客户端请求都会创建和销毁TCP链接，TCP协议销毁的链接状态是WAIT_TIME，完全释放还需要一定时间，当TPS和QPS较高时，服务端和客户端可能有大量的WAIT_TIME状态链接，从而会导致connect time out错误或者Cannot assign requested address 的问题。
5、配置模块的30秒长轮询 引起的频繁GC
配置模块使用HTTP短连接阻塞模型来模拟长连接通信，但是由于并非真实的长连接模型，因此每30秒需要进行一次请求和数据的上下文切换，每一次切换都有引起造成一次内存浪费，从而导致服务端频繁GC。
2.0架构
Nacos 2.0 架构最主要的变化就是增加了对长连接的支持，gRPC 和 Rsocket 实现了长连接 RPC 调用和推送能力。
2.0服务模型
虽然Nacos2.0的在架构层次上并未做太大的变化，但是具体的模型细节却有不小的改动，依旧使用注册服务的流程
Nacos 2.0架构的优缺点
优点
1、 客户端不再需要定时发送实例心跳，只需要有一个维持连接可用keepalive消息即可。重复TPS可以大幅降低。
2、 TCP连接断开可以被快速感知到，提升反应速度。
3、 长连接的流式推送，比UDP更加可靠；nio的机制具有更高的吞吐量，而且由于可靠推送，可以加长客户端用于对账服务列表的时间，甚至删除相关的请求。重复的无效QPS可以大幅降低。
4、 长连接避免频繁连接开销，可以大幅缓解TIME_ WAIT问题。
5、 真实的长连接，解决配置模块GC问题。
6、 更细粒度的同步内容，减少服务节点间的通信压力。
缺点
没有银弹的方案，新架构也会引入一些新问题
1、 内部结构复杂度上升，管理连接状态，连接的负载均衡需要管理。
2、 数据由原来的无状态，变为与连接绑定的有状态数据，流程链路更长。
3、 RPC协议的观测性不如HTTP。即使gRPC基于HTTP2.0Stream实现，仍然不如直接使用HTTP协议来的直观。
Nacos 2.X 规划
简单分享下Nacos 2.X 的后期规划吧。主要分为文档、质量和Roadmap。
在文档和质量方面，Nacos 1.X都做的不是很好。文档内容较少，仅有简单使用文档；和版本有一定脱节，更新不及时；没有对技术内容的说明，参与贡献难度高。代码质量及测试质量也不是很高，虽然已经使用checkstyle进行了codeStyle的校验以及开启了社区协作review。但是这还远远不够。Nacos 2.X将会逐步更新、细化官网使用文档；通过电子书对技术细节进行解析；通过Github展示技术方案，促进讨论及贡献；并且对代码进行大量重构及UT和IT的治理工作，在未来将Benchmark也会开源出来，方便给开源用户进行压测。
而RoadMap方面， Nacos 2.X 会对项目做大幅度的重构，完成初步插件化，并对刚才2.0架构的一些缺点，如负载均衡，可观测性进行提升。