互連網產品發布之灰階發布

標籤：

1. 為什麼要灰階發布

1. 互連網服務變動頻繁，發布周期短。速度與品質總是難以雙全。
2. 灰階發布能降低發布風險，減少影響範圍。
3. 降低對測試的依賴，減少線下自測的資料構造成本。
4. 方便集中監控日誌，全量發布由於各層負載平衡的作用，很難跟蹤一條完整的調用鏈路。
5. 可以灰階測試帳號，測試賬戶通過之後再灰階真實使用者帳號，進一步降低發布的風險和影響。
6. 方便復原。

不能靠灰階發布解決的問題

需要強調的是：上文所說的“可以容忍的影響”必須是可恢複的，比如API無法調用一段時間，但是修複之後，就可以成功調用。而永久性地丟失或者破壞使用者資料（比如商品資訊、訂單資訊等），則是不能容忍的。因此，互連網企業的架構師有責任通過設計完善的後備措施（比如使用者資料的定期備份、寫操作的業務流水日誌等），在生產系統錯亂導致丟失使用者資料的情況下，仍能夠通過人工幹預，根據記錄（備份資料、流水日誌等），把丟失的使用者資料修複至不久之前（比如一小時前至一周前）的狀態。

TIPS 先灰階測試帳號的灰階策略，可以降低破壞或者丟失真實使用者的資料的風險。

2. 期望達到什麼效果

不管是那種變更，我們都希望特定的請求能夠路由到我們的變更版本（灰階版本），以便觀察和驗證。

3. 灰階策略

其實就是什麼的請求應該路由到我們的灰階版本（灰階機器）上來。這個往往是業務強相關的。比如對於API來說，一般有如下幾個需求：

1. 特定使用者（比如測試帳號）
2. 特定的App（比如測試app或者合作App）
3. 特定的模組、介面（只有某些介面需要灰階，這種一般是API Container的修改，拿一些不是很重要的API做灰階測試。）
4. 特定的機器（某些請求IP轉寄到灰階機）

4. 灰階方案探討方案一、代碼層級通過對約定好的flag判斷，動態進行新老切換——Amazon的做法

實現：

在代碼中埋開關，做if-else判斷，對於需要灰階的機器，設定開關為on，否則為off。每次版本發布都是有兩個版本。

優點

• 快速復原，不需要重新發布和重啟系統。

缺點

• 對代碼有傾入性。
• 分支邏輯，帶來複雜性。

這種方式筆者曾經應用過，就是在阿里的時候把商品的資料庫從Oracle切換到MySql，使用了一個狀態變數進行控制。從而打到平滑遷移的效果。

方案二、預發布機——Alibaba的做法

其實這個不是真正意義上的灰階。因為這個預先發布機器是內部IP，沒有對外服務的。需要綁定網域名稱進行驗證。但是資料是完全的線上。所以本質上是灰階某些特定使用者（可以訪問灰階機器的使用者，自我裝載使用者）的一種簡單做法。其實API這邊也有類似的做法，就是我們的Gamma環境，而且我們還提供了Gamma機器的網域名稱，方便外部合作使用者配合測試。

優點

• 簡單

缺點

• 浪費一台機器（這個可以預先發布完成之後投入正式環境，預發布的時候從nginx摘除，不過需要營運支援。）
• 不夠靈活
• 只能針對接入層機器，IDL服務灰階需要另外考慮。

方案三、SET部署1. 按照業務隔離部署

比如現在API Container的做法，部署的粒度可以到API層級，前端根據nginx進行轉寄。比如：

• 微購物 API Container: api.weigou.qq.com
• 拍拍 API Container：api.paipai.com
• 易迅 API Container: api.yixun.com
• 網購 API Container：api.buy.qq.com

上面是大業務層級的隔離部署。還可以進一步細化到模組層級別，比如虛擬服務電商的API，是掛在拍拍下面的一個子業務模組，但是由於他們接入之後，訪問量大增，為了避免影響拍拍其他業務，也為了避免受其他業務影響，API這裡是給他們單獨部署了兩台機器，nginx配置一下就可以將針對虛擬API訪問引流過來了：

虛擬API Container：http://api.paipai.com/v2/virbiz

這樣，我們在發布一個版本的時候，可以先選擇業務量最小的易迅進行發布，觀察沒有問題再全量其他平台。

2. 按照使用者隔離部署

這個對於開放平台來說不是很適合，不過對於SNS這種應用情境就很合適了。比如QQ系統，按照使用者號碼段分為若干個set，每個set包含連續1億個號碼的使用者。假設現在最新的QQ號碼接近10億，則總共有10個set（Set 1到Set 10）。這樣每次可以選擇其中一個SET進行發布，而且高位QQ往往是不是很重要的使用者，所以會先發布SET10。

優點

• 隔離部署，各個業務線影響最小。自動支援灰階發布。

缺點

• 灰階的粒度取決於隔離部署的粒度，一般會偏大。
• 相對於集中式部署比較浪費機器。
• 各個業務線版本可能不一致，不利於統一管理。
• 有一定的實現和部署成本

方案四、動態路由

方法：採用一個可以靈活配置的灰階策略，影響Load Balance的行為，讓其根據灰階策略，返回灰階服務的IP和連接埠。

適合與後台IDL的服務灰階。

優點

• 靈活，可控。

缺點

• 現在的配置中心和L5本身沒有考慮指定路由策略，且不具有擴充性，需要在其外邊開發。
• API的中繼資料來源比較分散，目前 API和IDL中繼資料，API等級和頻率限制 分布在不同的資料來源，現在需要增加一個 灰階路由 資料來源。

 

 

灰階發布一般有三種方式 nginx+lua，nginx根據cookie分流，nginx 根據權重來分配：
nginx+lua根據來訪者ip地址區分，由於公司出口是一個ip地址，會出現訪問網站要麼都是老版，要麼都是新版，採用這種方式並不適合
nginx 根據權重來分配，實現很簡單，也可以嘗試
nginx根據cookie分流，灰階發布基於使用者才更合理

互連網產品發布之灰階發布