怎樣才是真正的灰度發布？

01-29

究竟什麼才是灰度發布其實並沒有一個嚴格的標準，因為這個東西不是黑的也不是白的是個中間過渡地帶，這類的東西定義都會比較麻煩。由於工作的原因看到好多友商所謂的灰度發布產品，有意思的是他們實現的是完全不一樣的功能，對外都說自己是灰度發布。我看到的有三種：

1. 更新過程可以暫停，停在一個既有新版本又有舊版本的狀態，然後選擇升級或者回滾

2. 支持流量比例分配，可以把百分之幾的流量分配給一個服務，剩下的給另一個服務

3. 支持 url 路徑流量分配，一個路徑下的流量給一個服務，另一個路徑流量給另一個服務

那究竟哪個才能算是灰度發布呢？拋開具體的技術實現，讓我們從需求的角度來考慮一下為什麼要有灰度發布？灰度發布究竟是要做什麼？從目的出發再來看技術實現就會清晰很多。

既然要灰度就是不希望所有人都看到，就是為了控制影響範圍，之所以要做這種限制就說明發布的人心裡對這個發布的版本就是不確定的，害怕影響範圍太大風險不可控。也就是說這個風險因素在開發和測試環境都沒有辦法控制，只能在生產環境來觀察，那究竟是怎樣的因素會導致必須要上線觀察而不是在開發測試環節來解決呢？主要有從運維和產品兩大方面的考量因素。

從運維的角度講，任何一次上線都是有風險的，或者有一些步驟的遺漏，流程的不規範，或者有一些隱藏的代碼 bug都會導致線上的不穩定。控制風險的辦法就是小批量上線，驗證之後在全部更新。此外一些穩定性和性能的問題在開發測試環境很難復現，因此這一類的修復和功能只能到生產環境來驗證，同樣由於效果的未知也不可能全量更新。再有一些大的重構，比如編程語言的變化，框架的變化，基礎庫的更新，操作系統的更新都會有未知的影響，而這些影響也需要生產的檢驗。

從產品的角度講，有一些產品設計，交互，界面展現形式都不是坐在辦公室里拍桌子就可以定出最佳實踐的。產品經理的視角和用戶的視角是不同的，即使是產品經理之間的風格，偏好也是不一致的。小到按鈕的順序，彈框展示的位置，大到頁面整體的布局，廣告位的展示策略，究竟用哪種設計更好並沒有理論上的最佳實踐。而這種情況就需要大家分別作出自己的方案，去線上收集真實的用戶數據作對比。也就是矽谷里常說的 A/B testing，也可以歸到灰度發布的範疇。本質上就是基於數據驅動來作抉擇，在用戶的投票中選擇哪種方案，而不是傳統的看誰嗓門大會拍桌子，看誰官大來做決策。

了解了需求，我們就很容易推導出所有人都在說的灰度發布真正是什麼了

1. 精確的流量分發控制

這是一切的核心，從運維風險控制的角度，需要把受影響的流量控制在一個精確的範圍內，在上線前就知道哪部分用戶會有問題，而不是真出問題誰受到影響都不知道。一個常見場景是新版本只讓公司內部的員工能訪問到，再一個市，一個省的一點點推上去。從產品角度看要做 A/B test，就需要控制測試樣本，哪些用戶是 A 版本，哪些用戶是 B 版本，在發布後應該就是固定的，而不是一個用戶一會兒訪問 A，一會兒訪問 B。而傳統的負載均衡器策略只能做到粗獷的比例分配，並沒有細粒度的流量規則控制。而一個理想的灰度發布系統應該有很細粒度的流量規則，比如匹配 android 用戶，匹配某個地區的用戶，甚至能組合多種條件匹配到特定的人群。

2. 監控系統的支撐

流量精確分配只是第一步，接下來更重要的是獲得多個版本的關鍵指標。對運維來說可能是看錯誤率，吞吐量，延遲，cpu 內存消耗這些系統層面指標。對於產品來說可能是要看點擊率，pv，uv 等業務指標的變化。這些都需要能把數據收集並作展示，來方便後續決策：全量推還是回滾？使用方案 A 還是 B？不然的話灰度發布帶來不了更多業務方面的促進，也不能幫你更好的了解業務的狀態和用戶行為。

3. 靈活的發布系統

從上面的介紹可以看出灰度發布並不是個短暫的過程，可能會持續很久。例如某個重大的框架或者系統更新可能會持續很久，有可能整個服務在幾個月內都是新舊並存，甚至有可能需要兩個版本分別各自迭代。而從產品的角度來看可能就會更靈活，很有可能線上有五六個方案都在收集數據，每天有了一些新想法都要上一些小版本看效果，每個版本上線後可能都要再各自做優化調整觀察效果。這種情況可能線上就永遠不會有一個統一的版本灰度反而是個常態來應對不斷變化的需求和挑戰。而發布系統也需要做相應的調整，不在把每個服務看成一個單一版本的運行體，只在更新的短時間內出現多版本共存，只允許全量推和回滾這種粗粒度策略。而是應該將多版本共存看成常態，允許每個版本各自迭代，版本之間又能區分對應的監控日誌信息，這樣靈活的發布系統才能配合靈活的灰度策略。

說了這麼寫灰度系統要做的事情其實就是流量控制和數據收集，來控制風險並幫助產品做決策。再看一下最開始提出的三個所謂的灰度發布：更新過程可以暫停，流量比例分配，url分流。它們充其量也只是做到了流量精確分配的某幾個特殊情況，而且還都是不很精確的分配。而如果結合使用場景就會發現，這幾種在實際中是很難用起來的，因為沒有流量的精確控制很難控制風險範圍，如果風險都不可控，那還要灰度發布幹什麼呢？更不要提後面的監控數據收集和靈活的發布了。

所以說一個真實好用的發布系統是十分複雜的，絕對不是頁面上點兩三下就可以完成的，而後面的實現更需要一整套體系來支撐。如果你想打造一個灰度發布系統，希望這篇文章能對你有所啟發。