平滑發(fā)布的介紹

背景

單位的云辦公相關(guān)系統(tǒng)沒有成熟的平滑發(fā)布方案，導(dǎo)致每一次發(fā)布都是直接發(fā)布，dll文件或配置文件的變更會引起站點的重啟。

云辦公系統(tǒng)的常駐用戶有10000 ，即使短短半分多鐘，也會收到一堆投訴?；诖耍覀兪崂砹艘惶灼交l(fā)布的方案。

實施方案

1、跟nginx代理服務(wù)器約定了一個健康檢查的接口

2、通過接口返回的http狀態(tài)碼來讓ngx是否分流用戶請求（這個我們單位的技術(shù)部那邊有標(biāo)準(zhǔn)的做法）

3、根據(jù)提供的這個服務(wù)健康檢查的接口：nginx判斷只要某個實例的接口返回5xx的狀態(tài)碼，即把該實例下線（nginx不會把流量轉(zhuǎn)發(fā)到該實例）

發(fā)布流程

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

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

2、下架某一個實例（假設(shè)系統(tǒng)集群有A、B、C個實例），比如A實例

3、查看是否下架成功：這個就是我們跟nginx約定的健康檢查接口，正常在線狀態(tài)下是200的statu，切離線后，這個接口返回的是401的statu。

在線情況：

離線情況：

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

5、在該實例下進(jìn)行版本發(fā)布

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

7、QA同學(xué)走查灰度的A實例服務(wù)器，保證它正常運行，如此循環(huán)，直到所有服務(wù)器都發(fā)布。

進(jìn)一步ABTesting的優(yōu)化

背景

平滑發(fā)布做完之后，確實給我?guī)砗艽蟮谋憷?，不用每次發(fā)布都發(fā)公告，不重要的或者非功能性的內(nèi)容發(fā)布了就是了。

但是用久了，客戶量上去之后，又遇到一個問題，那就是每一次業(yè)務(wù)大變更，大型發(fā)布都是直接發(fā)布到生產(chǎn)，這樣可能存在風(fēng)險。設(shè)計師設(shè)計的功能，用戶不一定完全接受，一旦上線新版本，

收到一大堆的吐槽，都是用戶呀，如果能在小范圍人群內(nèi)進(jìn)行灰度試用，完成平穩(wěn)的過度和使用反饋之后，優(yōu)化后再上到生產(chǎn)會更好一點。

所以這邊需要思考和設(shè)計一套統(tǒng)一的技術(shù)方案，未來無論云辦公還是其他的業(yè)務(wù)系統(tǒng)，都能通過灰度發(fā)布在可指定的小范圍內(nèi)先進(jìn)行體驗和功能驗證。

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

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

流程

步驟

1、進(jìn)入云辦公系統(tǒng)，進(jìn)入Nginx反代服務(wù)器

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

3、根據(jù)IP AB名單進(jìn)行流量轉(zhuǎn)發(fā)(名單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;}}

優(yōu)缺點

1、配置簡單，原資源平臺的灰度升級就是根據(jù)IP名單來劃分設(shè)計升級的

2、外部計算機(jī)很多都是非固定IP，這個適合在公司內(nèi)網(wǎng)實現(xiàn)，比如只是配置公司內(nèi)網(wǎng)的IP。

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

流程

步驟

1、進(jìn)入云辦公系統(tǒng)，進(jìn)入Nginx反代服務(wù)器

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

3、根據(jù)Key的版本來進(jìn)行流量轉(zhuǎn)發(fā)(比如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;}}

優(yōu)缺點

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

2、相對穩(wěn)定，對需要開放名單的用戶，在Cookie頭部加入特定的版本即可，應(yīng)用只要少許的開發(fā)量

3、首次訪問靜態(tài)頁面可能不會產(chǎn)生cookie

備注：這是團(tuán)隊內(nèi)認(rèn)為最好的Nginx代理方案，同理，User-Agent和Header都可以做此種類型的判斷，但是Header需要侵入底層HttpRequest去業(yè)務(wù)添加，不建議。

3、AB集群 業(yè)務(wù)代理方式

流程

步驟

1、進(jìn)入云辦公系統(tǒng)，兩種方式進(jìn)入系統(tǒng)，一種是登錄頁登錄：~/login ，一種是default頁面帶uckey登錄：~/default?usertoken=#usertoken#

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

3、根據(jù)轉(zhuǎn)發(fā)跳到具體的實例集群域名下（可以配置AB集群擁有不同域名,更容易區(qū)分）

優(yōu)缺點

1、與Nginx剝離，不用依賴公司的通用平臺和技術(shù)部的實現(xiàn)

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

3、如果是前后端分離情況下，需要保證靜態(tài)站點和服務(wù)站點均申請AB集群

4、所有入口需要統(tǒng)一做代理，有一定的開發(fā)量

應(yīng)用

目前手上2個系統(tǒng)已經(jīng)根據(jù)該方案實現(xiàn)了