建站
咨詢
售后
建站咨詢
新聞中心
前言
成都創(chuàng)新互聯(lián)主要業(yè)務(wù)有網(wǎng)站營銷策劃、網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站、微信公眾號(hào)開發(fā)、微信小程序開發(fā)、H5高端網(wǎng)站建設(shè)、程序開發(fā)等業(yè)務(wù)。一次合作終身朋友，是我們奉行的宗旨；我們不僅僅把客戶當(dāng)客戶，還把客戶視為我們的合作伙伴，在開展業(yè)務(wù)的過程中，公司還積累了豐富的行業(yè)經(jīng)驗(yàn)、營銷型網(wǎng)站資源和合作伙伴關(guān)系資源，并逐漸建立起規(guī)范的客戶服務(wù)和保障體系。
DevOps追求更短的迭代周期、更高頻的發(fā)布。但發(fā)布的次數(shù)越多，引入故障的可能性就越大。更多的故障將會(huì)降低服務(wù)的可用性，進(jìn)而影響到客戶體驗(yàn)。所以，為了保證服務(wù)質(zhì)量，守好發(fā)布這個(gè)最后一道關(guān)，阿里逐步發(fā)展出了適應(yīng)DevOps要求的發(fā)布策略。
在開始講述阿里的實(shí)踐之前，我們先簡單介紹下幾種常見發(fā)布策略，以及它們適用的場景和優(yōu)缺點(diǎn)。
一 常見發(fā)布策略
1 停機(jī)發(fā)布
停機(jī)發(fā)布會(huì)在發(fā)布以前關(guān)閉服務(wù)，停止用戶訪問，然后一次性的升級所有服務(wù)。這種發(fā)布策略的發(fā)布頻率往往比較低，且需要在發(fā)布之前做好充足的測試。
停機(jī)發(fā)布的特點(diǎn)有：
所有需要升級的組件被整合到一次發(fā)布中
一個(gè)項(xiàng)目中的大部分應(yīng)用都會(huì)被更新
發(fā)布之前的研發(fā)流程和測試流程往往需要花很長的時(shí)間
發(fā)布時(shí)如果出現(xiàn)問題, 修復(fù)和回滾的成本很高
完成一次停機(jī)發(fā)布, 需要花費(fèi)很久的時(shí)間, 且需要很多團(tuán)隊(duì)在一起才能完成
往往需要客戶端和服務(wù)器端同步升級
停機(jī)發(fā)布并不適合互聯(lián)網(wǎng)公司，因?yàn)閮纱伟l(fā)布的間隔很久，從功能特性提出到進(jìn)入市場的時(shí)間太長，對市場反應(yīng)不敏感，會(huì)在充分競爭的市場里處于下風(fēng)。每次發(fā)布因?yàn)橐C(jī)，也會(huì)帶來經(jīng)濟(jì)損失。
優(yōu)勢：
簡單，不太需要考慮新舊版本共存時(shí)的兼容性問題
劣勢：
發(fā)布過程中，服務(wù)不可用
只能在業(yè)務(wù)低峰期 (往往是夜間)發(fā)布，并且需要很多團(tuán)隊(duì)在一起工作
出現(xiàn)故障后很難回滾
適合場景：
開發(fā)測試環(huán)境
非關(guān)鍵應(yīng)用，用戶影響面小
兼容性比較難管控的場景
2 金絲雀發(fā)布
金絲雀發(fā)布這個(gè)術(shù)語源自20世紀(jì)初期，當(dāng)時(shí)英國的煤礦工人在下井采礦之前，會(huì)把籠養(yǎng)的金絲雀攜帶到礦井中，如果礦井中一氧化碳等有毒氣體的濃度過高，在影響礦工之前，金絲雀相比人類表現(xiàn)的更加敏感快速，金絲雀中毒之后，煤礦工人就知道該立刻撤離。金絲雀發(fā)布是在將整個(gè)軟件的新版本發(fā)布給所有用戶之前，先發(fā)布給部分用戶，用真實(shí)的客戶流量來測試，以保證軟件不會(huì)出現(xiàn)嚴(yán)重問題，降低發(fā)布風(fēng)險(xiǎn)。
在實(shí)踐中，金絲雀發(fā)布一般會(huì)先發(fā)布到一個(gè)小比例的機(jī)器，比如 2% 的服務(wù)器做流量驗(yàn)證，然后從中快速獲得反饋，根據(jù)反饋決定是擴(kuò)大發(fā)布還是回滾。金絲雀發(fā)布通常會(huì)結(jié)合監(jiān)控系統(tǒng)，通過監(jiān)控指標(biāo)，觀察金絲雀機(jī)器的健康狀況。如果金絲雀測試通過，則把剩余的機(jī)器全部升級成新版本，否則回滾代碼。
優(yōu)勢：
對用戶體驗(yàn)影響較小，在金絲雀發(fā)布過程中，只有少量用戶會(huì)受影響
發(fā)布安全能夠得到保障
劣勢：
金絲雀的機(jī)器數(shù)量比較少, 有一些問題并不能夠暴露出來
適用場景：
監(jiān)控比較完備且與發(fā)布系統(tǒng)集成
3 灰度/滾動(dòng)發(fā)布
灰度發(fā)布是金絲雀發(fā)布的延伸，是將發(fā)布分成不同的階段/批次，每個(gè)階段/批次的用戶數(shù)量逐級增加。如果新版本在當(dāng)前階段沒有發(fā)現(xiàn)問題，就再增加用戶數(shù)量進(jìn)入下一個(gè)階段，直至擴(kuò)展到全部用戶。
灰度發(fā)布可以減小發(fā)布風(fēng)險(xiǎn)，是一種零宕機(jī)時(shí)間的發(fā)布策略。它通過切換線上并存版本之間的路由權(quán)重，逐步從一個(gè)版本切換為另一個(gè)版本。整個(gè)發(fā)布過程會(huì)持續(xù)比較長的時(shí)間, 在這段時(shí)間內(nèi)，新舊代碼共存，所以在開發(fā)過程中，需要考慮版本之間的兼容性，新舊代碼共存不能影響功能可用性和用戶體驗(yàn)。當(dāng)新版本代碼出現(xiàn)問題時(shí)，灰度發(fā)布能夠比較快的回滾到老版本的代碼上。
結(jié)合特性開關(guān)等技術(shù)，灰度發(fā)布可以實(shí)現(xiàn)更復(fù)雜靈活的發(fā)布策略。
優(yōu)勢：
用戶體驗(yàn)影響比較小, 不需要停機(jī)發(fā)布
能夠控制發(fā)布風(fēng)險(xiǎn)
劣勢：
發(fā)布時(shí)間會(huì)比較長
需要復(fù)雜的發(fā)布系統(tǒng)和負(fù)載均衡器
需要考慮新舊版本共存時(shí)的兼容性
適用場景：
適合可用性較高的生產(chǎn)環(huán)境發(fā)布
4 藍(lán)綠發(fā)布
藍(lán)綠部署是指有兩個(gè)完全相同的、互相獨(dú)立的生產(chǎn)環(huán)境，一個(gè)叫做“藍(lán)環(huán)境”，一個(gè)叫做“綠環(huán)境”。其中，綠環(huán)境是用戶正在使用的生產(chǎn)環(huán)境。當(dāng)要部署一個(gè)新版本的時(shí)候，先把這個(gè)新版本部署到藍(lán)環(huán)境中，然后在藍(lán)環(huán)境中運(yùn)行冒煙測試，以檢查新版本是否正常工作。如果測試通過，發(fā)布系統(tǒng)更新路由配置，將用戶流量從綠環(huán)境導(dǎo)向藍(lán)環(huán)境，藍(lán)環(huán)境就變成了生產(chǎn)環(huán)境。這種切換通常在一秒鐘之內(nèi)就能搞定。如果出了問題，把路由切回到綠環(huán)境上，再在藍(lán)環(huán)境中調(diào)試，找到問題的原因。因此，藍(lán)綠部署可以做到僅僅一次切換，立刻就向所有用戶推出新版本，新功能對所有用戶立刻生效可見。
優(yōu)勢：
升級切換和回退速度非?？?br /> 零停機(jī)時(shí)間
不足：
一次性的全量切換，如果發(fā)布出現(xiàn)問題, 會(huì)對用戶產(chǎn)生比較大的影響
需要兩倍的機(jī)器資源
需要中間件和應(yīng)用自身支持熱備集群的流量切換
適用場景：
機(jī)器資源比較富余或者按需分配 (背靠云廠商)
5 A/B 測試
A/B 測試和灰度發(fā)布非常像，可以從發(fā)布的目的上進(jìn)行區(qū)分。AB測試側(cè)重的是根據(jù)A版本和B版本的差異進(jìn)行決策，最終選擇一個(gè)版本進(jìn)行部署。和灰度發(fā)布相比，AB測試更傾向于去決策，和金絲雀發(fā)布相比，AB測試在權(quán)重和流量的切換上更靈活。
舉個(gè)例子，某功能有兩個(gè)實(shí)現(xiàn)版本 A 和 B，通過細(xì)粒度的流量控制，把 50% 的用戶總是引導(dǎo)到 A 實(shí)現(xiàn)上，把剩下的 50% 用戶總是引導(dǎo)到 B 實(shí)現(xiàn)上，通過比較 A 實(shí)現(xiàn)和 B 實(shí)現(xiàn)的轉(zhuǎn)化率，最終選擇轉(zhuǎn)化率較高的 A 實(shí)現(xiàn)作為功能的最終版本。
優(yōu)勢：
快速實(shí)驗(yàn)?zāi)芰?br /> 用戶體驗(yàn)影響小
可以使用生產(chǎn)環(huán)境流量做測試
可以針對某些特定用戶做測試
不足：
需要較為復(fù)雜的業(yè)務(wù)流量識(shí)別和控制能力
需要考慮較為復(fù)雜的新舊版本兼容性問題
適用場景：
用來做業(yè)務(wù)探索和創(chuàng)新測試
需要對多個(gè)方案進(jìn)行決策
6 流量隔離環(huán)境發(fā)布
在上述的發(fā)布策略中，發(fā)布的單位都是應(yīng)用，但是一個(gè)功能模塊往往是由多個(gè)應(yīng)用組合在一起提供的服務(wù)，即使當(dāng)前發(fā)布的應(yīng)用出現(xiàn)了異常，這個(gè)異常也未必體現(xiàn)在當(dāng)前應(yīng)用中，在復(fù)雜的情況下，異常會(huì)延遲到它的下游應(yīng)用才體現(xiàn)出來，如何發(fā)現(xiàn)此類問題并且不影響用戶體驗(yàn)是非常重要的。此外，我們有時(shí)候還希望新版本的代碼上線以后，只影響到一小部分用戶。而傳統(tǒng)的灰度發(fā)布，因?yàn)闊o法識(shí)別業(yè)務(wù)流量，所以即使某個(gè)應(yīng)用只有一臺(tái)機(jī)器出現(xiàn)了問題，也可能會(huì)影響到所有的用戶。
如下圖左側(cè)的灰度發(fā)布，App1 的所有機(jī)器都有一定概率會(huì)路由到出現(xiàn)問題的紅色 App2 機(jī)器上。而右側(cè)的隔離環(huán)境發(fā)布中，新版本的代碼會(huì)先發(fā)布在全鏈路隔離環(huán)境中，即使發(fā)布中出現(xiàn)問題，也只會(huì)影響少量用戶。
優(yōu)勢：
能夠發(fā)現(xiàn)一些復(fù)雜的, 涉及到多應(yīng)用的問題
出現(xiàn)故障時(shí), 只會(huì)影響很小一部分用戶
不足：
需要對流量隔離環(huán)境進(jìn)行獨(dú)立監(jiān)控
系統(tǒng)設(shè)計(jì)復(fù)雜, 需要中間件和鏈路上的所有應(yīng)用能夠識(shí)別業(yè)務(wù)流量
適用場景：
較為核心的生產(chǎn)業(yè)務(wù)場景
二 阿里巴巴發(fā)布最佳實(shí)踐
我們將按照發(fā)布的過程來介紹阿里巴巴發(fā)布的最佳實(shí)踐。
1 發(fā)布計(jì)劃
發(fā)布前要對待發(fā)布功能模塊做充分驗(yàn)證，同時(shí)要思考假如本次發(fā)布引入故障該如何止血。所以在發(fā)布之前寫出本次發(fā)布的計(jì)劃清單是非常重要的，一個(gè)典型的發(fā)布計(jì)劃如下：
本次發(fā)布參與人開發(fā)人測試人代碼 Review 人
發(fā)布內(nèi)容
測試過程
風(fēng)險(xiǎn)描述
線上驗(yàn)證方案
線上出現(xiàn)問題的止血方案
發(fā)布步驟分 x 批發(fā)布前 x 批發(fā)布后暫停 x 小時(shí)
2 不同環(huán)境使用不同的發(fā)布策略
前面介紹的幾種發(fā)布策略都有各自的優(yōu)缺點(diǎn)，要根據(jù)自己的場景特點(diǎn)和需求選擇合適的發(fā)布策略。
一般來說，測試環(huán)境是用來做初步功能測試，所以會(huì)頻繁的更新代碼和發(fā)布，如果采用灰度發(fā)布的方式且發(fā)布的批次設(shè)置的比較大，則開發(fā)效率會(huì)大打折扣。這個(gè)時(shí)候單機(jī)或多機(jī)的單批次停機(jī)發(fā)布其實(shí)是一個(gè)不做的選擇。
對于預(yù)發(fā)環(huán)境，不僅要考慮自己測試的需要，還要考慮上下游其他開發(fā)者的測試需求，所以單批次停機(jī)發(fā)布就不再合適，可以設(shè)置兩批發(fā)布。
對于線上環(huán)境，可以先發(fā)布隔離流量環(huán)境，再多批次發(fā)布線上環(huán)境。
3 發(fā)布中關(guān)注監(jiān)控報(bào)警
僅靠發(fā)布策略是無法避免故障的發(fā)生的，在發(fā)布中和發(fā)布后仔細(xì)的觀察應(yīng)用的監(jiān)控?cái)?shù)據(jù)非常重要。應(yīng)用的核心指標(biāo)監(jiān)控?cái)?shù)據(jù)，比如 QPS、RT、成功率和報(bào)錯(cuò)數(shù)，能夠幫助用戶盡可能早的發(fā)現(xiàn)故障。此外，在生產(chǎn)環(huán)境中，如果批次數(shù)量設(shè)置的比較小，每批發(fā)布機(jī)器數(shù)量比較少，那么即使某些監(jiān)控指標(biāo)出現(xiàn)了問題，因?yàn)閿?shù)據(jù)量比較小，可能會(huì)被淹沒在整體的監(jiān)控?cái)?shù)據(jù)中，所以配置已發(fā)布機(jī)器的獨(dú)立監(jiān)控也是非常重要的。
4 金絲雀發(fā)布和無人值守
阿里內(nèi)部絕大部分應(yīng)用會(huì)在多機(jī)房/單元部署，可能存在一種場景，同一份代碼和配置在某些機(jī)房/單元正常，在其他的的單元/機(jī)房下就會(huì)出現(xiàn)故障，所以有必要在分批發(fā)布的時(shí)候，把所有機(jī)房/單元的組合都在第一批發(fā)布時(shí)出現(xiàn)，這樣問題可以及早暴露。此外研發(fā)人員往往會(huì)重點(diǎn)關(guān)注前幾批發(fā)布，如果后面批次才出現(xiàn)問題，研發(fā)人員可能無法快速響應(yīng)。
單元化是為了解決容災(zāi)和擴(kuò)展性問題，上圖是阿里巴巴的單元化部署架構(gòu)。
此外，應(yīng)用的監(jiān)控項(xiàng)一般都很多，在發(fā)布周期比較長的情況下，不能要求研發(fā)人員時(shí)刻專注每一個(gè)監(jiān)控項(xiàng)，需要一定的智能化方案幫助研發(fā)找出那些需要重點(diǎn)關(guān)注的監(jiān)控項(xiàng)。
為了解決上面兩個(gè)問題，阿里設(shè)計(jì)并實(shí)現(xiàn)了自己的金絲雀發(fā)布策略。金絲雀發(fā)布從應(yīng)用的每個(gè)機(jī)房/單元下抽取 10% 的機(jī)器放到首批，無人值守智能監(jiān)控系統(tǒng)會(huì)對這部分機(jī)器設(shè)置獨(dú)立的監(jiān)控，對于每個(gè)監(jiān)控項(xiàng)，無人值守會(huì)對比已發(fā)布和未發(fā)布機(jī)器的監(jiān)控指標(biāo)數(shù)據(jù)，同時(shí)對比發(fā)布前和發(fā)布后的監(jiān)控?cái)?shù)據(jù)，如果發(fā)現(xiàn)異常，會(huì)推送給研發(fā)人員做進(jìn)一步的判斷。
這種金絲雀發(fā)布策略可以幫助研發(fā)盡可能早的發(fā)現(xiàn)問題, 并且減少研發(fā)人員的工作量，提高研發(fā)效率。
5 持續(xù)集成和發(fā)布
合理的選擇發(fā)布策略，按照上面所述的最佳實(shí)踐來發(fā)布，發(fā)布的風(fēng)險(xiǎn)可以被控制在很小的范圍內(nèi)，甚至比停機(jī)發(fā)布的風(fēng)險(xiǎn)還要小。實(shí)際上，發(fā)布周期短，每次發(fā)布僅包含少量代碼是一個(gè)很好的發(fā)布實(shí)踐。因?yàn)椴渴痖g隔時(shí)間長，將會(huì)導(dǎo)致每次的部署包含更多的代碼變更，結(jié)果就是出現(xiàn)更多缺陷和宕機(jī)的風(fēng)險(xiǎn)。這種情況下，人們?yōu)榱私档桶l(fā)布風(fēng)險(xiǎn)，會(huì)傾向于增加更多的評審，事實(shí)上這除了大大增加部署時(shí)間外，對降低發(fā)布風(fēng)險(xiǎn)的影響微乎其微。這是一個(gè)越來越差的增強(qiáng)回路，我們需要通過高頻的持續(xù)部署，來顛覆這個(gè)惡性循環(huán)。
三 總結(jié)
敏捷開發(fā)能夠縮短產(chǎn)品走向市場的時(shí)間，讓消費(fèi)者更快地獲得想要的功能，也能讓產(chǎn)品團(tuán)隊(duì)更快地拿到消費(fèi)者的反饋并據(jù)此對產(chǎn)品做出迭代。為了解決敏捷開發(fā)下頻繁發(fā)布帶來的發(fā)布風(fēng)險(xiǎn)，本文介紹了多種發(fā)布策略，包括各個(gè)發(fā)布策略的優(yōu)缺點(diǎn)、適用場景，在不同場景下綜合應(yīng)用這些模式可以在更快速地交付高質(zhì)量的產(chǎn)品。
網(wǎng)頁名稱：DevOps發(fā)布策略簡介
本文路徑：http://m.5511xx.com/article/coidgdj.html
