Nacos 2.0 正式发布，性能提高了 10 倍！！

前不久，在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架构存在的问题

一句话总结，心跳多，无效查询多，心跳续约感知变化慢，链接消耗大，资源空耗严重。

一、 心跳数量多，致使TPS居高不下

经过心跳续约，当服务规模上升时，特别是相似Dubbo的接口级服务较多时，心跳及配置元数据的轮询数量众多，致使集群TPS很高，系统资源高度空耗。

二、 经过心跳续约感知服务变化，时延长

心跳续约须要达到超时时间才会移除并通知订阅者，默认为15s，时延较长，时效性差。若改短超时时间，当网络抖动时，会频繁触发变动推送，对客户端服务端都有更大损耗。

三、 UDP推送不可靠，致使QPS居高不下

因为UDP不可靠，所以客户端测须要每隔一段时间进行对帐查询，保证客户端缓存的服务列表的状态正确，当订阅客户端规模上升时，集群QPS很高，但大多数服务列表其实不会频繁改变，形成无效查询，从而存在资源空耗。

四、基于HTTP短链接模型，TIME_WAIT状态链接过多

HTTP短链接模型，每次客户端请求都会建立和销毁TCP连接，TCP协议销毁的连接状态是WAIT_TIME，彻底释放还须要必定时间，当TPS和QPS较高时，服务端和客户端可能有大量的WAIT_TIME状态连接，从而会致使connect time out错误或者Cannot assign requested address 的问题。

五、配置模块的30秒长轮询 引发的频繁GC

配置模块使用HTTP短链接阻塞模型来模拟长链接通讯，可是因为并不是真实的长链接模型，所以每30秒须要进行一次请求和数据的上下文切换，每一次切换都有引发形成一次内存浪费，从而致使服务端频繁GC。

2.0架构

Nacos 2.0 架构最主要的变化就是增长了对长链接的支持，gRPC 和 Rsocket 实现了长链接 RPC 调用和推送能力。

2.0服务模型

虽然Nacos2.0的在架构层次上并未作太大的变化，可是具体的模型细节却有不小的改动，依旧使用注册服务的流程

Nacos 2.0架构的优缺点

优势
一、 客户端再也不须要定时发送实例心跳，只须要有一个维持链接可用keepalive消息便可。重复TPS能够大幅下降。

二、 TCP链接断开能够被快速感知到，提高反应速度。

三、 长链接的流式推送，比UDP更加可靠；nio的机制具备更高的吞吐量，并且因为可靠推送，能够加长客户端用于对帐服务列表的时间，甚至删除相关的请求。重复的无效QPS能够大幅下降。

四、 长链接避免频繁链接开销，能够大幅缓解TIME_ WAIT问题。

五、 真实的长链接，解决配置模块GC问题。

六、 更细粒度的同步内容，减小服务节点间的通讯压力。

缺点
没有银弹的方案，新架构也会引入一些新问题

一、 内部结构复杂度上升，管理链接状态，链接的负载均衡须要管理。

二、 数据由原来的无状态，变为与链接绑定的有状态数据，流程链路更长。

三、 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架构的一些缺点，如负载均衡，可观测性进行提高。