Spring Boot集成Flyway实现数据库版本控制？

今天给你们介绍一款比较好用的数据库版本控制工具Flyway。在经过Spring Boot构建微服务的过程当中，通常状况下在拆分微服务的同时，也会按照系统功能的边界对其依存的数据库进行拆分。在这种状况下，微服务的数据库版本管理对于研发工程管理来讲，就会是一个比较棘手的问题。

在正常的代码管理流程中，从产品研发研发的过程看，通常会经历功能开发、研发测试、集成测试、预发布测试、上线等多个环节。而对于同一个产品功能，可能还会涉及对多个微服务代码及数据库结构的改动。

而这些改动须要咱们在以上流程中每发布一个环境，都须要提早预置好数据库结构变动的依赖。假设，咱们开发完成须要发布到测试环境，那么就须要咱们提早将改动的脚本在测试环境执行，测试环境完成测试后须要发布到预发布环境测试，也须要提早在预发布环境执行脚本。以往，这种过程都依赖于人工执行，若是想要保持全部环境数据库版本的一致性，很大程度上是须要依赖于人，环境比较少还好，但若是环境比较多的话，长此以往很容易就出现你们不维护的状态了。只有某天在某个环境进行测试时出错了，才会猛然发现有些服务的数据库变动脚本并无获得执行，从而去补缺。

那么有没有一种比较智能的方式，在微服务启动的时候，就能够检测到数据库版本的变化，从而可以自动去执行变动的数据库脚本，以此来保证除生产外的大部分环境的数据库版本均可以自动一致呢？

答案是有多，市面上的方案也有一些，今天给你们介绍的是使用得比较普遍一点的Flyway。

Flyway概述

Flyway是一款数据库版本控制管理工具，功能上相似Git对代码的版本控制。Flyway支持市面上几乎全部的经常使用数据库，如Mysql、Oracle、PostgreSQL等。经过Flyway的管理，咱们能够很轻松的跨多个环境管理数据库的schema及相关业务数据变动信息。例如，开发一个新功能建立一个新表，只须要将脚本按照规范的命名格式放置在项目的指定目录，那么应用就能够经过Flyway自动检测当前环境的数据库版本，从而自动帮咱们完成相应环境的结构同步，而再也不须要像以前那样手动执行。

除了数据库schema结构的变动外，数据的变动也能够经过这种方式同步，例如咱们在字典表新增了一条字典数据，相似地也能够经过这种方式去管理同步数据变动记录。

Spring Boot集成Flyway

在Spring Boot项目中使用Flyway是很是方便和简单的。首先咱们须要引入Flyway的依赖及插件依赖，以下：

<!--引入flyway的依赖-->
<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
    <version>5.0.3</version>
</dependency>
复制代码

<!--flyway插件依赖-->
 <plugin>
     <groupId>org.flywaydb</groupId>
     <artifactId>flyway-maven-plugin</artifactId>
     <version>5.0.3</version>
 </plugin>
复制代码

至此，咱们就完成了Spring Boot项目对Flyway的集成，是否是很简单呢！完成Flyway的集成后，咱们的数据库脚本须要怎么管理才能被Flyway自动识别并获得正确执行呢？

咱们须要在项目在resources中创建db/migration文件夹，并经过V1.0__init.sql（是__而不是_)相似这样的命名方式来命名咱们每次须要变动的数据库脚本。例如咱们建立了一个全新的项目，那么咱们就能够把这个项目的初始化数据库脚本放到这里，如：V1.0__init_database.sql。

这样，若是你此时链接一个全新的数据库，启动Spring Boot项目Flyway就会自动去扫描db/migration目录下未被执行的脚本，从而帮你完成数据库脚本的同步。随着功能的开发，假设有一个新的数据库变动须要执行，那么咱们就须要再创建一个新的脚本文件，如：V1.1__add_dictdata.sql这样，下次启动项目的时候，这个脚本也就会自动执行了。关于数据脚本的命名规范除了V1.1这样的版本号以外，后面的部分你们能够根据变动的类型起一个有意义、相对规范的名字便可。

说到这里，是否是有点疑惑，Flyway究竟是怎么作才能作到对数据库版本的管理的呢？事实上，若是咱们首次集成Flyway,启动项目后Flyway会在对应的数据库中建立一张名为"flyway_schema_history"的表，这种表就会记录全部脚本版本的执行状况，如：

也就是说，实际上Flyway对数据库脚本版本的控制彻底是依赖于维护了这样一张信息表。假设有个脚本已经被成功执行过，若是咱们人为的删除这种表中的执行记录，会怎么样呢？答案是，Flyway会再次执行，而且由于执行过，若是脚本中有重建表的SQL，那么极可能会形成数据丢失的状况，因此使用Flyway对于这种表的维护是相当重要的，切记切记！

另外，大多数状况下，咱们在使用Flyway以前，可能数据库已经执行过了一些脚本，若是此时要从新将其管理起来，而且想达到以前执行过的脚本再也不自动执行的效果的话，此时可能就须要咱们手工在***flyway_schema_history***表中插入对应的脚本执行版本记录，从而临时绕开下Flyway了。

后记

Flyway是一个比较自动化的数据库版本控制工具，用好了会方便咱们开发提升研发效率，另外一方面，再好的工具也在于人怎么使用，若是没有一套完整的操做规范，太自动的工具也可能会带来灾难，如重要的数据被重建致使丢失的状况！因此，大部分状况下Flyway对于测试及开发环境数据库版本的维护仍是很方便的，至于生产嘛，仍是建议经过一套流程约定，人工执行管理比较保险！