1.Distro协议

Distro 协议是 Nacos 社区自研的⼀种 AP 分布式协议，是面向临时实例设计的⼀种分布式协议，其保证了在某些 Nacos 节点宕机后，整个临时实例处理系统依旧可以正常工作。作为⼀种有状态的中间件应用的内嵌协议，Distro 保证了各个Nacos 节点对于海量注册请求的统⼀协调和存储。

• 1.数据初始化同步
  新加入的 Distro 节点会进行全量数据拉取。具体操作是轮询所有的 Distro 节点，通过向其他的机器发送请求拉取全量数据，在全量拉取操作完成之后，Nacos 的每台机器上都维护了当前的所有注册上来的非持久化实例数据。
  

  image.png

• 2.数据同步校验
  在 Distro 集群启动之后，各台机器之间会定期的发送心跳。心跳信息主要为各个机器上的所有数据的元信息（之所以使用元信息，是因为需要保证网络中数据传输的量级维持在⼀个较低水平）。这种数据校验会以心跳的形式进行，即每台机器在固定时间间隔会向其他机器发起⼀次数据校验请求，⼀旦在数据校验过程中，某台机器发现其他机器上的数据与本地数据不⼀致，则会发起⼀次全量拉取请求，将数据补齐
  

  image.png

• 3.写操作数据同步
  对于⼀个已经启动完成的 Distro 集群，在⼀次客户端发起写操作的流程中，当注册非持久化的实例的写请求打到某台 Nacos 服务器时，Distro 集群处理的流程图如下。
  

  image.png

整个步骤包括几个部分（图中从上到下顺序）：
1.前置的 Filter 拦截请求，并根据请求中包含的 IP 和 port 信息计算其所属的 Distro 责任节点，并将该请求转
发到所属的 Distro 责任节点上。
2.责任节点上的 Controller 将写请求进行解析。
3.Distro 协议定期执行 Sync 任务，将本机所负责的所有的实例信息同步到其他节点上。

• 4.读操作数据同步
  由于每台机器上都存放了全量数据，因此在每⼀次读操作中，Distro 机器会直接从本地拉取数据。快速响应
  
  image.png
  
  这种机制保证了 Distro 协议可以作为⼀种 AP 协议，对于读操作都进行及时的响应。在网络分区的情况下，对于所有的读操作也能够正常返回；当网络恢复时，各个 Distro 节点会把各数据分片的数据进行合并恢复。

2.服务发现与注册

2.1 临时实例注册

• 1.健康检测
  使用客户端服务心跳上报（SDK）方式维持活性，发送心跳的周期默认是 5 秒，Nacos 服务端会在 15 秒没收到心跳后将实例设置为不健康，在 30 秒没收到心跳时将这个临时实例摘除

• 2.心跳上报方式
  OpenAPI
  调用 Http 接口对服务进行注册，然后通过 Http 接口发送心跳到注册中心。在注册服务的同时会注册⼀个全局的客户端心跳检测的任务。在服务⼀段时间没有收到来自客户端的心跳后，该任务会将其标记为不健康，如果在间隔的时间内还未收到心跳，那么该任务会将其剔除。

  SDK RPC
  客户端会定时的通过 RPC 连接向 Nacos 注册中心发送心跳(Nacos 2.x 版本中，旧版的还是仍然通过OpenAPI 的方式)，保持连接的存活。如果客户端和注册中心的连接断开，那么注册中心会主动剔除该 client 所注册的服务，达到下线的效果。同时 Nacos 注册中心还会在注册中心启动时，注册⼀个过期客户端清除的定时任务，用于删除那些健康状态超过⼀段时间的客户端。

2.2 永久实例注册

Nacos 中使用 SDK 对于永久实例的注册实际也是使用 OpenAPI 的方式进行注册，这样可以保证即使是客户端下线后也不会影响永久实例的健康检查。

