平滑釋出的介紹
背景
單位的雲辦公相關係統沒有成熟的平滑釋出方案，導致每一次釋出都是直接釋出，dll檔案或配置檔案的變更會引起站點的重啟。
雲辦公系統的常駐使用者有10000+，即使短短半分多鐘，也會收到一堆投訴。基於此，我們梳理了一套平滑釋出的方案。
實施方案
釋出流程
目的主要是為了釋出的時候能夠平滑釋出，所以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個系統已經根據該方案實現了
參考資料
https://github.com/CNSRE/ABTestingGateway ABTestingGateway
ABTestingGateway是新浪開源的一個動態路由系統。ABTestingGateway是一個可以動態設定分流策略的灰度釋出系統，工作在7層，
基於nginx和ngx-lua開發，使用redis作為分流策略資料庫，可以實現動態排程功能。