使用Azure SQL Data Sync在Azure 上實(shí)現(xiàn)藍(lán)綠部署

通過(guò)敏捷開(kāi)發(fā)自動(dòng)化部署實(shí)現(xiàn)產(chǎn)品的快速發(fā)布已經(jīng)成為大多數(shù)產(chǎn)品團(tuán)隊(duì)的共識(shí)。然而每次談到用藍(lán)綠部署來(lái)實(shí)現(xiàn)部署自動(dòng)化的時(shí)候，開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)都會(huì)提出同樣的疑問(wèn)，系統(tǒng)的web層和app層可以很容易地利用已有產(chǎn)品合技術(shù)部署成互相獨(dú)立的兩套系統(tǒng)來(lái)實(shí)現(xiàn)減少業(yè)務(wù)中斷快速發(fā)布產(chǎn)品，那應(yīng)用升級(jí)常見(jiàn)的數(shù)據(jù)庫(kù)schema的升級(jí)以及data convention，這時(shí)候藍(lán)綠部署又該如何實(shí)現(xiàn)呢？這里我們用Azure上的SQL PaaS為例來(lái)說(shuō)明整個(gè)實(shí)現(xiàn)。

如上所說(shuō)，藍(lán)綠部署通常是指同一系統(tǒng)的兩個(gè)并行并且完全獨(dú)立的生產(chǎn)環(huán)境，接受真實(shí)用戶流量的環(huán)境為藍(lán)棧。另一環(huán)境為綠棧。通常綠棧上承載著系統(tǒng)的最新版本，在測(cè)試通過(guò)后藍(lán)棧流量切換到綠棧，綠棧運(yùn)行穩(wěn)定后會(huì)成為新的生產(chǎn)藍(lán)棧。而原來(lái)的藍(lán)棧則被銷毀從而達(dá)到節(jié)約成本的目的。

我們先看一下最常見(jiàn)的發(fā)布流程

觸發(fā)CD的task創(chuàng)建和生產(chǎn)環(huán)境基礎(chǔ)架構(gòu)相同的綠棧（staging）

觸發(fā)CD的task在綠棧部署新版本應(yīng)用

觸發(fā)CD的task在綠棧做自動(dòng)化測(cè)試

觸發(fā)CD的task把流量從藍(lán)棧平滑切換到綠棧，綠棧成為新的藍(lán)棧

新藍(lán)棧運(yùn)行穩(wěn)定后，綠棧（原藍(lán)棧staging）被銷毀

整個(gè)流程如下圖所示：

這個(gè)方案雖然滿足了零宕機(jī)的需求但是存在以下問(wèn)題

新版本應(yīng)用部署時(shí)數(shù)據(jù)庫(kù)的升級(jí)是從版本零到最新版本，以上step3測(cè)試沒(méi)有覆蓋到生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)版本到最新版本的路徑測(cè)試，這樣新版本在生產(chǎn)環(huán)境順利運(yùn)行是存在隱患的

同樣，step3的測(cè)試是基于一個(gè)干凈的空的數(shù)據(jù)庫(kù)，沒(méi)有在真實(shí)或類真實(shí)數(shù)據(jù)之上做新版本測(cè)試

針對(duì)以上的問(wèn)題，我們?cè)倏匆幌碌诙N常見(jiàn)的發(fā)布流程

第二種常見(jiàn)發(fā)布流程

觸發(fā)CD的task創(chuàng)建和生產(chǎn)環(huán)境基礎(chǔ)架構(gòu)相同的綠棧（staging）該環(huán)境不含數(shù)據(jù)庫(kù)

觸發(fā)CD的task把綠棧應(yīng)用指向生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)并執(zhí)行所需的schema升級(jí)等事務(wù)

觸發(fā)CD的task在綠棧部署新版本應(yīng)用

觸發(fā)CD的task在綠棧做自動(dòng)化測(cè)試

觸發(fā)CD的task把流量從藍(lán)棧平滑切換到綠棧，綠棧成為新的藍(lán)棧

新藍(lán)棧運(yùn)行穩(wěn)定后，綠棧（原藍(lán)棧staging）被銷毀

