作者

本名杨翊，花名席翁。Nacos PMC，主要参与的是服务发现模块，和做一些内核重构和提升的工作。 Apache SharadingSphere PMC，主要负责和参与过的模块有 路由模块、分布式事务、 数据同步、以及弹性扩容。

Nacos 简介

Nacos 在阿里巴巴起源于 2008 年五彩石项目，该项目完成了微服务拆分和业务中台建设，随着云计算和开源环境的兴起，2018 年我们深刻感受到开源软件行业的影响，因此决定将 Nacos 开源，输出阿里十年关于服务发现和配管管理的沉淀，推动微服务行业发展，加速企业数字化转型。

目前Nacos支持主流微服务开发语言&主流服务框架和配置管理框架，比如支持Duboo和SCA， 还对接了一些云原生的组件比如coreDNS和sentinel等。

客户端语言方面支持诸如Java，go python等主流语言，还有近期刚发布正式版本的C#和C++，在此感谢所有社区贡献者的支持。

Nacos 开源2年多以来，共发布了34个版本，其中有一些比较重要的里程碑版本；Nacos还非常年轻，有很大的进步空间，欢迎社区及各界大佬一起共同建设。

Nacos 1.X架构及问题

接下来我们看一下nacos1.x架构及其分析一下存在的比较重要的问题。 首先先来看一下架构简图。

Nacos 1.X架构层次

Nacos 1.X 大致分为5层， 分别是接入、通信、功能、同步和持久化。

接入层是用户最直接交互的层面，主要有Nacos客户端，以及依赖客户端的Dubbo和SCA以及用户操作的控制台Console组成。 客户端和Console进行服务和配置操作，统一通过HTTP的OpenAPI发起通信请求。

通信层主要基于HTTP的短连接请求模型进行，部分推送功能通过UDP进行通信。

功能目前有服务发现和配置管理，这层也就是实际管理服务和配置的业务层。

同步层有数据同步的AP模式Distro和CP模式Raft，还有有一个最简易的水平通知Notify，用处各不相同：

• Distro：非持久化服务的同步模式
• Raft：持久化服务的同步模式、以及使用Derby作为配置的存储时同步配置操作。
• Notify：使用MySQL作为配置的存储时，通知其他节点更新缓存及发起配置推送。

持久化层Nacos使用MySQL、Derby和本地文件系统来进行数据的持久化 配置信息，用户信息，权限信息存储在MySQL或Derby数据库中， 持久化服务信息及服务和实例元数据信息存储在本地文件系统。

Nacos 1.X架构下的服务模型

我们通过一个服务发现的流程，再深入熟悉一下Nacos 1.X架构和基于当前架构的Nacos服务发现模型。

Nacos客户端注册服务会通过OpenAPI发送Http注册服务的请求，请求内容会带上服务信息及实例信息，通常这个步骤是由微服务框架SCA和dubbo完成。

服务端收到请求后，会先在Contoller中进行数据的读取和校验，比如IP是否合法，服务名是否正确等等。校验通过后，如果这个服务是第一次注册，Nacos会在服务端生成一个Service对象，然后把这次注册的实例信息存入这个Service对象中；如果Nacos服务端已经有了这个Service对象，那么就会直接把新注册的实例信息存入对象。这个Service对象通过 命名空间+Group+Service 的组合来保证唯一性。

完成实例存入Service的同时，会触发两个事件，其中一个事件是用于数据同步的，Nacos服务端会根据这个服务是否是临时对象的信息，使用Distro或者Raft协议进行同步，通知其他的Nacos节点该服务发生了变更；另一个事件则通知在该Nacos服务节点上订阅了该服务的订阅者，并根据订阅者信息，通过UDP的方式，把最新的服务列表推送到订阅者客户端上。这就完成了一次服务注册流程。

另外，对于那些被定义为持久化的服务的所有信息，都会通过raft协议，保证能够写入到文件系统中被持久化。

最后，其他的Nacos节点，在通过同步而进行Service变更的时候也会触发通知订阅者的事件，从而使在其他Nacos服务节点上订阅该服务的订阅者也能收到推送。

1.X架构存在的问题

粗略介绍了下 Nacos1.X的架构和服务发现模型，接下来分析一下Nacos1.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。

Nacos 2.0架构及新模型

Nacos 2.0架构层次

Nacos 2.X 在 1.X的架构基础上 新增了对长连接模型的支持，同时保留对旧客户端和openAPI的核心功能支持。

通信层目前通过gRPC和Rsocket实现了长连接RPC调用和推送能力。

在服务端测，新增一个链接层，用来将不同类型的Request请求，将来自不同客户端的不同类型请求，转化为相同语意的功能数据结构，复用业务处理逻辑。同时，将来的流量控制和负载均衡等功能也会在链接层处理。

其他架构分层在大体上保持不变。

Nacos 2.0新服务模型

虽然Nacos2.0的在架构层次上并未做太大的变化，但是具体的模型细节却有不小的改动，依旧使用注册服务的流程，再深入了解一下Nacos2.0服务模型的变化。

由于通信使用了RPC方式，因此某一客户端的所有请求（无论是注册还是订阅）都通过同一个链接和同一个服务节点进行，不像之前通过HTTP连接可能每次请求都请求在不同的Nacos节点上，这就导致了服务发现的数据内容由原来的无状态化变为了与连接状态绑定的一种有状态数据。为了适应这种变化，需要改变一下数据模型，因此抽象了一个新数据结构，将同一个客户端通过该链接发布和订阅的内容关联起来，暂命名为Client。这个Client不是客户端的意思，而是这个客户端所相关的数据内容，一个链接与一个Client对应。

当客户端发布了服务时，该客户端所发布的所有服务与订阅者信息会被更新到与该客户端链接相对应的Client对象中，然后通过事件机制触发对索引信息的更新。这个索引信息是客户端链接和服务的索引，方便快速聚合生成需要推送的服务纬度的数据。

索引信息更新完成后，会触发推送事件，此时会将所有和该服务有关的Client对象，通过刚产生的索引信息聚合起来，当数据聚合完成后，再从客户端链接中筛选出订阅该服务的订阅者的客户端链接，将推送数据通过该链接，推送回去。这样一次发布变更的主链路就完成了。

回过头看数据同步，客户端发布了服务时实际更新的对象从原来的Service变成Client对象，所以需要同步的内容也变成了Client对象；同时服务端间的通信方式也会换成RPC。这里只有真正被客户端更新的Client对象会触发同步，如果是通过同步而更新的Client对象不会再次触发同步。

最后看Metadata，Metadata是从1.X版本中的Service对象和Instance对象中分离出来的一些属性：比如服务的元数据label标签，实例的上下线状态、权重和元数据label标签等。这些元数据可以被openAPI单独修改，在聚合数据时生效。之所以将元数据拆分出来，区别于基础数据，原因是基础数据，比如：ip端口，服务名等一经发布不应该被修改，而且应当以发布时的信息为准；但其他的原数据，比如上下线状态和权重，通常是在运行过程中动态调节的，因此拆分开之后，分为两条不同的处理工作流应该更加合理。

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

加入我们

欢迎在 Nacos github 上提交issue与PR进行讨论和贡献。或加入Nacos社区群参与社区讨论。

除了参与开源，我们也欢迎更多有能力及有意愿的同学加入阿里云共建云原生，详情请看云原生应用平台。

本文整理自Spring Cloud Alibaba Meetup杭州站演讲，全年Spring Cloud Alibaba Meetup全年规划戳这里。