在引入 Nacos 配置中心之前,项目中配置都直接使用数据表,慢慢积累了十几张用于配置的表,操作配置严重依赖开发手动提 SQL. 为了统一管理配置,加上提效的目的,我们想做一个自己的配置后台,即使之后引入了 Nacos 也可以通过这个后台来间接集成 Nacos 配置管理的功能 (不打算直接暴漏 Nacos 的后台控制面板)
# 模型
# 元数据表
create table tt.biz_config_metadata
(
id bigint auto_increment primary key,
source varchar(64) default '' not null comment '配置的数据源, {库名.表名}',
config_key varchar(64) default '' not null comment '配置 key, 用于动态表单的创建, 一般对应数据源相关表的字段名称, __config__ 代表该整个数据源的配置',
sort int default 0 not null comment '字段展示的排序',
label varchar(64) default '' not null comment '配置名称, 用于列表、详情展示',
description varchar(255) default '' not null comment '配置字段的描述',
searchable tinyint default 0 not null comment '是否允许搜索',
editable tinyint default 0 not null comment '是否允许编辑',
key_type varchar(64) default '' not null comment '配置字段的类型',
default_value varchar(255) default '' not null comment '配置字段的默认值',
nullable tinyint default 0 not null comment '是否允许为空',
on_update_current_timestamp tinyint default 0 not null comment '更新记录是否自动更新时间',
display_scope varchar(3) default '111' not null comment '字段的显示范围,000 不显示 001 在列表中显示 010 在编辑中显示 100 在创建中显示...',
constraints text charset utf8mb4 null comment '配置的其它约束, 比如范围约束',
create_time datetime default CURRENT_TIMESTAMP not null comment '创建时间',
update_time datetime default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '更新时间',
constraint uk_source_config_key unique (source, config_key)
)
comment '业务配置表的元数据';
每个业务表中的字段都会对应一条 source + config_key 的记录 我们也可以指定一个特殊的 config_key 来代表业务表全局的信息,如表名、唯一索引等。
同时这张元数据表的维护可以做到 自举,元数据表本身就是一张配置表,也有自己的元数据,可以一键生成某张表的元数据(生成后需要手动校验下),当已有元数据发生字段变化的时候,也可以编辑元数据。
这一系列元数据就可以结合动态表单来实现我们抽象出来的四个配置管理的功能:列表、详情、新增、编辑
# 操作
为了保证操作安全性,可以采用 JSON Schema 来校验复杂的 JSON 配置
动态 SQL 的操作,所有的 SQL 表名、字段都必须和元数据校验,防止 SQL 注入和越界非法访问表数据。
操作日志审计功能
结合 Netflix/archaius 来读取配置
...