各环境业务配置数据同步问题方案征求

[guguji]

场景

公司分四个开发环境 dev/uat/pre/pro 系统开发时，研发&测试会在 dev 配置完整，测试通过后，后续环境都需要手动配置一份，繁琐且容易出错

思路

参考 git branch 思路，dev 配置往 其他各个环境推进，无需再配置一遍，省时省力

难点

• 数据复杂，难做 diff：系统内配置设计多个表关数据，如果推下一个环境直接覆盖，有风险；做 diff 又很难展现
• 差异化数据同步：比如测试环境接口性能差，接口耗时需要设置 300ms ，生产性能好，只需要设置 100ms ，比较痛
• 任务冲突：迭代的任务在配置测试，此时生产需要 hotfix ，且入口只能从 dev 开始，此时如何保证基准和生产一致，且抹除迭代内的任务也不人性化
• 同步问题：由于数据复杂，没办法 ddl 同步，各环境沙盒，只能暴露 rest 接口调用，且需要考虑事务问题

老铁们有啥好的方案么？交流交流

说下目前的场景为何需要配置驱动话：
平台：BFF ，即聚合服务，配置元数据驱动
目标：C 端门面聚合服务，对 C 提供接口数据聚合 /解析 /吐出，向内拓扑聚合各 rpc 接口，解决平台侧服务频繁对接内部业务皆苦的繁琐工作，直接配置化

场景举例：页面 A, 需要一个接口数据，由下游业务 1-rpc ，业务 2-数仓推 hbase ，业务 3-rpc 拼接转换提供，
聚合服务这边只需配置页面，加数据包概念，数据包对应的数据源拓扑出三个业务分别查询，再依据接口文档约定解析返回，全程配置化，无需发版。

痛点：dev 配置并且测试完后，后续各个环境还是需要相应的人员配置一份，非常的苦逼！因为任何的配错或者漏掉，都可能导致 bug
所以急需一个配置分发功能，由测试稳定的环境推到各个环境，各环境保持元数据一致。

[xuanbg]

最简单也是最好的办法，使用配置中心来提供不同环境下的配置数据。

[guguji]

@xuanbg 主要是业务表配置的，举个例子，假设要配置一个活动，设计到圈人、价格、时间、渠道、投放等，这是一个完整打包的业务数据，没办法依赖配置中心。

[sujin190]

@xuanbg #1 配置中心才是坑死人的，如果把业务数据也放到配置中心来配置，然后测试开发生产都在一起，你确定不会分分钟搞崩生产环境？

运维、产品、运营、市场不同的配置不同人自己负责呗，为啥要 diff 同步，这种容易坑人，除了运维，其他的配置自身就是产品流程的一部分，功能设计的时候本来就要在产品流程中设计操作功能

你这既要动态配置有要求开发测试生产环境一致，本来就是静态功能，直接硬编码随着迭代正常发布测试就行吧，不需要可配自然也不需要同步，过度设计制造麻烦啊，测试开发应该只负责功能一致，谁负责的配置需求谁负责设置并完成回归测试呗，比如一个运营配置需求，刚上线时还没正式开放功能使用时你不让他自己弄一遍并完成回归测试，后面还不分分钟出事故啊

[securityCoding]

导出、导入？

[renmu]

@guguji 写成功能让运营配置去啊

[clf]

相关的业务自己写部署后的调用实施记录呗。可以由工具去主动调用。

[potatowish]

消息队列

[sujin190]

如果考虑到上线时配置过多，需要学习不容易快速完成，那么应该全部有默认配置，上线后先以默认配置运行，之后按需修改，业务配置的默认参数应该时依据运维环境相关配置动态生成，所以业务配置不会有环境相关不能直接以默认配置运行的情况，运维配置无非是数据地址域名什么的，不大可能需要配置非常多又不能一致的，而且吧设计的时候，默认配置一般是硬编码在代码里的，确实需要存数据库的，要么和正常配置数据分开存要么有独立标识代码里做兼容

总的来说，个人认为 diff 同步一致方案肯定是个坑，感觉不大可能有靠谱的方案的，除非你是配置完就再也不需要改了这种

[guguji]

@sujin190 我补充了一下背景，倒不是默认值问题，纯粹的元数据驱动系统，全程配置

[sujin190]

@guguji #9 看其实，我们写业务流程是直接写代码，你写业务流程是写配置，那么你需要一个模板引擎啊，开发配置时写模板，之后用对应的环境信息编译生成对应环境的配置设置到数据库之类的就好吧，模板就可以用 git 管理吧

[xuanbg]

@guguji 你这种业务数据，当然是存数据库啊