要了解一個灰度發布系統的功能，個人覺得有必要先了解灰度發布的概念定義和灰度發布流程，從概念和流程中明確灰度的目的並梳理出流程中系統工具可以支撐的地方，那么實現一套發布系統需要考慮的地方也就清楚了。灰度發布的目的首先是為了應用從老版本升級到新版本的時候能做到平滑升級，升級過程中通常會先按照一定發布策略選取部分用戶流量，先行請求新版本的應用，通過收集這部分用戶對新版本應用的反饋，以及新版本應用實例本身的日志、性能、穩定性等指標來評審新版應用。根據評審情況，決定是否繼續增加新版本的應用實例和流量占比，直至全量升級，或者發現問題回滾至老版本。對應的灰度發布流程圖如下：
根據以上的灰度發布的概念和流程定義，一套灰度發布系統需要我們考慮的問題也就一目了然。
1. 發布策略定制
新版本應用的部署在灰度發布流程中往往會分多個階段，並逐漸增加實例數，例如一次灰度發布一共分3個階段，新版本的部署實例數量會在3個階段中逐漸增加，從10個、50個一直增加到100個。這樣做是為了保證應用整體功能的穩定運行，在每個階段結束時我們都可以觀察評審新版本的效果，根據階段發布效果來決定是否繼續增加新版本的實例，或者在發現問題的時候采取策略回滾。另一方面，為了增加發布流程的自動化程度，灰度發布系統會考慮支持在不同階段之間增加自動化執行的功能，當然用戶也會有階段之間加入人工審核的需求需要灰度發布平台支持。因此支持定制多階段發布策略的功能對灰度發布系統來說是必要的。
2. 流量配比
在灰度發布流程中，當流量入口的負載均衡策略是簡單的按實例數均衡分配的話，那不同應用版本處理的流量比就是實例數量比，但在一定場景下這樣實現就限制了用戶流量配置的使用方式，例如假設用戶受到資源限制想用較少新版實例來處理較大的流量比例就做不到了。灰度發布平台還是需要考慮應用新舊版本流量配比的功能，這樣結合上一點中提到的定制發布策略的功能，用戶能夠對新版版本處理的用戶流量比實現更加精確的控制。像網易輕舟產品實現的灰度發布功能，已經實現了與服務網格（service mesh）技術的協同，能夠精確控制每個應用版本的流量配比。
3. 日志與監控
在灰度發布流程的每個階段，發布人都需要根據當時新版本的運行情況來決定后續是繼續升級流程還是發現問題直接回滾，而灰度發布系統就需要為用戶提供盡可能多的判斷指標和參考數據，例如需要支持用戶查看部署實例的運行日志，以及提供CPU、內存使用率、網卡流量等監控數據來為新版應用的功能和穩定性判斷提供依據。
4. 快速回滾
對部署系統來說，應用的任何一次上線升級都需要具備快速回滾的能力，以便當出現問題能夠及時恢復老的穩定版本，控制損失。回滾功能具體要實現新版實例的下線或刪除，老版實例的重新創建，以及流量重新切換到老版本。
5. 告警功能
發布系統需要對整個發布流程負責。在對接用戶的過程中，本人也碰到過用戶反饋灰度過程新舊版本共存時間較長，希望對未完成的灰度流程給出即時告警的需求，例如一些移動端app的新版本上線后，需要運行一段時間，來調研獲取用戶對新功能的反饋，這時候發布系統如果能夠及時提醒用戶當前未完成的灰度發布流程，以及流程中的新舊版本應用信息就顯得十分必要了。另一方面，發布系統也需要及時對監控指標給出告警，比如由於新版本上線導致的CPU使用率、內存使用率上升的情況能夠及時通知發布人員進行處理。
從網易雲多年的devops產品設計和開發經驗來看，以上五點是一個灰度發布系統必不可缺的，目前網易輕舟devops產品正是按着這些要求實現了主機和容器的灰度發布功能，當用戶在輕舟平台上進行灰度發布的時候，能夠定制發布時每個階段新老版本實例比例和流量比例，同時控制每個階段結束時系統自動入下一階段或者人工審核操作的關鍵節點，一旦發現問題，支持用戶快速回滾，同時系統也對接了應用日志和監控數據查看、告警通知、應用版本管理、制品管理等功能，實現了應用發布的閉環管理。