系统参数配置维护建议

背景

随着系统的发展和迭代，会有越来越多的业务配置参数存在于代码之中，大多数开发者会将此类参数放到项目配置文件中，或者枚举类中获取，但是对于一些变动率比较高的参数，放在以上位置，参数的变动可能需要进行代码的发布或者服务的重启

配置分类

根据个人观察及日常开发中发现的情况，配置需要细分为至少两类，且需要按照不通的方式进行维护

系统配置

系统配置可以理解为系统运行必须的配置，没有配置会直接导致系统无法启动或着运行，此类配置主要有:

• 数据库连接
• 中间件连接
• 系统组件配置

业务配置

在支撑业务过程中需要的配置项，即不影响系统整体启动和运行，只影响单一业务模块的参数，此类配置主要有:

• 第三方系统交互参数
• 某一业务场景中的必要参数
• 业务调整需要对应调整的参数

配置维护建议

系统配置

此类配置可以放在项目的配置文件中，因为一般此类参数变动大多数情况下都是需要应用重启生效或者停机发布的。此类信息几乎不需要业务开发过度介入，只是运维或者架构层面进行修改即可。

业务参数

建议放在表中维护，并添加缓存实现web化管理；
渣渣这边目前做的是，此类参数全部落表存储，

表字段

区分:业务场景，字段名称，参数key，参数值，上一次参数值，上一次操作人，上一次操作时间，落库时间，修改时间

代码实现

对外提供CRUD接口，增删改实时进行缓存更新，缓存key写入设置失效时间，防止错误数据误写入缓存后无法更新的问题
；缓存时最好使用一个配置一个key的方式，此类配置一般量级可能步到1000个，占据内容不大会特别大，之前有看到将系统所有的参数都设置到一个Hash中，空间没节省多少，但是对于任何一个参数变动，都要做Hash的全量覆盖更新，意义不大

意义

对于系统参数，维护人员可以是运维/架构
对于业务参数，可以抽成web页面，供业务方进行修改，可以解放业务开发人员。

写在最后

可能大家感觉这个事情是个小事，方案也是千篇一律的，但是目前发现在很多公司，存在系统参数和业务参数放在一起维护的情况，任何业务参数的修改都要业务开发人员去主导处理，非常耗时，浪费人效。