请问下，微服务化的应用，大量的 sql 更新怎么控制的呢？

[clacf]

背景：我们公司的业务都是微服务化的，大概上百个服务。分成 10 个产品线的样子。由于测试，迭代，镜像版本持续更新。看镜像仓库，能够看到上百个小版本。现在做私有化部署，根本没法知道什么版本该用什么 sql ，至于后续的升级更是一团乱麻。当前能做的就是从生产环境拉下来数据库，脱敏处理后，直接部署。但是会造成很多报错，每次调测都耗费大量的人力

需求: 不知道各位什么方法，能够管控起来如此众多的 sql 提交。我这边有两种方案:
1. 开发各自管理自己的应用，每次定版后，必须携带数据库 sql 目录，目录下必须包含全量初始化数据，以及上一个版本到这个版本的增量数据。但是这个涉及到开发的配合问题，没法强制管理起来。
2. 开发把数据库校验写道自己的应用中，每次部署，自动检测是升级，还是全量初始化。（这个肯定最漂亮，但是不知道实现起来，技术难度高不高）
3. 数据库严格控制权限。开发想更新，必须要走专用管控流程，提交经过审核后，才能够同步到测试库。将来部署的时候，可以回溯所有的版本。

各位大哥，有木有好点子可以提供下呢?

[lasuar]

大量的 sql 是指 少量多次，还是一次很多？前者就加入版本化管理，后者由组长或数据库权限掌控者审核后直接执行。

私有化部署，不是直接复制目前线上环境的数据表和代码吗？为什么要关注旧版本？

[clacf]

@lasuar #1
1. 每天少量多次推送到测试环境。每个月的一次迭代中会一次同步大批量 sql 到生产中。
2. 线上环境，存在客户的信息。没法直接复制，脏数据清理非常耗时，各种关联。卖给私有化客户，肯定得尽量干干净净。

[aboat365]

你的问题是数据库版本控制？如果是，有大量的文章告诉你如何做，你只需要找到适合自己团队的方法即可。你提到每次升级都耗费大量人力，实际上没有办法能大量减少人力的消耗，因为这就是版本升级必须付出的代价。无非就是一些规范和步骤让这些事情做起来更有条理，避免遗漏。数据库版本控制有一些工具可以进行辅助，比如数据库结构比对，迁移脚本，数据库变更审计。总而言之，只能把版本发布工作做的更有条理，而不能大量压缩时间。顺便推荐一下我开发的 IDEA 插件《 Database Buddy 》,可以比对两个数据库的结构差异，并生成迁移脚本。

[lasuar]

第一点，这个是需要加入版本化管理的。
第二点，只能提前整理好清理表的 sql 。

[clacf]

@lasuar #4 这些都得协调大量的开发，统一这么干。需要想下怎么约束和审计。

[clacf]

@aboat365 #3 谢谢，领教了

[lasuar]

第一点，在 sql 管理时需要进一步的优化，比如将 sql 按库/表分版本/文件存放，例如 sqls/v1.0.0/db_biz/t_user.sql ，这样在迭代时方便管理。另一个方式分需求目录存放，可以减少冲突。