Nacos尽可能减少用户部署以及运维成本，做到用户只需要⼀个程序包，就快速单机模式启动 Nacos 或集群模式启动 Nacos。而 Nacos 是⼀个需要存储数据的组件，为实现目标，就要在 Nacos 内部实现数据存储。单机问题不大，内嵌关系型数据库即可；但集群模式就要考虑保障各节点间的数据⼀致性及数据同步，就得引入共识算法，通过算法保障各节点间的数据⼀致性。
Nacos 在单个集群中同时运行 CP 协议及 AP 协议？要从 Nacos 场景出发：Nacos 集服务注册发现及配置管理于⼀体，集群下，各节点间的数据⼀致性保障问题，需拆分成两方面：
服务之间感知对方服务的当前可正常提供服务的实例信息，须从服务发现注册中心获取，因此对服务注册发现中心组件的可用性提出高要求，需在任何场景尽最大可能保证服务注册发现能力可以对外提供服务；同时 Nacos 的服务注册发现设计，采取了心跳可自动完成服务数据补偿的机制。如果数据丢失的话，是可以通过该机制快速弥补数据丢失。
为满足服务发现注册中心的可用性，强⼀致性共识算法不太合适，因为强⼀致性共识算法能否对外提供服务有要求，如当前集群可用节点数没过半，整个算法直接“罢工”，而最终⼀致共识算法更多保障服务可用性，并能保证在⼀定时间内各节点之间数据能达成⼀致。上述都是针对 Nacos 服务发现注册中的非持久化服务（即需客户端上报心跳进行服务实例续约）。
而对 Nacos 服务发现注册中的持久化服务，因为所有数据都是直接调用 Nacos服务端直接创建，因此需由 Nacos 保障数据在各节点间的强⼀致性，因此针对此类型的服务数据，选择强⼀致性共识算法来保障数据⼀致性。
配置数据直接在 Nacos 服务端进行创建并管理，须保证大部分的节点都保存此配置数据，才能认为配置被成功保存，否则就会丢失配置的变更，问题很严重，如发布重要配置变更出现丢失变更，多半引起严重现网故障，因此对配置数据的管理，须集群中大部分节点强⼀致，这里只能使用强⼀致性共识算法。
强⼀致性共识算法，当前最多使用 Raft 协议，易让人理解，并有很多成熟工业算法实现，如蚂蚁金服 JRaft、Zookeeper ZAB、Consul Raft、百度 braft、Apache Ratis；因为 Nacos 是 Java 技术栈，因此只能在 JRaft、ZAB、ApacheRatis 中选择，但ZAB 和 Zookeeper 强绑定，再加上希望可以和 Raft 算法库支持团队随时沟通交流，因此选择 JRaft，也因为 JRaft 支持多 RaftGroup，为 Nacos 后面的多数据分片带来可能。
而 Distro 协议是阿里巴巴自研的⼀个最终⼀致性协议，最终⼀致性协议很多如 Gossip、Eureka 内的数据同步算法。Distro 算法集 Gossip 及 Eureka 协议优点并优化而出，原生 Gossip由于随机选取发送消息的节点，不可避免存在消息重复发给同⼀节点情况，增加网络传输的压力，也给消息节点带来额外的处理负载，而 Distro 算法引入权威 Server 概念，每个节点负责⼀部分数据及将自己的数据同步给其他节点，有效降低消息冗余问题。
服务注册和配置管理⼀致性协议 分开，没下沉到 Nacos内核模块作为通用能力
因此必然要对 Nacos⼀致性协议做抽象及下沉，使其成为 Core 模块能力，彻底让服务注册发现模块只充当计算能力，同时为配置模块去外部数据库存储打下架构基础。
当前 Nacos 内核中，已将⼀致性协议的能力完全下沉到内核模块作为 Nacos 核心能力，很好的服务于服务注册发现模块及配置管理模块。
新 Nacos 架构将⼀致性协议从原先服务注册发现模块下沉到内核模块，并尽可能提供统⼀抽象接口，使上层的服务注册发现模块及配置管理模块，不再耦合任何⼀致性语义。
解耦抽象分层后，每个模块能快速演进，并且性能和可用性都大幅提升。
既然 Nacos 将 AP、CP 协议下沉到内核模块：
且尽可能保持了⼀样的使用体验。那这⼀致性协议下沉如何做到的？
其实，⼀致性协议，就是用来保证数据⼀致的，而数据的产生，必然有⼀个写入的动作；同时还要能够读数据，并且保证读数据的动作以及得到的数据结果，并且能够得到⼀致性协议的保障。因此，⼀致性协议最最基础的两个方法，就是写动作和读动作
public interface ConsistencyProtocol<T extends Config, P extends RequestProcessor> extends CommandOperations {
/**
* Obtain data according to the request.
*/
Response getData(ReadRequest request) throws Exception;
/**
* 同步数据提交，在 Datum 中已携带相应的数据操作信息
*/
Response write(WriteRequest request) throws Exception;
}任何使用⼀致性协议的，只需使用 getData 及 write 方法。
⼀致性协议抽象在 consistency 包，Nacos 对 AP、CP ⼀致性协议接口使用抽象都在，且实现具体⼀致性协议时，采用插件可插拔，进⼀步将⼀致性协议具体实现逻辑和服务注册发现、配置管理两个模块解耦。
package com.alibaba.nacos.core.distributed;
/**
* Conformance protocol management, responsible for managing the lifecycle of conformance protocols in Nacos.
*/
@SuppressWarnings("all")
@Component(value = "ProtocolManager")
public class ProtocolManager extends MemberChangeListener implements DisposableBean {
private void initAPProtocol() {
ApplicationUtils.getBeanIfExist(APProtocol.class, protocol -> {
Class configType = ClassUtils.resolveGenericType(protocol.getClass());
Config config = (Config) ApplicationUtils.getBean(configType);
injectMembers4AP(config);
protocol.init(config);
ProtocolManager.this.apProtocol = protocol;
});
}
private void initCPProtocol() {
ApplicationUtils.getBeanIfExist(CPProtocol.class, protocol -> {
Class configType = ClassUtils.resolveGenericType(protocol.getClass());
Config config = (Config) ApplicationUtils.getBean(configType);
injectMembers4CP(config);
protocol.init(config);
ProtocolManager.this.cpProtocol = protocol;
});
}
}仅做完⼀致性协议抽象还不够：
服务发现及配置模块，更应专注数据使用及计算，而非数据咋存储、咋保障数据⼀致性，数据存储及多节点⼀致问题应交由存储层保证。
为了：
Nacos又做数据存储抽象。
⼀致性协议是为保证数据⼀致，如利用⼀致性协议实现存储，那服务模块以及配置模块，就由原来的依赖⼀致性协议接口转为依赖存储接口，而存储接口后面具体实现就比⼀致性协议丰富，且服务模块、配置模块也无需为直接依赖⼀致性协议而承担多余编码工作（快照、状态机实现、数据同步）。使这两模块可更专注自己核心逻辑。对于数据抽象，这里仅以服务注册发现模块为例：
package com.alibaba.nacos.core.storage.kv;
public interface KvStorage {
enum KvType {
/**
* Local file storage.
*/
File,
/**
* Local memory storage.
*/
Memory,
/**
* RocksDB storage.
*/
RocksDB,
}
// ...
}由于 Nacos 的服务模块存储，更多是根据单或多个唯⼀ key 去执行点查，因此KV存储接口最适合。接口定义后，就是这KVStore具体实现。可直接将 KVStore 实现对接 Redis，DB或直接根据 Nacos 内核模块的⼀致性协议，在此基础之上，实现⼀个内存或者持久化的分布式强（弱）⼀致性 KV。
通过功能边界将 Nacos 进程进⼀步分离为计算逻辑层和存储逻辑层，计算层和存储层之间的交互仅通过薄薄数据操作胶水代码，就在单个 Nacos 进程里面实现计算、存储彻底分离。
进⼀步实现插件化的设计，对于中小公司且有运维成本要求的话，可以直接使用 Nacos 自带的内嵌分布式存储组件来部署⼀套 Nacos 集群。
服务实例数据以及配置数据的量级很大的话，并且本身有⼀套比较好的 Paas 层服务，那么完全可以复用已有的存储组件，实现 Nacos 的计算层与存储层彻底分离。
本文由博客一文多发平台 OpenWrite 发布！