平滑發(fā)布的介紹
背景
單位的云辦公相關(guān)系統(tǒng)沒(méi)有成熟的平滑發(fā)布方案,導(dǎo)致每一次發(fā)布都是直接發(fā)布,dll文件或配置文件的變更會(huì)引起站點(diǎn)的重啟。
云辦公系統(tǒng)的常駐用戶有10000 ,即使短短半分多鐘,也會(huì)收到一堆投訴。基于此,我們梳理了一套平滑發(fā)布的方案。
實(shí)施方案
1、跟nginx代理服務(wù)器約定了一個(gè)健康檢查的接口
2、通過(guò)接口返回的http狀態(tài)碼來(lái)讓ngx是否分流用戶請(qǐng)求(這個(gè)我們單位的技術(shù)部那邊有標(biāo)準(zhǔn)的做法)
3、根據(jù)提供的這個(gè)服務(wù)健康檢查的接口:nginx判斷只要某個(gè)實(shí)例的接口返回5xx的狀態(tài)碼,即把該實(shí)例下線(nginx不會(huì)把流量轉(zhuǎn)發(fā)到該實(shí)例)
發(fā)布流程
目的主要是為了發(fā)布的時(shí)候能夠平滑發(fā)布,所以QA與開(kāi)發(fā)人員在發(fā)布得時(shí)候按照如下步驟操作:
1、打開(kāi)系統(tǒng)的nginx列表管理頁(yè)面:[/publish/ngxconfig]
2、下架某一個(gè)實(shí)例(假設(shè)系統(tǒng)集群有A、B、C個(gè)實(shí)例),比如A實(shí)例
3、查看是否下架成功:這個(gè)就是我們跟nginx約定的健康檢查接口,正常在線狀態(tài)下是200的statu,切離線后,這個(gè)接口返回的是401的statu。
在線情況:
離線情況:
4、觀察監(jiān)控站點(diǎn),直至該實(shí)例下的Req、Connnectiuon流量都消失
5、在該實(shí)例下進(jìn)行版本發(fā)布
6、打開(kāi)Fidller,host到待發(fā)布的實(shí)例,然后判斷是否發(fā)布成功(發(fā)布dll、配置文件時(shí),IIS站點(diǎn)會(huì)短暫重啟)
7、QA同學(xué)走查灰度的A實(shí)例服務(wù)器,保證它正常運(yùn)行,如此循環(huán),直到所有服務(wù)器都發(fā)布。
進(jìn)一步ABTesting的優(yōu)化
背景
平滑發(fā)布做完之后,確實(shí)給我?guī)?lái)很大的便利,不用每次發(fā)布都發(fā)公告,不重要的或者非功能性的內(nèi)容發(fā)布了就是了。
但是用久了,客戶量上去之后,又遇到一個(gè)問(wèn)題,那就是每一次業(yè)務(wù)大變更,大型發(fā)布都是直接發(fā)布到生產(chǎn),這樣可能存在風(fēng)險(xiǎn)。設(shè)計(jì)師設(shè)計(jì)的功能,用戶不一定完全接受,一旦上線新版本,
收到一大堆的吐槽,都是用戶呀,如果能在小范圍人群內(nèi)進(jìn)行灰度試用,完成平穩(wěn)的過(guò)度和使用反饋之后,優(yōu)化后再上到生產(chǎn)會(huì)更好一點(diǎn)。
所以這邊需要思考和設(shè)計(jì)一套統(tǒng)一的技術(shù)方案,未來(lái)無(wú)論云辦公還是其他的業(yè)務(wù)系統(tǒng),都能通過(guò)灰度發(fā)布在可指定的小范圍內(nèi)先進(jìn)行體驗(yàn)和功能驗(yàn)證。
基于上面的平滑,我們?cè)贜ginx反向代理服務(wù)器上動(dòng)心思,讓nginx來(lái)幫我們做ABTesting的方案。以下是我們嘗試的幾種方案:
1、Nginx反向代理:來(lái)路IP策略
流程
步驟
1、進(jìn)入云辦公系統(tǒng),進(jìn)入Nginx反代服務(wù)器
2、Nginx讀取來(lái)路IP的AB名單
3、根據(jù)IP AB名單進(jìn)行流量轉(zhuǎn)發(fā)(名單A走特定實(shí)例,名單B走云辦公原有集群實(shí)例)
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)缺點(diǎn)
1、配置簡(jiǎn)單,原資源平臺(tái)的灰度升級(jí)就是根據(jù)IP名單來(lái)劃分設(shè)計(jì)升級(jí)的
2、外部計(jì)算機(jī)很多都是非固定IP,這個(gè)適合在公司內(nèi)網(wǎng)實(shí)現(xiàn),比如只是配置公司內(nèi)網(wǎng)的IP。
2、Nginx反向代理:$.Cookies策略
流程
步驟
1、進(jìn)入云辦公系統(tǒng),進(jìn)入Nginx反代服務(wù)器
2、Nginx讀取Http請(qǐng)求的Cokie的version信息(也可以是別的key)
3、根據(jù)Key的版本來(lái)進(jìn)行流量轉(zhuǎn)發(fā)(比如Version1.1走特定集群,Version1.0走通用集群實(shí)例)
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)缺點(diǎn)
1、配置簡(jiǎn)單,根據(jù)Nginx的 $COOKIE_version 屬性來(lái)判斷
2、相對(duì)穩(wěn)定,對(duì)需要開(kāi)放名單的用戶,在Cookie頭部加入特定的版本即可,應(yīng)用只要少許的開(kāi)發(fā)量
3、首次訪問(wèn)靜態(tài)頁(yè)面可能不會(huì)產(chǎn)生cookie
備注:這是團(tuán)隊(duì)內(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),一種是登錄頁(yè)登錄:~/login ,一種是default頁(yè)面帶uckey登錄:~/default?usertoken=#usertoken#
2、登錄的時(shí)候和usertoken傳入的時(shí)候進(jìn)去 路由代理模塊,進(jìn)行用戶信息校驗(yàn),根據(jù)不同的人員和部門(人員和部門配置歸屬AB名單)分流到兩個(gè)不同的AB集群
3、根據(jù)轉(zhuǎn)發(fā)跳到具體的實(shí)例集群域名下(可以配置AB集群擁有不同域名,更容易區(qū)分)
優(yōu)缺點(diǎn)
1、與Nginx剝離,不用依賴公司的通用平臺(tái)和技術(shù)部的實(shí)現(xiàn)
2、需要申請(qǐng)AB集群,AB集群擁有不同的域名。
3、如果是前后端分離情況下,需要保證靜態(tài)站點(diǎn)和服務(wù)站點(diǎn)均申請(qǐng)AB集群
4、所有入口需要統(tǒng)一做代理,有一定的開(kāi)發(fā)量
應(yīng)用
目前手上2個(gè)系統(tǒng)已經(jīng)根據(jù)該方案實(shí)現(xiàn)了