2019-11-20 19:27:03 劉能搬磚

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

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

而這些改動需要我們在以上流程中每發佈一個環境，都需要提前預置好數據庫結構變更的依賴。假設，我們開發完成需要發佈到測試環境，那麼就需要我們提前將改動的腳本在測試環境執行，測試環境完成測試後需要發佈到預發佈環境測試，也需要提前在預發佈環境執行腳本。以往，這種過程都依賴於人工執行，如果想要保持所有環境數據庫版本的一致性，很大程度上是需要依賴於人，環境比較少還好，但如果環境比較多的話，久而久之很容易就出現大家不維護的狀態了。只有某天在某個環境進行測試時出錯了，才會猛然發現有些服務的數據庫變更腳本並沒有得到執行，從而去補缺。

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

答案是有多，市面上的方案也有一些，今天給大家介紹的是使用得比較廣泛一點的Flyway。

Flyway概述

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

除了數據庫schema結構的變更外，數據的變更也可以通過這種方式同步，例如我們在字典表新增了一條字典數據，類似地也可以通過這種方式去管理同步數據變更記錄。

Spring Boot集成Flyway

在Spring Boot項目中使用Flyway是非常方便和簡單的。首先我們需要引入Flyway的依賴及插件依賴，如下：


<dependency>
 <groupid>org.flywaydb/<groupid>
 <artifactid>flyway-core/<artifactid>
 <version>5.0.3/<version>
/<dependency>

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

分享到:

閱讀更多 劉能搬磚 的文章

關鍵字: PostgreSQL 數據庫腳本語言