一、Druid
Druid是Java语言中最好的数据库连接池。Druid能够提供强大的监控和扩展功能。
—— Alibaba
我们在项目集成 Druid 的主要目的也是在于其相对于同类框架来说更优异的数据库连接池性能，以及强大的监控面板。对于项目测试与运行阶段的故障与运行状态的跟踪与监测提供了很有力的帮助。通用的配置在网上可以找到很到，这里不再赘述，后续可能会再更新一些 Druid 实际应用的配置。
二、Flyway
Flyway是一个简单开源数据库版本控制器（约定大于配置），主要提供migrate、clean、info、validate、baseline、repair等命令。它支持 SQL（PL/SQL、T-SQL）方式和Java方式，支持命令行客户端等，还提供一系列的插件支持。
Flyway的功能很简单，目的也很明确——就是为了环境变化／多地部署时的数据库自动迁移（包括库表结构、数据、索引、序列等），以及版本迭代时数据库的自动同步迭代。SQL 脚本置入配置的路径后，将不再做任何变更，将数据库的迭代固化下来。
当然，理想很丰满，现实很骨感。个人感觉，Flyway 是 Spring Boot 组件里，比较不靠谱的那一种。
- 高版本的 Flyway 向前不兼容，想兼容就要银子（不是不能收费，只是在大的开源框架里突然出现这么个异类，很怪异；同时似乎也违背了 Flyway 作者当年的开发宣言）
- Flyway 具有平台敏感性。Windows / Unix 下换行符不同的编码，会直接导致看起来内容完全一致的 SQL 脚本计算出的校验值不同，从而导致 SQL 脚本校验失败继而服务无法启动
Flyway 在 Spring Boot 项目中的集成
- 依赖（gradle）
compile 'org.flywaydb:flyway-core'
目前项目采用的 Spring Boot 版本为 1.15.17，自动配置的 Flyway 版本号为 3.2.1。
- 配置
flyway:
enabled: true
locations: classpath:db/migration
baseline-on-migrate: true
- locations：保存 SQL 脚本的位置，必须位于 resource 路径下 。在库表结构出现分岔的情况下，此处的配置与分岔的版本一一对应，也无不可。
- baseline-on-migrate：对于已经建立了库表的旧项目，这里必须设置为
true
集成了 Flyway 的服务正常启动后，会自动在库里建立表schema_version，每一个 SQL 脚本一行数据，保存了脚本的版本号、校验值、描述等信息。[1]
- SQL 脚本的命名规范
V1.001__discription.sql
- 首字母标志了脚本的类型：
- V 只执行一次的脚本
- U 反执行脚本【无实践意义】
- R 发生变化就执行一次的脚本
- 首字母后为版本号
1.001，建议与代码版本号保持一致 -
__为分隔符，分隔符后为脚本的描述信息
- 换行符
如前所述，换行符可能导致脚本校验不通过；当同一个项目的开发人员使用的平台不一样时，尤其需要注意这个问题。从项目的实践来看，统一 IDE 与 git 的配置是一个不错的选择。
一般服务器都是 Unix 系统，故而统一使用 Unix 系统下的
LF 做为换行符。当使用 git 做为代码管理工具时，务必关闭 gitbash 的自动变更换行符功能：
git config --global core.autocrlf false
三、 Druid 与 Flyway 的集成与冲突
Flyway通过 SQL 脚本来执行数据库的建立与更新。当同时集成了 Druid 和 Flyway 之后，Druid 的 wall 防火墙极可能直接干预 SQL 脚本的操作，继而导致 Flyway 执行中断。在项目开发的过程中，配置了以下防火墙属性以放行 Flyway 的 SQL 操作[2]
spring:
datasource:
druid:
wall:
config:
variantCheck: false
noneBaseStatementAllow: true
commentAllow: true
multiStatementAllow: true
-
如果实在需要变更脚本，可以将更新后的脚本的新校验值覆盖到
scheme_version中，以规避服务不能启动的问题。新校验值可以从 变更脚本后服务启动失败 的日志中找到。当然极不建议如此操作。 ↩ -
视 SQL 脚本的不同，属性配置会有所变化。具体可以参考 Druid 的官方资料： Druid Wall Filter Config ↩