整個(gè)流程如下圖所示。

這個(gè)方案存在以下問(wèn)題

雖然測(cè)試基于真實(shí)數(shù)據(jù)，但是也存在在生產(chǎn)環(huán)境上直接測(cè)試導(dǎo)致宕機(jī)的風(fēng)險(xiǎn)

發(fā)布的回滾只能回滾到step2這個(gè)節(jié)點(diǎn)之前的數(shù)據(jù)庫(kù)備份點(diǎn)，step2到回滾前的事務(wù)數(shù)據(jù)無(wú)法保留

好，我們?cè)倏匆幌碌谌N常見(jiàn)的發(fā)布流程。

第三種常見(jiàn)發(fā)布流程

觸發(fā)CD的task創(chuàng)建和生產(chǎn)環(huán)境基礎(chǔ)架構(gòu)相同的綠棧（staging）

觸發(fā)CD的task在綠棧的數(shù)據(jù)導(dǎo)入生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)的最新備份

觸發(fā)CD的task在綠棧部署新版本應(yīng)用

觸發(fā)CD的task在綠棧做自動(dòng)化測(cè)試

觸發(fā)CD的task把綠棧數(shù)據(jù)庫(kù)指向生產(chǎn)數(shù)據(jù)庫(kù)并執(zhí)行所需的schema升級(jí)等事務(wù)

觸發(fā)CD的task把流量從藍(lán)棧平滑切換到綠棧，綠棧成為新的藍(lán)棧

新藍(lán)棧運(yùn)行穩(wěn)定后，綠棧（原藍(lán)棧staging）被銷毀

整個(gè)流程如下圖所示。

這個(gè)方案還是存在以下問(wèn)題

雖然不再有污染真實(shí)環(huán)境數(shù)據(jù)的風(fēng)險(xiǎn)，但是發(fā)布回滾的時(shí)候依然會(huì)丟失相應(yīng)時(shí)間段的事務(wù)數(shù)據(jù)

一旦發(fā)生回滾，業(yè)務(wù)無(wú)法滿足零宕機(jī)的需要

總結(jié)以上三種藍(lán)綠部署的流程和已知問(wèn)題，可以得出藍(lán)綠部署的主要需求點(diǎn)是：

應(yīng)用發(fā)布零宕機(jī)

真實(shí)數(shù)據(jù)測(cè)試

事務(wù)數(shù)據(jù)無(wú)丟失

應(yīng)用回滾零宕機(jī)

我們以一個(gè)Azure SQL PaaS的系統(tǒng)為例看一下是如何滿足需求解決以上三種方案存在的問(wèn)題

解決以上三種方案存在的問(wèn)題

觸發(fā)CD的task創(chuàng)建和生產(chǎn)環(huán)境基礎(chǔ)架構(gòu)相同的綠棧（staging）

觸發(fā)CD的task在綠棧的數(shù)據(jù)導(dǎo)入生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)的最新備份

Enable從藍(lán)棧數(shù)據(jù)庫(kù)到綠棧數(shù)據(jù)庫(kù)Azure Sql PaaS的Data Sync功能使得生產(chǎn)數(shù)據(jù)庫(kù)實(shí)時(shí)re復(fù)制到綠棧

觸發(fā)CD的task在綠棧部署新版本應(yīng)用

觸發(fā)CD的task在綠棧做自動(dòng)化測(cè)試

觸發(fā)CD的task把流量從藍(lán)棧平滑切換到綠棧，綠棧成為新的藍(lán)棧

Enable從新藍(lán)棧數(shù)據(jù)庫(kù)到新綠棧數(shù)據(jù)庫(kù)Azure Sql PaaS的Data Sync功能

新藍(lán)棧運(yùn)行穩(wěn)定后，綠棧（原藍(lán)棧staging）被銷毀

整個(gè)流程如下圖所示。

