一、Nacos 配置管理模块

1、配置⼀致性模型

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

2、Server 间的⼀致性协议

2.1、有 DB 模式（读写分离架构）

⼀致性的核心是 Server 与 DB 保持数据⼀致性，从而保证 Server 数据⼀致；Server 之间都是相等的。数据写任何⼀个 Server，优先持久化，持久化成功后异步通知其他节点到数据库中拉取最新配置值，并且通知写入成功。

2.2、无 DB 模式

Server 间采用 Raft 协议保证数据⼀致性，行业大部分产品采用此模式，因此不展开介绍。Nacos提供此模式，是方便用户本机运行，降低对存储依赖。

3、SDK 与 Server 的⼀致性协议

SDK 与 Server ⼀致性协议的核心是通过 MD5 值是否⼀致，如果不⼀致就拉取最新值。

3.1、Nacos 1.X

Nacos 1.X 采用 Http 1.1 短链接模拟长链接，每 30s 发⼀个心跳跟 Server 对比 SDK 配置 MD5 值是否跟 Server 保持⼀致，如果⼀致就 hold 住链接，如果有不⼀致配置，就把不⼀致的配置返回，然后 SDK 获取最新配置值。

3.2、Nacos 2.X

Nacos 2.x 相比上面 30s ⼀次的长轮训，升级成长链接模式，配置变更，启动建立长链接，配置变更服务端推送变更配置列表，然后 SDK 拉取配置更新，因此通信效率大幅提升。

二、Nacos ⾼可⽤设计

Nacos 历经 10 多年双十⼀考验，经历过多次断网，节点全挂，存储不可用各种故障，因此充分面对失败设计，沉淀了非常多的经验。

1、全局高可用

Nacos 部署架构上是单 Region 封闭，Region 间独立，跨 Region 通过网关或者 Nacos-sync 完成服务互通。从而降低 Region 间网络故障风险。 当然用户也可以跨 Region 组 Nacos 集群，但是这样会带来服务跨 Region 互调，真正发生网络故障的时候，无法控制业务影响。 因此不推荐此模式。

2、同城容灾

Nacos 本身是采用 AP 的⼀致性模式，同 Region 多个可用区部署，任何⼀个可用区出问题，剩下部分继续工作。 很多人问为什么不是三个可用区呢？ 因为业务都部署三个可用区从理论上是可用性最好的，但是成本会大幅增加，因此⼀般公司只选择两个可用区。

3、数据多级容灾

Nacos 持久化存储做了主备容灾，而且底层存储数据多副本高可用保障。 Nacos Server 有全量缓存数据，即使存储挂或者不可用，只影响写，核心的读服务不受影响。 Nacos SDK 有所需服务和配置缓存，Server 即使全挂，走本地缓存，保证核心业务调用不受影响。

💖微服务实战

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

💖 Spring家族及微服务系列文章 

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