一、背景網際網路產品開發有個非常特別的地方，就是不停的公升級，公升級，再公升級。採用敏捷開發的方式，基本上保持每週或者每兩周一次的發布頻率，系統公升級總是伴隨著各種風險，新舊版本相容的風險，使用者使用習慣突然改變而造成使用者流失的風險，系統宕機的風險，500錯誤服務不可用的風險等等。為了避免這些風險，很多產品都採用了灰度發布的策略，其主要思想就是把影響集中到乙個點，然後再發散到乙個面，出現意外情況後很容易就回退，即使影響也是可控的。任何脫離實際業務的技術工作都是耍流氓，技術需要服務於業務。因此，本文盡量淡化了業務方面的因素，聚焦於技術層面，建議在實際運用中還是要根據各自的業務場景去變化和調整。
三、灰度的優勢1、 在發布過程中降低上線風險2、 降低影響範圍，並且範圍可控3、 降低對測試的依賴，減少線下自測的資料構造成本4、 特定的請求能夠指向特定的伺服器，方便集中監控日誌，方便跟蹤完整的呼叫鏈路5、 方便系統流量切入6、 便於隨時回滾7、 指定特定人群，方便系統回訪，方便產品需求收集，完善產品功能，提公升產品質量8、 在無狀態的情況下保障使用者使用到的版本一致9、 避免宕機給使用者帶來不好的體驗和使用
四、目標1、 做到對現有業務系統無侵入性2、 能夠發揮以上提到的灰度的優勢3、 發布系統的靈活配置4、 發布系統和業務系統的松耦合5、 和閘道器系統結合，讓操作平滑
五、功能1、 路由策略管理/配置2、 灰度規則管理3、 開啟/關閉開關
1、http方式接入
其中分為幾個重要的部分：接入層閘道器，接入客戶端請求，根據下發的配置將符合條件的請求**到新舊系統上．配置管理後台，這個後台可以配置不同的**策略給接入層閘道器．穩定和灰度兩種處理客戶端請求的業務伺服器．
http請求的入口都落在閘道器上，閘道器會根據管控平台(admin dashboard)的配置進行uri的選擇。此時請求資料會判斷當前應用是否已經開啟灰度，再次判斷是應用級別的灰度還是服務級別的灰度，然後根據管控平台配置的灰度策略進行灰度，可以支援白名單、權重、ip段、業務域等。管控平台會呼叫引擎管理執行相應的指令，進行關閉、開啟、更新策略和白名單資料等，每次閘道器重新reload和重啟時會從灰度管理系統呼叫介面讀取配置應用的資訊，加入快取。為了提公升效能，應用的基本資訊、灰度策略、白名單等資料快取在記憶體或者類redis這樣的緩衝中，靈活的進行快取資料的更新。實現功能：1、動態路由2、服務動態編排，實現流量的自由切換3、啟服/停服4、服務自檢
2、rpc(dubbo)接入
如果直接停機重啟rpc service會有什麼影響：服務發布時，直接重啟tomcat，導致節點正在處理的請求會受到影響，嚴重時會有資料異常。服務發布時如果節點正在作為task_tracker執行lts任務，會導致任務失敗並retry。服務發布時如果節點正在消費rocketmq中的訊息，會導致訊息消費異常，甚至進入retry或dlq佇列。服務發布完成後沒有即時驗證機制，直接暴露給使用者，如有異常影響面很廣。線上無法同時存在新老版本的服務來用於長時間的驗證。竟然有這麼多問題，想想就可怕，淚崩~,因此必須想法優雅的實現服務的啟停，因此引出dubbo 服務的持續發布：
實現的功能：1、快取負載策略在系統啟動的時候要根據系統配置拉取灰度策略，並且儲存在記憶體中，定時獲取最新的負載策略，需要提供及時觸發的策略更新介面。2、 負載均衡在系統上線之前選擇執行時使用的負載均衡進行呼叫。3、系統配置系統在上線前需要錄入管控平台，並且完成相應的配置，在啟動的時候作為唯一標識能夠拉取相應的配置。4、監控和統計系統在記憶體中快取統計資訊，定時上傳管控平台，監控出現問題不影響系統正常使用(sentinel,or dubbo-amdin模組擴充套件)。5、qos運維工具系統的啟動使用qos，停服採用延時關閉結合jvm鉤子。
七、檢查機制
為了平滑發布的順利進行，檢查確認機制不可或缺，即確保dubbo/http中的下線都已生效，並且無流量發生，我們從以下兩個維度去檢查：
介面檢查，呼叫dubbo、http的api介面，檢查業務服務機器狀態，是否為已經下線。當然，在做了下線功能的同時，我們也有檢查功能和上線功能，可供呼叫。監控檢查，呼叫監控平台(elk)的api介面，檢查業務服務機器的請求訪問數和日誌流量是否都已經為0，已經處於下線狀態。經過上述改造後，我們新的發布流程如下，基本解決了平滑發布問題，發布時對業務的影響降到了最低；
八、停服/啟服後小範圍驗證1.灰度驗證--不影響線上使用者2.部分例項發布-- 導部分流量到新例項(可通過閘道器路由規則：使用者id取模，區域限制等等)3.全部發布
歡迎關注運維自研堂訂閱號，運維自研堂是乙個技術分享平台，主要是運維自動化開發：linux、python、django、saltstack、tornado、bootstrap、redis、golang、docker、etcd、k8s、ci/cd、devops等經驗分享。
開源 創新 共享
投稿&商務合作
牛人並不可怕，可怕的是牛人比我們還努力！
長按，識別加入我們！
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
藍綠發布 灰度發布和滾動發布
2.灰度發布 3.滾動發布 4.小結 應用程式公升級面臨最大挑戰是新舊業務切換，將軟體從測試的最後階段帶到生產環境，同時要保證系統不間斷提供服務 長期以來，業務公升級漸漸形成了幾個發布策略 藍綠發布 灰度發布和滾動發布 這些發布方案目的是盡可能避免因發布導致的流量丟失或服務不可用問題。1.1 發布流...