Nacos架构与原理：CAP一致性协议详解

Nacos架构与原理：CAP一致性协议详解

Nacos是一个集服务注册发现和配置管理于一体的组件，为了实现数据存储和一致性保障，它在单个集群中同时运行CP协议（Raft）和AP协议（Distro）。这种设计既满足了服务发现注册中心的高可用性需求，又保证了配置数据的强一致性。

为什么 Nacos 需要一致性协议

Nacos的目标是尽可能减少用户的部署和运维成本，支持单机模式和集群模式的启动。由于Nacos需要存储数据，因此在集群模式下，必须解决节点间的数据一致性和同步问题。这需要引入共识算法来保障数据一致性。

为什么 Nacos 选择了 Raft 以及 Distro

Nacos作为一个集服务注册发现和配置管理于一体的组件，需要从两个方面来考虑数据一致性保障：

从服务注册发现来看

• 对于非持久化服务（需要客户端上报心跳进行服务实例续约），由于采用了心跳可自动完成服务数据补偿的机制，因此更注重可用性，适合使用最终一致性共识算法。
• 对于持久化服务（直接通过Nacos服务端创建的数据），则需要保障数据在各个节点之间的强一致性，因此选择强一致性共识算法。

从配置管理来看

配置数据必须保证大部分节点都保存了此配置数据才能认为配置被成功保存，因此对于配置数据的管理，必须要求集群中大部分节点是强一致的，只能使用强一致性共识算法。

为什么是 Raft 和 Distro ？

Raft (CP模式)

• 选择原因：当前工业生产中使用最多的强一致性共识算法是Raft协议，它更容易理解且有多个成熟实现。Nacos作为Java技术栈项目，选择了支持多RaftGroup的JRaft，为后续的多数据分片提供了可能。

Distro （AP模式）

• 特点：Distro是阿里巴巴自研的最终一致性协议，通过引入权威Server的概念，有效降低了消息冗余问题，提高了网络传输效率。

Nacos 一致性协议的演进

早期的 Nacos 一致性协议

早期Nacos架构中，服务注册和配置管理的一致性协议是分开的，没有下沉到内核模块作为通用能力演进，导致服务注册发现模块逻辑复杂且难以维护。

当前 Nacos 的一致性协议层

当前Nacos已经将一致性协议能力下沉到内核模块，提供了统一的抽象接口，使得服务注册发现模块和配置管理模块不再需要耦合任何一致性语义，实现了计算存储的彻底分离。

Nacos 如何做到一致性协议下沉

• 一致性协议抽象：将一致性协议抽象为基本的读写操作，通过插件化设计实现解耦。
• 数据存储抽象：通过KVStore接口实现存储抽象，使得服务模块和配置模块可以专注于核心逻辑，而将数据存储和一致性问题交给存储层处理。

通过这些改进，Nacos实现了计算和存储的逻辑分离，提高了系统的性能和可用性。