一、背景
在软件开发过程中有很多配置和一些字典数据需要进行管理，大多数处理方案都显得比较定制化，有些配置来源于数据库，有些就写在代码里，比较散乱，同时对于一些复杂的树形结构等也无法抽象一个通用的数据结构进行简化。因此需要一个相对通用的简单方案来管理这些kv类数据。
这个组件是接着这篇文章《用一个极致简单的场景演练领域建模》进行设计的,算是兄弟篇了，根据不同业务场景实现不同的业务场景Service能力。从组件的应用架构图上看，麻雀虽小，五脏俱全。这个组件可以方便的进行集成和二次开发，基本可以作为组件小而美的典型。
二、需求
2.1 KV 场景支持
-
支持简单KV类模型
-
支持三元组模型
-
支持按某一维度分组
-
支持存在父子级关心的数据kv模型
-
支持作为某个数据表记录的扩展字段
-
支持value是JSON字符串和JSON对象的能力
2.2 读写数据源场景支持
-
优先支持数据库存储
-
KVService CURD场景支持
-
从远程服务中读写配置(redis,remote config)需要二次开发
-
从本地读取配置(properties,enum)需要二次开发
2.3 组件交付内容
-
组件KV模型
-
组件持久化DAO和Mapper
-
组件DDL脚本
-
组件统一服务接口
三、技术设计&实现
3.1 组件应用架构图
从上面看主要分为五层，看着非常简单但是也有一点点技术含量.
-
统一API层 ：屏蔽KV内部场景服务的差异方便接入和集成
-
场景层：主要描述支持哪些场景
-
模型层: 根据不同场景来构建不同的KVPair对象,外部统一由KVPairBO做业务对象引用和操作
-
能力服务层：上面四个服务是针对不同场景做的个性化服务方法逻辑
下面四个服务是针对于不同的KV数据来源做的适配性服务方法逻辑，目前只实现了支持DB读写相关的逻辑
其他的可以按自己的场景分别实现即可接入。 -
持久层：为了方便用户接入和使用，这里做了持久层模型和接口相关的支持。
3.2 组件模块简介
-
kv-component
kv组件的核心模块,kv模型和service都在这里维护
-
kv-component-web
kv组件的springboot服务,二次开发可以通过spring-controller来测试二次开发的逻辑
3.3 KV模型和KVApi接口
四、总结
4.1 优缺点
优点：支持所有kv场景的数据管理
缺点: 不能大规模的管理KV数据，比如非常复杂的JSON，非常多的分组情况，这样可能会引起混乱，容易耦合
4.2 更多场景支持
-
多对多引用,把关系作为一方的扩展字段
-
一对多引用,把关系作为一方的扩展字段
一方或者另外一方对多方的引用可以按分组和对象扩展引用的方式进行管理
-
聚合对象的快照存储
-
树形结构的快照存储
-
项目链接地址：
https://gitee.com/sky-painting/component-kv
原文始发于微信公众号（神帅的架构实战）：component-kv设计与实现
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/241582.html
