來自：DevOps技術棧 作者：翁智華
出處：http：//adkx。net/9eigk
背景
單位的雲辦公相關係統沒有成熟的平滑釋出方案，導致每一次釋出都是直接釋出，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例項伺服器，保證它正常執行，如此迴圈，直到所有伺服器都發布。
進一步AB測試的最佳化
平滑釋出做完之後，確實給我帶來很大的便利，不用每次釋出都發公告，不重要的或者非功能性的內容釋出了就是了。
但是用久了，客戶量上去之後，又遇到一個問題，那就是每一次業務大變更，大型釋出都是直接釋出到生產，這樣可能存在風險。設計師設計的功能，使用者不一定完全接受，一旦上線新版本，收到一大堆的吐槽，都是使用者呀，如果能在小範圍人群內進行灰度試用，完成平穩的過度和使用反饋之後，最佳化後再上到生產會更好一點。
所以這邊需要思考和設計一套統一的技術方案，未來無論雲辦公還是其他的業務系統，都能透過灰度釋出在可指定的小範圍內先進行體驗和功能驗證。
基於上面的平滑，我們在Nginx反向代理伺服器上動心思，讓nginx來幫我們做ABTesting的方案。
以下是我們嘗試的幾種方案：
1、Nginx反向代理：來路IP策略
流程圖：
步驟：
1、進入雲辦公系統，進入Nginx反代伺服器
2、Nginx讀取來路IP的AB名單
3、根據IP AB名單進行流量轉發（名單A走特定例項，名單B走雲辦公原有叢集例項）
優缺點：
1、配置簡單，原資源平臺的灰度升級就是根據IP名單來劃分設計升級的
2、外部計算機很多都是非固定IP，這個適合在公司內網實現，比如只是配置公司內網的IP。
2、Nginx反向代理：$。Cookies策略
流程圖：
步驟
1、進入雲辦公系統，進入Nginx反代伺服器
2、Nginx讀取Http請求的Cokie的version資訊（也可以是別的key）
3、根據Key的版本來進行流量轉發（比如Version1。1走特定叢集，Version1。0走通用叢集例項）
優缺點：
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個系統已經根據該方案實現了。
END
