你做好灰度發佈了嗎
攜手創作，共同成長！這是我參與「掘金日新計劃 · 8 月更文挑戰」的第12天，點擊查看活動詳情
對於中型及以上的企業互聯網公司擁有的用户級基本都是百萬級以上的。而當我們的產品需求又總是源源不斷，一旦上線新的迭代功能出現問題都會直接影響用户的。對於企業來説可能是一場災難。
現在很多企業可能沒有設計灰度發佈，或者説有灰度環境但是隻是作為發佈之前的一個預發環境。所以，在大型系統中容錯是很重要。畢竟經歷再嚴格的測試，上線後出現 bug 也是很正常的。為了讓上線的功能產生的錯誤對用户的影響最少，可以分批上線或者讓部分用户體驗。這種方式就是灰度發佈，也稱為金絲雀發佈。
金絲雀發佈
金絲雀發佈是一個將新版本推出給非常精選的用户列表的過程。開發者選擇滿足特定條件的人發佈他們的更新。更改/更新最終將發佈給所有人，但一小部分用户可以先於其他用户體驗它。
如果初始用户發現任何錯誤或問題，開發人員可以立即修復並啟動新的更新。如果他們發現新版本沒有任何錯誤，他們可以將其發佈給整個用户羣。
常用的灰度發佈的實現方式有兩種：
- 分批次部署發佈
- 通過業務規則部署發佈
通過分批次部署發佈
分批次部署根據部署服務器的維度進行設計的。某服務可能部署了十幾個實例甚至更多。
設計原理
將所有實例進行分組，分組規則：2的倍數擴展。即如15個實例劃分四組：1 2 4 8。這樣劃分可控制劃分組不會太多，這樣部署次數也不會太多。如有1024台機器的話也只需部署十次就可以。
然後只需觀察已部署的機器日誌，發現錯誤則修復。完全沒問題後再部署第二組，依次下去。
存在問題
- 每次都需要檢查沒問題才繼續進行，實例很多的話工作量也會多，可能需要一整天時間都在跟進。效率極其低。
- 此方案測試可能需要內部人員自己測試，才能準確命中服務器，線上用户可能命中率很低
通過業務規則部署發佈
根據某種業務策略，讓部分用户優先體驗功能，這樣出問題隻影響部分用户。
設計原理
用用户 id，手機號，設備信息等相關信息，生成哈希值，再進行求模。然後根據比例將部分用户的訪問路由到新版功能，就灰度環境。部分用户還是保持訪問舊版功能。這樣當新版用户使用時出現問題則進行修復，當完全都沒有錯誤時則可以全部上線到所有服務內。
通過取模策略是一種單策略。當有多個服務或者説微服務環境下，可能需要組合策略，比如多個服務同時灰度，或者僅其中幾個灰度環境其他不需要灰度環境。這時可以增加一個 Tag 進行標識。
優勢
- 降低測試成本，提高上線的效率
- 對於大部分用户來説服務是高可用的
參考資料：