實現一套灰度發佈系統須要考慮哪些問題？

要了解一個灰度發佈系統的功能，我的以爲有必要先了解灰度發佈的概念定義和灰度發佈流程，從概念和流程中明確灰度的目的並梳理出流程中系統工具能夠支撐的地方，那麼實現一套發佈系統須要考慮的地方也就清楚了。灰度發佈的目的首先是爲了應用從老版本升級到新版本的時候能作到平滑升級，升級過程當中一般會先按照必定發佈策略選取部分用戶流量，先行請求新版本的應用，經過收集這部分用戶對新版本應用的反饋，以及新版本應用實例自己的日誌、性能、穩定性等指標來評審新版應用。根據評審狀況，決定是否繼續增長新版本的應用實例和流量佔比，直至全量升級，或者發現問題回滾至老版本。對應的灰度發佈流程圖以下：

根據以上的灰度發佈的概念和流程定義，一套灰度發佈系統須要咱們考慮的問題也就一目瞭然。

1. 發佈策略定製

新版本應用的部署在灰度發佈流程中每每會分多個階段，並逐漸增長實例數，例如一次灰度發佈一共分3個階段，新版本的部署實例數量會在3個階段中逐漸增長，從10個、50個一直增長到100個。這樣作是爲了保證應用總體功能的穩定運行，在每一個階段結束時咱們均可以觀察評審新版本的效果，根據階段發佈效果來決定是否繼續增長新版本的實例，或者在發現問題的時候採起策略回滾。另外一方面，爲了增長髮布流程的自動化程度，灰度發佈系統會考慮支持在不一樣階段之間增長自動化執行的功能，固然用戶也會有階段之間加入人工審覈的需求須要灰度發佈平臺支持。所以支持定製多階段發佈策略的功能對灰度發佈系統來講是必要的。

2. 流量配比

在灰度發佈流程中，當流量入口的負載均衡策略是簡單的按實例數均衡分配的話，那不一樣應用版本處理的流量比就是實例數量比，但在必定場景下這樣實現就限制了用戶流量配置的使用方式，例如假設用戶受到資源限制想用較少新版實例來處理較大的流量比例就作不到了。灰度發佈平臺仍是須要考慮應用新舊版本流量配比的功能，這樣結合上一點中提到的定製發佈策略的功能，用戶可以對新版版本處理的用戶流量比實現更加精確的控制。像網易輕舟產品實現的灰度發佈功能，已經實現了與服務網格（service mesh）技術的協同，可以精確控制每一個應用版本的流量配比。

3. 日誌與監控

在灰度發佈流程的每一個階段，發佈人都須要根據當時新版本的運行狀況來決定後續是繼續升級流程仍是發現問題直接回滾，而灰度發佈系統就須要爲用戶提供儘量多的判斷指標和參考數據，例如須要支持用戶查看部署實例的運行日誌，以及提供CPU、內存使用率、網卡流量等監控數據來爲新版應用的功能和穩定性判斷提供依據。

4. 快速回滾

對部署系統來講，應用的任何一次上線升級都須要具有快速回滾的能力，以便當出現問題可以及時恢復老的穩定版本，控制損失。回滾功能具體要實現新版實例的下線或刪除，老版實例的從新建立，以及流量從新切換到老版本。

5. 告警功能

發佈系統須要對整個發佈流程負責。在對接用戶的過程當中，本人也碰到過用戶反饋灰度過程新舊版本共存時間較長，但願對未完成的灰度流程給出即時告警的需求，例如一些移動端app的新版本上線後，須要運行一段時間，來調研獲取用戶對新功能的反饋，這時候發佈系統若是可以及時提醒用戶當前未完成的灰度發佈流程，以及流程中的新舊版本應用信息就顯得十分必要了。另外一方面，發佈系統也須要及時對監控指標給出告警，好比因爲新版本上線致使的CPU使用率、內存使用率上升的狀況可以及時通知發佈人員進行處理。

從網易雲多年的devops產品設計和開發經驗來看，以上五點是一個灰度發佈系統必不可缺的，目前網易輕舟devops產品正是按着這些要求實現了主機和容器的灰度發佈功能，當用戶在輕舟平臺上進行灰度發佈的時候，可以定製發佈時每一個階段新老版本實例比例和流量比例，同時控制每一個階段結束時系統自動入下一階段或者人工審覈操做的關鍵節點，一旦發現問題，支持用戶快速回滾，同時系統也對接了應用日誌和監控數據查看、告警通知、應用版本管理、製品管理等功能，實現了應用發佈的閉環管理。