ers4AP(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又做数据存储抽象。
5 数据存储抽象
?致性协议是为保证数据?致，如利用?致性协议实现存储，那服务模块以及配置模块，就由原来的依赖?致性协议接口转为依赖存储接口，而存储接口后面具体实现就比?致性协议丰富，且服务模块、配置模块也无需为直接依赖?致性协议而承担多余编码工作（快照、状态机实现、数据同步）。使这两模块可更专注自己核心逻辑。对于数据抽象，这里仅以服务注册发现模块为例：
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 发布！