究竟什么才是灰度發(fā)布其實(shí)并沒有一個(gè)嚴(yán)格的標(biāo)準(zhǔn)，因?yàn)檫@個(gè)東西不是黑的也不是白的是個(gè)中間過渡地帶，這類的東西定義都會(huì)比較麻煩。由于工作的原因看到好多友商所謂的灰度發(fā)布產(chǎn)品，有意思的是他們實(shí)現(xiàn)的是完全不一樣的功能，對外都說自己是灰度發(fā)布。我看到的有三種：
1. 更新過程可以暫停，停在一個(gè)既有新版本又有舊版本的狀態(tài)，然后選擇升級或者回滾
2. 支持流量比例分配，可以把百分之幾的流量分配給一個(gè)服務(wù)，剩下的給另一個(gè)服務(wù)
3. 支持 url 路徑流量分配，一個(gè)路徑下的流量給一個(gè)服務(wù)，另一個(gè)路徑流量給另一個(gè)服務(wù)
那究竟哪個(gè)才能算是灰度發(fā)布呢？拋開具體的技術(shù)實(shí)現(xiàn)，讓我們從需求的角度來考慮一下為什么要有灰度發(fā)布？灰度發(fā)布究竟是要做什么？從目的出發(fā)再來看技術(shù)實(shí)現(xiàn)就會(huì)清晰很多。
既然要灰度就是不希望所有人都看到，就是為了控制影響范圍，之所以要做這種限制就說明發(fā)布的人心里對這個(gè)發(fā)布的版本就是不確定的，害怕影響范圍太大風(fēng)險(xiǎn)不可控。也就是說這個(gè)風(fēng)險(xiǎn)因素在開發(fā)和測試環(huán)境都沒有辦法控制，只能在生產(chǎn)環(huán)境來觀察，那究竟是怎樣的因素會(huì)導(dǎo)致必須要上線觀察而不是在開發(fā)測試環(huán)節(jié)來解決呢？主要有從運(yùn)維和產(chǎn)品兩大方面的考量因素。
從運(yùn)維的角度講，任何一次上線都是有風(fēng)險(xiǎn)的，或者有一些步驟的遺漏，流程的不規(guī)范，或者有一些隱藏的代碼 bug都會(huì)導(dǎo)致線上的不穩(wěn)定?？刂骑L(fēng)險(xiǎn)的辦法就是小批量上線，驗(yàn)證之后在全部更新。此外一些穩(wěn)定性和性能的問題在開發(fā)測試環(huán)境很難復(fù)現(xiàn)，因此這一類的修復(fù)和功能只能到生產(chǎn)環(huán)境來驗(yàn)證，同樣由于效果的未知也不可能全量更新。再有一些大的重構(gòu)，比如編程語言的變化，框架的變化，基礎(chǔ)庫的更新，操作系統(tǒng)的更新都會(huì)有未知的影響，而這些影響也需要生產(chǎn)的檢驗(yàn)。
從產(chǎn)品的角度講，有一些產(chǎn)品設(shè)計(jì)，交互，界面展現(xiàn)形式都不是坐在辦公室里拍桌子就可以定出最佳實(shí)踐的。產(chǎn)品經(jīng)理的視角和用戶的視角是不同的，即使是產(chǎn)品經(jīng)理之間的風(fēng)格，偏好也是不一致的。小到按鈕的順序，彈框展示的位置，大到頁面整體的布局，廣告位的展示策略，究竟用哪種設(shè)計(jì)更好并沒有理論上的最佳實(shí)踐。而這種情況就需要大家分別作出自己的方案，去線上收集真實(shí)的用戶數(shù)據(jù)作對比。也就是硅谷里常說的 A/B testing，也可以歸到灰度發(fā)布的范疇。本質(zhì)上就是基于數(shù)據(jù)驅(qū)動(dòng)來作抉擇，在用戶的投票中選擇哪種方案，而不是傳統(tǒng)的看誰嗓門大會(huì)拍桌子，看誰官大來做決策。
了解了需求，我們就很容易推導(dǎo)出所有人都在說的灰度發(fā)布真正是什么了。
1. 精確的流量分發(fā)控制
這是一切的核心，從運(yùn)維風(fēng)險(xiǎn)控制的角度，需要把受影響的流量控制在一個(gè)精確的范圍內(nèi)，在上線前就知道哪部分用戶會(huì)有問題，而不是真出問題誰受到影響都不知道。一個(gè)常見場景是新版本只讓公司內(nèi)部的員工能訪問到，再一個(gè)市，一個(gè)省的一點(diǎn)點(diǎn)推上去。從產(chǎn)品角度看要做 A/B test，就需要控制測試樣本，哪些用戶是 A 版本，哪些用戶是 B 版本，在發(fā)布后應(yīng)該就是固定的，而不是一個(gè)用戶一會(huì)兒訪問 A，一會(huì)兒訪問 B。而傳統(tǒng)的負(fù)載均衡器策略只能做到粗獷的比例分配，并沒有細(xì)粒度的流量規(guī)則控制。而一個(gè)理想的灰度發(fā)布系統(tǒng)應(yīng)該有很細(xì)粒度的流量規(guī)則，比如匹配 android 用戶，匹配某個(gè)地區(qū)的用戶，甚至能組合多種條件匹配到特定的人群。
2. 監(jiān)控系統(tǒng)的支撐
流量精確分配只是第一步，接下來更重要的是獲得多個(gè)版本的關(guān)鍵指標(biāo)。對運(yùn)維來說可能是看錯(cuò)誤率，吞吐量，延遲，cpu 內(nèi)存消耗這些系統(tǒng)層面指標(biāo)。對于產(chǎn)品來說可能是要看點(diǎn)擊率，pv，uv 等業(yè)務(wù)指標(biāo)的變化。這些都需要能把數(shù)據(jù)收集并作展示，來方便后續(xù)決策：全量推還是回滾？使用方案 A 還是 B？不然的話灰度發(fā)布帶來不了更多業(yè)務(wù)方面的促進(jìn)，也不能幫你更好的了解業(yè)務(wù)的狀態(tài)和用戶行為。
3. 靈活的發(fā)布系統(tǒng)
從上面的介紹可以看出灰度發(fā)布并不是個(gè)短暫的過程，可能會(huì)持續(xù)很久。例如某個(gè)重大的框架或者系統(tǒng)更新可能會(huì)持續(xù)很久，有可能整個(gè)服務(wù)在幾個(gè)月內(nèi)都是新舊并存，甚至有可能需要兩個(gè)版本分別各自迭代。而從產(chǎn)品的角度來看可能就會(huì)更靈活，很有可能線上有五六個(gè)方案都在收集數(shù)據(jù)，每天有了一些新想法都要上一些小版本看效果，每個(gè)版本上線后可能都要再各自做優(yōu)化調(diào)整觀察效果。這種情況可能線上就永遠(yuǎn)不會(huì)有一個(gè)統(tǒng)一的版本灰度反而是個(gè)常態(tài)來應(yīng)對不斷變化的需求和挑戰(zhàn)。而發(fā)布系統(tǒng)也需要做相應(yīng)的調(diào)整，不在把每個(gè)服務(wù)看成一個(gè)單一版本的運(yùn)行體，只在更新的短時(shí)間內(nèi)出現(xiàn)多版本共存，只允許全量推和回滾這種粗粒度策略。而是應(yīng)該將多版本共存看成常態(tài)，允許每個(gè)版本各自迭代，版本之間又能區(qū)分對應(yīng)的監(jiān)控日志信息，這樣靈活的發(fā)布系統(tǒng)才能配合靈活的灰度策略。
說了這么寫灰度系統(tǒng)要做的事情其實(shí)就是流量控制和數(shù)據(jù)收集，來控制風(fēng)險(xiǎn)并幫助產(chǎn)品做決策。再看一下最開始提出的三個(gè)所謂的灰度發(fā)布：更新過程可以暫停，流量比例分配，url分流。它們充其量也只是做到了流量精確分配的某幾個(gè)特殊情況，而且還都是不很精確的分配。而如果結(jié)合使用場景就會(huì)發(fā)現(xiàn)，這幾種在實(shí)際中是很難用起來的，因?yàn)闆]有流量的精確控制很難控制風(fēng)險(xiǎn)范圍，如果風(fēng)險(xiǎn)都不可控，那還要灰度發(fā)布干什么呢？更不要提后面的監(jiān)控?cái)?shù)據(jù)收集和靈活的發(fā)布了。
所以說一個(gè)真實(shí)好用的發(fā)布系統(tǒng)是十分復(fù)雜的，絕對不是頁面上點(diǎn)兩三下就可以完成的，而后面的實(shí)現(xiàn)更需要一整套體系來支撐。如果你想打造一個(gè)灰度發(fā)布系統(tǒng)，希望這篇文章能對你有所啟發(fā)。
