系統架構設計：平滑發布和ABTesting

平滑發布的介紹

背景

單位的雲辦公相關係統沒有成熟的平滑發布方案，導致每一次發布都是直接發布，dll文件或配置文件的變更會引起站點的重啟。

雲辦公系統的常駐用戶有10000+，即使短短半分多鐘，也會收到一堆投訴。基於此，我們梳理了一套平滑發布的方案。

實施方案

1、跟nginx代理伺服器約定了一個健康檢查的介面

2、通過介面返回的http狀態碼來讓ngx是否分流用戶請求（這個我們單位的技術部那邊有標準的做法）

3、根據提供的這個服務健康檢查的介面：nginx判斷只要某個實例的介面返回5xx的狀態碼，即把該實例下線（nginx不會把流量轉發到該實例）

發布流程

目的主要是為了發布的時候能夠平滑發布，所以QA與開發人員在發布得時候按照如下步驟操作：

1、打開系統的nginx列表管理頁面：[/publish/ngxconfig]

2、下架某一個實例（假設系統集群有A、B、C個實例），比如A實例

3、查看是否下架成功：這個就是我們跟nginx約定的健康檢查介面，正常在線狀態下是200的statu，切離線後，這個介面返回的是401的statu。

在線情況：

離線情況：

4、觀察監控站點，直至該實例下的Req、Connnectiuon流量都消失

5、在該實例下進行版本發布

6、打開Fidller，host到待發布的實例，然後判斷是否發布成功（發布dll、配置文件時，IIS站點會短暫重啟）

7、QA同學走查灰度的A實例伺服器，保證它正常運行，如此循環，直到所有伺服器都發布。

進一步ABTesting的優化

背景

平滑發布做完之後，確實給我帶來很大的便利，不用每次發布都發公告，不重要的或者非功能性的內容發布了就是了。

但是用久了，客戶量上去之後，又遇到一個問題，那就是每一次業務大變更，大型發布都是直接發布到生產，這樣可能存在風險。設計師設計的功能，用戶不一定完全接受，一旦上線新版本，

收到一大堆的吐槽，都是用戶呀，如果能在小範圍人群內進行灰度試用，完成平穩的過度和使用回饋之後，優化後再上到生產會更好一點。

所以這邊需要思考和設計一套統一的技術方案，未來無論雲辦公還是其他的業務系統，都能通過灰度發布在可指定的小範圍內先進行體驗和功能驗證。

基於上面的平滑，我們在Nginx反向代理伺服器上動心思，讓nginx來幫我們做ABTesting的方案。以下是我們嘗試的幾種方案：

1、Nginx反向代理：來路IP策略

流程

步驟

1、進入雲辦公系統，進入Nginx反代伺服器

2、Nginx讀取來路IP的AB名單

3、根據IP AB名單進行流量轉發(名單A走特定實例，名單B走雲辦公原有集群實例)

server {
listen 80;
server_name officecloud.com;
access_log officecloud.com/logs main;
ip_list 192.168.254.4,192.168.254.170

set $group default;
if ($remote_addr in iplist) {
set $group ACluster;
}

location / { 
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
index index.html index.htm;
}
}

優缺點

1、配置簡單，原資源平台的灰度升級就是根據IP名單來劃分設計升級的

2、外部電腦很多都是非固定IP，這個適合在公司內網實現，比如只是配置公司內網的IP。

2、Nginx反向代理：$.Cookies策略

流程

步驟

1、進入雲辦公系統，進入Nginx反代伺服器

2、Nginx讀取Http請求的Cokie的version資訊（也可以是別的key）

3、根據Key的版本來進行流量轉發(比如Version1.1走特定集群，Version1.0走通用集群實例)

server {
listen 80;
server_name officecloud.com;
access_log officecloud.com/logs main;
ip_list 192.168.254.4,192.168.254.170

set $group default;
if ($http_cookie ~* "version=V1.0"){
set default;
}
if ($http_cookie ~* "version=V1.1"){
set $group ACluster;
}

location / { 
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
index index.html index.htm;
}
}

優缺點

1、配置簡單，根據Nginx的 $COOKIE_version 屬性來判斷

2、相對穩定，對需要開放名單的用戶，在Cookie頭部加入特定的版本即可，應用只要少許的開發量

3、首次訪問靜態頁面可能不會產生cookie

備註：這是團隊內認為最好的Nginx代理方案，同理，User-Agent和Header都可以做此種類型的判斷，但是Header需要侵入底層HttpRequest去業務添加，不建議。

3、AB集群+業務代理方式

流程

步驟

1、進入雲辦公系統，兩種方式進入系統，一種是登錄頁登錄：~/login ，一種是default頁面帶uckey登錄：~/default?usertoken=#usertoken#

2、登錄的時候和usertoken傳入的時候進去路由代理模組,進行用戶資訊校驗，根據不同的人員和部門(人員和部門配置歸屬AB名單)分流到兩個不同的AB集群

3、根據轉發跳到具體的實例集群域名下（可以配置AB集群擁有不同域名,更容易區分）

優缺點

1、與Nginx剝離，不用依賴公司的通用平台和技術部的實現

2、需要申請AB集群，AB集群擁有不同的域名。

3、如果是前後端分離情況下，需要保證靜態站點和服務站點均申請AB集群

4、所有入口需要統一做代理，有一定的開發量

應用

目前手上2個系統已經根據該方案實現了

參考資料

//github.com/CNSRE/ABTestingGateway ABTestingGateway

ABTestingGateway是新浪開源的一個動態路由系統。ABTestingGateway是一個可以動態設置分流策略的灰度發布系統，工作在7層，

基於nginx和ngx-lua開發，使用redis作為分流策略資料庫，可以實現動態調度功能。

Tags: 平滑發布灰度測試系統架構設計