使用Azure SQL Data Sync在Azure 上實現藍綠部署

經過敏捷開發自動化部署實現產品的快速發佈已經成爲大多數產品團隊的共識。然而每次談到用藍綠部署來實現部署自動化的時候，開發和運維團隊都會提出一樣的疑問，系統的web層和app層能夠很容易地利用已有產品合技術部署成互相獨立的兩套系統來實現減小業務中斷快速發佈產品，那應用升級常見的數據庫schema的升級以及data convention，這時候藍綠部署又該如何實現呢？這裏咱們用Azure上的SQL PaaS爲例來講明整個實現

 

如上所說，藍綠部署一般是指同一系統的兩個並行而且徹底獨立的生產環境， 接受真實用戶流量的環境爲藍棧。另外一環境爲綠棧。一般綠棧上承載着系統的最新版本，在測試經過後藍棧流量切換到綠棧，綠棧運行穩定後會成爲新的生產藍棧。 而原來的藍棧則被銷燬從而達到節約成本的目的。

咱們先看一下最多見的發佈流程：

1. 觸發CD 的task建立和生產環境基礎架構相同的綠棧（staging）
2. 觸發CD 的task在綠棧部署新版本應用
3. 觸發CD的task在綠棧作自動化測試
4. 觸發CD的task把流量從藍棧平滑切換到綠棧，綠棧成爲新的藍棧
5. 新藍棧運行穩定後，綠棧（原藍棧staging）被銷燬

整個流程以下圖所示：

 

 

 

這個方案雖然知足了零宕機的需求可是存在如下問題

1． 新版本應用部署時數據庫的升級是從版本零到最新版本，以上step3測試沒有覆蓋到生產環境數據庫版本到最新版本的路徑測試，這樣新版本在生產環境順利運行是存在隱患的

2． 一樣，step3的測試是基於一個乾淨的空的數據庫，沒有在真實或類真實數據之上作新版本測試

 

針對以上的問題，咱們再看一下第二種常見的發佈流程

1. 觸發CD 的task建立和生產環境基礎架構相同的綠棧（staging）

該環境不含數據庫

1. 觸發CD的task把綠棧應用指向生產環境數據庫並執行所需的schema升級等事務
2. 觸發CD 的task在綠棧部署新版本應用
3. 觸發CD的task在綠棧作自動化測試
4. 觸發CD的task把流量從藍棧平滑切換到綠棧，綠棧成爲新的藍棧
5. 新藍棧運行穩定後，綠棧（原藍棧staging）被銷燬

整個流程以下圖所示。

 

 

這個方案存在如下問題

1． 雖然測試基於真實數據，可是也存在在生產環境上直接測試致使宕機的風險

2． 發佈的回滾只能回滾到step2這個節點以前的數據庫備份點，step2到回滾前的事務數據沒法保留

 

好，咱們再看一下第三種常見的發佈流程

1． 觸發CD 的task建立和生產環境基礎架構相同的綠棧（staging）

2． 觸發CD的task在綠棧的數據導入生產環境數據庫的最新備份

3． 觸發CD 的task在綠棧部署新版本應用

4． 觸發CD的task在綠棧作自動化測試

5． 觸發CD的task把綠棧數據庫指向生產數據庫並執行所需的schema升級等事務

6． 觸發CD的task把流量從藍棧平滑切換到綠棧，綠棧成爲新的藍棧

7． 新藍棧運行穩定後，綠棧（原藍棧staging）被銷燬

整個流程以下圖所示。

 

 

 

這個方案仍是存在如下問題

1． 雖然再也不有污染真實環境數據的風險，可是發佈回滾的時候依然會丟失相應時間段的事務數據

2． 一旦發生回滾，業務沒法知足零宕機的須要

 

總結以上三種藍綠部署的流程和已知問題，能夠得出藍綠部署的主要需求點是：

• 應用發佈零宕機
• 真實數據測試
• 事務數據無丟失
• 應用回滾零宕機

 

咱們以一個Azure SQL PaaS的系統爲例看一下是如何知足需求解決以上三種方案存在的問題

1． 觸發CD 的task建立和生產環境基礎架構相同的綠棧（staging）

2． 觸發CD的task在綠棧的數據導入生產環境數據庫的最新備份

3． Enable從藍棧數據庫到綠棧數據庫Azure Sql PaaS的Data Sync功能使得生產數據庫實時re複製到綠棧

4． 觸發CD 的task在綠棧部署新版本應用

5． 觸發CD的task在綠棧作自動化測試

6． 觸發CD的task把流量從藍棧平滑切換到綠棧，綠棧成爲新的藍棧

7． Enable重新藍棧數據庫到新綠棧數據庫Azure Sql PaaS的Data Sync功能

8． 新藍棧運行穩定後，綠棧（原藍棧staging）被銷燬

 

 整個流程以下圖所示。

 

能夠看到step3加入Data Sync功能後，應用的測試是在非生產環境可是和生產環境數據又是實時同步的真實的數據上進行，不存在測試路徑覆蓋不全的問題也不存在會致使生產環境宕機的風險。同時，在step7加入另一個方向的Data Sync功能後，終端用戶在新藍棧發生的任何事務數據被回寫到原有藍棧中。一旦須要回滾，再也不須要花時間建立新數據庫並導入備份，只須要由CD task把流量重新藍棧切換到原來的藍棧便可，回滾也能實現零宕機。

 

那接下來咱們就看一下如何配置Data Sync來實現以上的功能（Data Sync的原理可查閱https://docs.microsoft.com/en-us/azure/sql-database/sql-database-sync-data）

1. 首先建立2個Azure的Sql PaaS，其中一個生產環境的數據庫含有真實的數據，另一個咱們會用空的數據庫以便展現Data Sync的功能

 

 

Demotest1是生產庫藍棧

StagingDB是綠棧

 

　　2.　在Demotest1裏enable Sync to other databases功能

 

Demotest1作爲data sync的hub，每300秒會把數據從hub同步到member數據庫StagingDB

 

 

　　3.　配置data sync group的member數據庫stagingdb

 

 

　　4.　接下來，配置須要同步到綠棧的表和列，這裏咱們選擇所有的表和列

 

 

　　5.　咱們先看一下生產數據庫內，如今使用azure portal的query editor功能就能夠直接查詢數據庫

 

 

　　6.　接着查詢一下綠棧數據庫，此時綠棧只有數據庫元數據

 

　　7.　5分鐘後，再作一次查詢，這時能夠看到數據開始逐步同步到綠棧數據庫。新版應用能夠開始測試

·　   8.　測試完成後便可平滑遷移生產環境流量

　　9.　此時須要刪除原有data sync group，並配置重新的生產數據庫（hub）往舊生產數據庫（member）的data sync用於回滾切換

 

在整個流程中，須要注意如下幾點：

1， 配置data sync時，衝突解決必須以承載生產環境的Hub數據庫爲主，以避免出現sequence 衝突

2， 在藍綠部署的流程裏，無需配置全部表的data sync，考慮到member數據庫是採用生產數據庫中最近的備份爲source，相似audit tail之類的系統table無需配置sync，有安全審覈要求的除外。

3， 在配置新的生產數據庫到舊生產數據庫的data sync時候，不能把新升級的Schema直接sync回舊生產庫，複雜的schema升級的場景建議採用data sync，須要採用支持table mapping和transformation rule的第三方軟件。

4， 另外， data sync也有一些限制https://docs.microsoft.com/en-us/azure/sql-database/sql-database-sync-data，含有不適用於data sync的數據表和列的數據庫也不建議採用data sync來作藍綠部署