關於灰度發佈的感想

最近在研究springcloud，其中重要的就是服務的治理，各種接口與應用漫天飛，開發人員與運維實施人員不斷的扯皮。曾幾何時內部開發的RPC遠程訪問接口，在實施部署過程中費時勞力。

微服務接口的版本控制，代碼的版本管理，最後到運維實施部署階段就是灰度發佈的管理，應該都是軟件工程不同階段的管理範疇。

• 選定策略：包括用戶規模、發佈頻率、功能覆蓋度、回滾策略、運營策略、新舊系統部署策略等
• 篩選用戶：包括用戶特徵、用戶數量、用戶常用功能、用戶範圍等
• 部署系統：部署新系統、部署用戶行爲分析系統（web analytics）、設定分流規則、運營數據分析、分流規則微調
• 發佈總結：用戶行爲分析報告、用戶問卷調查、社會化媒體意見收集、形成產品功能改進列表

灰度發佈按端分類

1. web頁面灰度：按照IP或者用戶ID切流啊。具有隨機性，可以控制比例
2. 服務端灰度：考驗主系分能力了，可以做邏輯切換開關，按照義務相關屬性逐漸切流
3. 客戶端灰度：一般按照用戶逐漸推送包，主要是PC端(WIN，MAC)、移動端（安卓，OS）內部大規模內測

4. 數據庫的灰度升級：首先數據全量複製，雙寫，最後去掉老數據庫

發佈策略

• 單策略：基於IP地址、用戶ID、版本tag，用戶自主升級。
• 基於上下文灰度發佈策略：不限於地理位置、用戶終端特性（如分辨率、性能）、用戶自身特點（性別、年齡、忠誠度等）

新版本回滾策略

• 當新版本灰度發佈表現不佳時，應回滾至舊版本。對於純粹的Web應用而言，回滾相對簡單。主要難點在於用戶數據的無縫切換。對於客戶端應用，如果期待用戶自行卸載新版本另行安裝舊版本，成本和流失率都太高。可以考慮通過快速另行發佈新版本，利用升級來“回滾”，覆蓋上次灰度發佈的修改。
• 對於移動客戶端，iOS TestFlight 實現灰度發佈，安卓APP直接發佈新版本覆蓋有問題版本。

灰度發佈工具

1. Nginx灰度發佈： Nginx+LUA方式、根據Cookie實現灰度發佈、根據來路IP實現灰度發佈

2. 使用optimizely做A/B測試

 

 

 

 

參考：

https://www.jianshu.com/p/93a542855251

https://www.cnblogs.com/todsong/p/3918406.html