• 1.健康检测
  Nacos 采用的是注册中心探测机制，注册中心会在永久服务初始化时 根据客户端选择的协议类型注册探活的定时任务。Nacos 现在内置提供了三种探测的协议，即 Http、TCP 以及 MySQL 。⼀般而言 Http 和 TCP 已经可以涵盖绝大多数的健康检查场景。

2.3 集群模式下健康检测

Nacos ⼀个服务只会被 Nacos 集群中的⼀个注册中心所负责，其余节点的服务信息只是集群副本，用于订阅者在查询服务列表时，始终可以获取到全部的服务列表。临时实例只会对其被负责的注册中心节点发送心跳信息，注册中心服务节点会对其负责的永久实例进行健康探测，在获取到健康状态后由当前负责的注册中心节点将健康信息同步到集群中的其他的注册中心。
OpenAPI
OpenAPI 注册的临时实例也是通过同步自身负责的节点到其他节点来更新其他节点的对应的临时实例的心跳时间，保证其他节点不会删除或者修改此实例的健康状态。
SDK RPC
只需要和注册中心集群中的任意⼀台节点建立联系，那么由这个节点负责这个客户端就可以了。注册中心会在启动时注册⼀个全局的同步任务，用于将其当前负责的所有节点信息同步到集群中的其他节点，其他非负责的节点也会创建该客户端的信息，在非负责的节点上，连接类型的客户端，会有⼀个续约时间的概念，在收到其他节点的同步信息时，更新续约时间为当前时间，如果在集群中的其他节点在⼀段时间内没有收到不是自己的负责的节点的同步信息，那么认为此节点已经不健康，从而达到对不是自己负责的节点健康状态检查

3.配置管理

Nacos 配置管理⼀致性协议分为两个大部分，第⼀部分是 Server 间⼀致性协议，⼀个是 SDK 与Server 的⼀致性协议，配置作为分布式系统中非强⼀致数据，在出现脑裂的时候可用性高于⼀致性，因此阿里配置中心是采用 AP ⼀致性协议

3.1 Server 间的⼀致性协议

有 DB 模式（读写分离架构）
数据写任何⼀个 Server，优先持久化，持久化成功后异步通知其他节点到数据库中拉取最新配置值，并且通知写入成功

image.png

3.2 SDK 与 Server 的⼀致性协议

SDK 与 Server ⼀致性协议的核心是通过 MD5 值是否⼀致，如果不⼀致就拉取最新值
Nacos 1.X
Nacos 1.X 采用 Http 1.1 短链接模拟长链接，每 30s 发⼀个心跳跟 Server 对比 SDK 配置 MD5 值是否跟 Server 保持⼀致，如果⼀致就 hold 住链接，如果有不⼀致配置，就把不⼀致的配置返回，然后 SDK 获取最新配置值
Nacos 2.X
Nacos 2.x 相比上面 30s ⼀次的长轮训，升级成长链接模式，配置变更，启动建立长链接，配置变更服务端推送变更配置列表，然后 SDK 拉取配置更新，因此通信效率大幅提升。

4.寻址机制

寻址机制是Nacos集群中去获取其他成员节点的方式

4.1 单机寻址

单机模式的寻址模式很简单，其实就是找到自己的 IP:PORT 组合信息，然后格式化为⼀个节点信息

4.2 文件寻址

文件寻址模式是 Nacos 集群模式下的默认寻址实现。文件寻址模式很简单，其实就是每个 Nacos节点需要维护⼀个叫做 cluster.conf 的文件，该文件默认只需要填写每个成员节点的 IP 信息即可，端口会自动选择 Nacos 的默认端口 8848。

4.3 地址服务器寻址

地址服务器寻址模式是 Nacos 官方推荐的⼀种集群成员节点信息管理，该模式利用了⼀个简易的web 服务器，用于管理 cluster.conf 文件的内容信息，这样，运维人员只需要管理这⼀份集群成员节点内容即可，而每个 Nacos 成员节点，只需要向这个 web 节点定时请求当前最新的集群成员节点列表信息即可。

配置方式

5.Eureka迁移Nacos