Nacos简介—4.Nacos架构和原理二

大纲

1.Nacos的定位和优势

2.Nacos的整体架构

3.Nacos的配置模型

4.Nacos内核设计之一致性协议

5.Nacos内核设计之自研Distro协议

6.Nacos内核设计之通信通道

7.Nacos内核设计之寻址机制

8.服务注册发现模块的注册中心的设计原理

9.服务注册发现模块的注册中心的服务数据模型

10.服务注册发现模块的健康检查机制

11.配置管理模块的配置一致性模型

12.Zookeeper、Eureka和Nacos的对比总结

5.Nacos内核设计之自研Distro协议

(1)Distro协议的背景和设计思想

(2)Distro协议的工作原理之数据初始化

(3)Distro协议的工作原理之数据校验

(4)Distro协议的工作原理之写操作

(5)Distro协议的工作原理之读操作

(6)总结

(1)Distro协议的背景和设计思想

一.Distro协议的背景

Distro协议是Nacos自研的⼀种AP分布式协议，也是面向临时实例设计的⼀种分布式协议。它保证了在某些Nacos节点宕机后，整个临时实例处理系统依旧可正常工作。

作为⼀种有状态的中间件应用的内嵌协议，Distro协议保证了各个Nacos节点对于海量注册请求的统⼀协调和存储。

二.Distro协议的设计思想

设计一：Nacos每个节点是平等的

每个节点都会处理写请求，以及都会把新数据同步到其他节点。

设计二：每个节点只负责部分数据

每个节点都会定时发送自己负责数据的校验值到其他节点来保持数据⼀致性。

设计三：每个节点独立处理读请求

所以每个节点都能够及时从本地发出响应。

(2)Distro协议的工作原理之数据初始化

新加入的Nacos节点会拉取全量数据。具体操作就是轮询所有Nacos节点，向其他节点发送请求来拉取全量数据。

完成拉取全量数据后，Nacos的每个节点都拥有了当前所有注册上来的非持久化实例数据。

(3)Distro协议的工作原理之数据校验

在Nacos集群启动后，各节点间会定期发送心跳。心跳信息主要是当前节点上的所有数据的元信息，使用元信息的原因是要保证在网络中传输的数据量维持在⼀个较低水平。

这种数据校验会以心跳的形式进行。即每个节点会在固定时间间隔，向其他节点发起⼀次数据校验请求。在数据校验过程中，一旦某节点发现其他节点上的数据与本地数据不⼀致，则会发起⼀次全量拉取请求，将数据补齐。

(4)Distro协议的工作原理之写操作

对于⼀个已经启动完成的Nacos集群，在⼀次客户端发起写操作的流程中，当注册非持久化的服务实例的写请求发送到某台Nacos节点时，Nacos集群处理的流程如下：

一.前置的Filter拦截写请求

首先，收到写请求的Nacos节点，其前置Filter会拦截写请求。然后根据请求中包含的IP和Port信息计算其所属的Nacos责任节点，并将该请求转发到所属的Nacos责任节点上。

二.Controller会解析写请求

所属的Nacos责任节点收到写请求后，会让其Controller解析写请求。

三.Distro协议下Nacos节点会定时执行同步任务

定时同步任务会将本机所负责的所有实例信息同步到其他节点上。

(5)Distro协议的工作原理之读操作

由于Nacos的每个节点上都存放了全量数据，因此在每⼀次读操作中，Nacos节点会直接从本地拉取数据进行快速响应。

这种机制保证了Distro协议作为⼀种AP协议，能及时响应读操作的请求。在网络分区情况下，对于所有的读操作也能够正常返回。当网络分区恢复时，各Nacos节点都会把各数据分片的数据进行合并恢复。

(6)总结

Distro协议是Nacos对临时服务实例数据开发的⼀致性协议。其数据存储在缓存中，在启动时进行全量数据同步，并定期进行数据校验。在Distro协议的设计思想下，每个节点都可以接收和处理读写请求。

Distro协议的请求场景主要分为如下三种情况：

情况一：当节点接收到属于自己负责的服务实例的写请求时，直接写入。

情况二：当节点接收到不属于自己负责的服务实例的写请求时，首先在集群内部路由，然后转发给对应的节点，从而完成写请求。

情况三：当节点接收到任何读请求时，都直接在本机查询并返回，因为所有服务实例的数据都被同步到了各机器节点上。

Distro协议作为Nacos临时服务实例的⼀致性协议，保证了分布式环境下各节点上的服务信息状态，都能及时通知其他节点。Distro协议可让Nacos维持数十万量级的服务实例数据的存储和⼀致性。

6.Nacos内核设计之通信通道

(1)现状背景

(2)场景分析

(3)长连接核心诉求

(4)长连接选型对比

(1)现状背景

Nacos 1.x版本的Config/Naming模块，各自的推送通道都是按照自己的设计模型来实现的。配置和服务器模块的数据推送通道不统⼀，HTTP短连接性能压力巨大，未来Nacos需构建能同时支持配置及服务的长连接通道，以标准的通信模型重构推送通道。

(2)场景分析

场景一：配置管理

一.Client和Server之间的通信

客户端Client需要感知服务端Server的节点列表，需要按照某种策略选择其中⼀个Server节点进行连接。当底层连接断开时，客户端Client就需要切换Server进行重连。

客户端基于当前可用的长连接，进行配置的查询、发布、删除、监听等RPC语义的接口通信。

服务端需要将配置变更消息推送给当前监听的客户端。当网络不稳定时，客户端接收失败，就需要支持重推并告警。

服务端需要感知客户端连接断开事件，将连接注销，并且清空连接对应的上下文。

二.Server之间的通信

每个Server都需要能够获取集群所有Server的地址列表，然后为每个Server创建独立的长连接。当长连接断开时，需要进行重连。当节点列表变更时，需要创建新节点的长连接和销毁下线节点的长连接。

Server间需要进行数据同步，包括配置信息、当前连接数信息、系统负载信息、负载调节信息等同步。

场景二：服务注册发现

一.Client和Server之间的通信

客户端Client需要感知服务端Server的节点列表，需要按照某种策略选择其中⼀个Server节点进行连接。当底层连接断开时，客户端Client就需要切换Server进行重连。

客户端基于当前可用的长连接，进行服务的查询、注册、注销、订阅等RPC语义的接口通信。

服务端需要将服务变更消息推送新给客户端，完成推送后客户端需要ACK，方便服务端进行metrics统计和重推判定等。

服务端需要感知客户端连接断开事件，将连接注销，并且清空连接对应的上下文。

二.Server之间的通信

服务端之间需要通过长连接感知对端存活状态，需要通过长连接汇报服务状态(同步RPC能力)。

服务端之间进行AP Distro数据同步，需要异步RPC带ACK能力。

(3)长连接核心诉求

一.功能性诉求

二.性能要求

三.负载均衡

四.连接生命周期

一.功能性诉求

客户端的诉求：

诉求一：实时感知连接生命周期的能力，包括连接建立