要了解乙個灰度發布系統的功能，個人覺得有必要先了解灰度發布的概念定義和灰度發布流程，從概念和流程中明確灰度的目的並梳理出流程中系統工具可以支撐的地方，那麼實現一套發布系統需要考慮的地方也就清楚了。灰度發布的目的首先是為了應用從老版本公升級到新版本的時候能做到平滑公升級，公升級過程中通常會先按照一定發布策略選取部分使用者流量，先行請求新版本的應用，通過收集這部分使用者對新版本應用的反饋，以及新版本應用例項本身的日誌、效能、穩定性等指標來評審新版應用。根據評審情況，決定是否繼續增加新版本的應用例項和流量佔比，直至全量公升級，或者發現問題回滾至老版本。對應的灰度發布流程圖如下：
根據以上的灰度發布的概念和流程定義，一套灰度發布系統需要我們考慮的問題也就一目了然。
1. 發布策略定製
新版本應用的部署在灰度發布流程中往往會分多個階段，並逐漸增加例項數，例如一次灰度發布一共分3個階段，新版本的部署例項數量會在3個階段中逐漸增加，從10個、50個一直增加到100個。這樣做是為了保證應用整體功能的穩定執行，在每個階段結束時我們都可以觀察評審新版本的效果，根據階段發布效果來決定是否繼續增加新版本的例項，或者在發現問題的時候採取策略回滾。另一方面，為了增加發布流程的自動化程度，灰度發布系統會考慮支援在不同階段之間增加自動化執行的功能，當然使用者也會有階段之間加入人工審核的需求需要灰度發布平台支援。因此支援定製多階段發布策略的功能對灰度發布系統來說是必要的。
2. 流量配比
在灰度發布流程中，當流量入口的負載均衡策略是簡單的按例項數均衡分配的話，那不同應用版本處理的流量比就是例項數量比，但在一定場景下這樣實現就限制了使用者流量配置的使用方式，例如假設使用者受到資源限制想用較少新版例項來處理較大的流量比例就做不到了。灰度發布平台還是需要考慮應用新舊版本流量配比的功能，這樣結合上一點中提到的定製發布策略的功能，使用者能夠對新版版本處理的使用者流量比實現更加精確的控制。像網易輕舟產品實現的灰度發布功能，已經實現了與服務網格（service mesh）技術的協同，能夠精確控制每個應用版本的流量配比。
3. 日誌與監控
在灰度發布流程的每個階段，發布人都需要根據當時新版本的運**況來決定後續是繼續公升級流程還是發現問題直接回滾，而灰度發布系統就需要為使用者提供盡可能多的判斷指標和參考資料，例如需要支援使用者檢視部署例項的執行日誌，以及提供cpu、記憶體使用率、網絡卡流量等監控資料來為新版應用的功能和穩定性判斷提供依據。
4. 快速回滾
5. 告警功能
從網易雲多年的devops產品設計和開發經驗來看，以上五點是乙個灰度發布系統必不可缺的，目前網易輕舟devops產品正是按著這些要求實現了主機和容器的灰度發布功能，當使用者在輕舟平台上進行灰度發布的時候，能夠定製發布時每個階段新老版本例項比例和流量比例，同時控制每個階段結束時系統自動入下一階段或者人工審核操作的關鍵節點，一旦發現問題，支援使用者快速回滾，同時系統也對接了應用日誌和監控資料檢視、告警通知、應用版本管理、製品管理等功能，實現了應用發布的閉環管理。
實現一套灰度發布系統需要考慮哪些問題？
仔細考慮一下灰度發布系統要達到哪些目的，基本就能有答案了。需要注意的是，客戶端應用 無論pc端還是移動端 的灰度發布要比web應用的灰度發布更為複雜，因為應用執行在使用者持有的終端上，資料採集和回滾都更為困難 但可採集的資料型別要更加豐富。注 本人缺乏移動客戶端產品的經驗，下述內容可能不適用於移動客...
搭建一套積分商城系統需要注意什麼？
越來越多的企業意識到積分 系統的重要性，一套積分 系統的開發，不僅可以拉新使用者，提高使用者活躍度，還可以提公升使用者留存率，從而提高企業的轉化效果。積分 系統的開發過程，有什麼需要我們注意的呢？1 從使用者角度出發，搭建完善的積分 系統 在開發之前，企業就應該從使用者角度去考慮問題，把握好使用者的...
HTC董事長稱考慮收購一套移動作業系統
雖然公司的意圖已經很明顯，但是在這件事情上htc不會按部就班。按台灣 社獲悉的訊息，htc對一些可選的選項進行了謹慎的討論，如果未來htc會買下一套作業系統的話，這絕不是一次衝動購買。雖然htc有意購買一套作業系統，但在問及何時會購買時htc卻沒有給出任何正面的回應。這或許是因為對於htc來說，無論...