可以看到step3加入Data Sync功能后，應(yīng)用的測(cè)試是在非生產(chǎn)環(huán)境但是和生產(chǎn)環(huán)境數(shù)據(jù)又是實(shí)時(shí)同步的真實(shí)的數(shù)據(jù)上進(jìn)行，不存在測(cè)試路徑覆蓋不全的問(wèn)題也不存在會(huì)導(dǎo)致生產(chǎn)環(huán)境宕機(jī)的風(fēng)險(xiǎn)。同時(shí)，在step7加入另外一個(gè)方向的Data Sync功能后，終端用戶在新藍(lán)棧發(fā)生的任何事務(wù)數(shù)據(jù)被回寫(xiě)到原有藍(lán)棧中。一旦需要回滾，不再需要花時(shí)間創(chuàng)建新數(shù)據(jù)庫(kù)并導(dǎo)入備份，只需要由CD task把流量從新藍(lán)棧切換到原來(lái)的藍(lán)棧即可，回滾也能實(shí)現(xiàn)零宕機(jī)。

那接下來(lái)我們就看一下如何配置Data Sync來(lái)實(shí)現(xiàn)以上的功能（Data Sync的原理可查閱https://docs.microsoft.com/en-us/azure/sql-database/sql-database-sync-data）

1首先創(chuàng)建2個(gè)Azure的Sql PaaS，其中一個(gè)生產(chǎn)環(huán)境的數(shù)據(jù)庫(kù)含有真實(shí)的數(shù)據(jù)，另外一個(gè)我們會(huì)用空的數(shù)據(jù)庫(kù)以便展示Data Sync的功能

Demotest1是生產(chǎn)庫(kù)藍(lán)棧

StagingDB是綠棧

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

Demotest1做為data sync的hub，每300秒會(huì)把數(shù)據(jù)從hub同步到member數(shù)據(jù)庫(kù)StagingDB

3.配置data sync group的member數(shù)據(jù)庫(kù)stagingdb

4.接下來(lái)，配置需要同步到綠棧的表和列，這里我們選擇全部的表和列

5.我們先看一下生產(chǎn)數(shù)據(jù)庫(kù)內(nèi)，現(xiàn)在使用azure portal的query editor功能就可以直接查詢數(shù)據(jù)庫(kù)

6.接著查詢一下綠棧數(shù)據(jù)庫(kù)，此時(shí)綠棧只有數(shù)據(jù)庫(kù)元數(shù)據(jù)

7.5分鐘后，再做一次查詢，這時(shí)可以看到數(shù)據(jù)開(kāi)始逐步同步到綠棧數(shù)據(jù)庫(kù)。新版應(yīng)用可以開(kāi)始測(cè)試

8.測(cè)試完成后即可平滑遷移生產(chǎn)環(huán)境流量

9.此時(shí)需要?jiǎng)h除原有data sync group，并配置從新的生產(chǎn)數(shù)據(jù)庫(kù)（hub）往舊生產(chǎn)數(shù)據(jù)庫(kù)（member）的data sync用于回滾切換

在整個(gè)流程中，需要注意以下幾點(diǎn)：

1.配置data sync時(shí)，沖突解決必須以承載生產(chǎn)環(huán)境的Hub數(shù)據(jù)庫(kù)為主，以免出現(xiàn)sequence沖突

2.在藍(lán)綠部署的流程里，無(wú)需配置所有表的data sync，考慮到member數(shù)據(jù)庫(kù)是采用生產(chǎn)數(shù)據(jù)庫(kù)中最近的備份為source，類似audit tail之類的系統(tǒng)table無(wú)需配置sync，有安全審核要求的除外。

3.在配置新的生產(chǎn)數(shù)據(jù)庫(kù)到舊生產(chǎn)數(shù)據(jù)庫(kù)的data sync時(shí)候，不能把新升級(jí)的Schema直接sync回舊生產(chǎn)庫(kù)，復(fù)雜的schema升級(jí)的場(chǎng)景建議采用data sync，需要采用支持table mapping和transformation rule的第三方軟件。

4.另外，data sync也有一些限制https://docs.microsoft.com/en-us/azure/sql-database/sql-database-sync-data，含有不適用于data sync的數(shù)據(jù)表和列的數(shù)據(jù)庫(kù)也不建議采用data sync來(lái)做藍(lán)綠部署