Spring Boot集成Flyway實現數據庫版本控制?

今天給你們介紹一款比較好用的數據庫版本控制工具Flyway。在經過Spring Boot構建微服務的過程當中,通常狀況下在拆分微服務的同時,也會按照系統功能的邊界對其依存的數據庫進行拆分。在這種狀況下,微服務的數據庫版本管理對於研發工程管理來講,就會是一個比較棘手的問題。sql

在正常的代碼管理流程中,從產品研發研發的過程看,通常會經歷功能開發、研發測試、集成測試、預發佈測試、上線等多個環節。而對於同一個產品功能,可能還會涉及對多個微服務代碼及數據庫結構的改動。數據庫

而這些改動須要咱們在以上流程中每發佈一個環境,都須要提早預置好數據庫結構變動的依賴。假設,咱們開發完成須要發佈到測試環境,那麼就須要咱們提早將改動的腳本在測試環境執行,測試環境完成測試後須要發佈到預發佈環境測試,也須要提早在預發佈環境執行腳本。以往,這種過程都依賴於人工執行,若是想要保持全部環境數據庫版本的一致性,很大程度上是須要依賴於人,環境比較少還好,但若是環境比較多的話,長此以往很容易就出現你們不維護的狀態了。只有某天在某個環境進行測試時出錯了,纔會猛然發現有些服務的數據庫變動腳本並無獲得執行,從而去補缺。bash

那麼有沒有一種比較智能的方式,在微服務啓動的時候,就能夠檢測到數據庫版本的變化,從而可以自動去執行變動的數據庫腳本,以此來保證除生產外的大部分環境的數據庫版本均可以自動一致呢?maven

答案是有多,市面上的方案也有一些,今天給你們介紹的是使用得比較普遍一點的Flyway。微服務

Flyway概述

Flyway是一款數據庫版本控制管理工具,功能上相似Git對代碼的版本控制。Flyway支持市面上幾乎全部的經常使用數據庫,如Mysql、Oracle、PostgreSQL等。經過Flyway的管理,咱們能夠很輕鬆的跨多個環境管理數據庫的schema及相關業務數據變動信息。例如,開發一個新功能建立一個新表,只須要將腳本按照規範的命名格式放置在項目的指定目錄,那麼應用就能夠經過Flyway自動檢測當前環境的數據庫版本,從而自動幫咱們完成相應環境的結構同步,而再也不須要像以前那樣手動執行。工具

除了數據庫schema結構的變動外,數據的變動也能夠經過這種方式同步,例如咱們在字典表新增了一條字典數據,相似地也能夠經過這種方式去管理同步數據變動記錄。測試

Spring Boot集成Flyway

在Spring Boot項目中使用Flyway是很是方便和簡單的。首先咱們須要引入Flyway的依賴及插件依賴,以下:spa

<!--引入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對於測試及開發環境數據庫版本的維護仍是很方便的,至於生產嘛,仍是建議經過一套流程約定,人工執行管理比較保險!

相關文章
相關標籤/搜索