摘要：就是一種灰度發布方式，讓一部分用戶繼續用，一部分用戶開始用，如果用戶對沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現調整問題，以保證其影響度。

一、背景
互聯網產品開發有個非常特別的地方，就是不停的升級，升級，再升級。采用敏捷開發的方式，基本上保持每周或者每兩周一次的發布頻率，系統升級總是伴隨著各種風險，新舊版本兼容的風險，用戶使用習慣突然改變而造成用戶流失的風險，系統宕機的風險，500錯誤服務不可用的風險等等。為了避免這些風險，很多產品都采用了灰度發布的策略，其主要思想就是把影響集中到一個點，然后再發散到一個面，出現意外情況后很容易就回退，即使影響也是可控的。
任何脫離實際業務的技術工作都是耍流氓，技術需要服務于業務。因此，本文盡量淡化了業務方面的因素，聚焦于技術層面，建議在實際運用中還是要根據各自的業務場景去變化和調整。

二、什么是灰度
灰度發布是指在黑與白之間，能夠平滑過渡的一種發布方式。AB test就是一種灰度發布方式，讓一部分用戶繼續用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
互聯網系統，灰度其實就是根據設定的規則將請求路由到我們的灰度版本（灰度機器）上來。比如對于API來說，一般有如下幾個需求：特定用戶（比如測試帳號）、 特定的App（比如測試app或者合作App）、特定的模塊、接口（只有某些接口需要灰度，這種一般是API Container的修改，拿一些不是很重要的API做灰度測試）、特定的機器（某些請求IP轉發到灰度機）等。

三、灰度的優勢
1、 在發布過程中降低上線風險
2、 降低影響范圍，并且范圍可控
3、 降低對測試的依賴，減少線下自測的數據構造成本
4、 特定的請求能夠指向特定的服務器，方便集中監控日志，方便跟蹤完整的調用鏈路
5、 方便系統流量切入
6、 便于隨時回滾
7、 指定特定人群，方便系統回訪，方便產品需求收集，完善產品功能，提升產品質量
8、 在無狀態的情況下保障用戶使用到的版本一致
9、 避免宕機給用戶帶來不好的體驗和使用

四、目標
1、 做到對現有業務系統無侵入性
2、 能夠發揮以上提到的灰度的優勢
3、 發布系統的靈活配置
4、 發布系統和業務系統的松耦合
5、 和網關系統結合，讓操作平滑

五、功能
1、 路由策略管理/配置
2、 灰度規則管理
3、 開啟/關閉開關

六、系統設計
需要設計的系統分為兩種場景，一種是http方式接入，需要借助網關(gate-way)去實現流量的切換，和系統路由；另一種是rpc接入(目前為dubbo)，需要借助dubbo提供的負載均衡策略
來實現，結合自帶的qos(dubbo的在線運維命令)實現服務啟動/關閉。
【說明】：服務內部執行線程監控待定，sentinel 、 pinpoint or other。

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 服務的持續發布：

dubbo-consumer實現不同的負載均衡，在負載的時候進行白名單校驗和策略選擇。系統對灰度管控平臺非強制依賴，管控平臺出現問題不影響系統正常運行。
負載動態路由，阻止后續流量進入，監控服務是否還有執行的線程，加入鉤子offline服務或者接口，進行服務升級，自檢，啟動online，接入負載均衡。

由于很多接口都有在Dubbo中進行注冊，因此需要有辦法能夠對其Provider Service接口進行下線或屏蔽，使其不提供服務，即其它服務無法調用它的接口。
Service接口下線后，此consumer機器自然無任何流量流入，因此也無流量返回，達到下線consumer機器的目的，然后即可部署代碼。
官方有提供Dubbo-Admin工具，用于對Dubbo中各APP及其Service接口進行管理，里面自然也包含有實現下線的功能，可以有3種方法：
屏蔽，貌似一直沒有效果(尷尬)；
禁用，可以成功禁用；
權重調節，可以設置0-100的權重，設置為0時即不提供服務。

經過權重調節方案，通過Dubbo-Admin對需要下線機器的APP應用接口權限設置為0。

實現的功能：
1、緩存負載策略
在系統啟動的時候要根據系統配置拉取灰度策略，并且保存在內存中，定時獲取最新的負載策略，需要提供及時觸發的策略更新接口。
2、 負載均衡
在系統上線之前選擇運行時使用的負載均衡進行調用。
3、系統配置
系統在上線前需要錄入管控平臺，并且完成相應的配置，在啟動的時候作為唯一標識能夠拉取相應的配置。
4、監控和統計
系統在內存中緩存統計信息，定時上傳管控平臺，監控出現問題不影響系統正常使用（sentinel,or dubbo-amdin模塊擴展）。
5、qos運維工具
系統的啟動使用qos，停服采用延時關閉結合jvm鉤子。

七、檢查機制

為了平滑發布的順利進行，檢查確認機制不可或缺，即確保Dubbo/Http中的下線都已生效，并且無流量發生，我們從以下兩個維度去檢查：

接口檢查，調用Dubbo、Http的API接口，檢查業務服務機器狀態，是否為已經下線。當然，在做了下線功能的同時，我們也有檢查功能和上線功能，可供調用。
監控檢查，調用監控平臺(ELK)的API接口，檢查業務服務機器的請求訪問數和日志流量是否都已經為0，已經處于下線狀態。
經過上述改造后，我們新的發布流程如下，基本解決了平滑發布問題，發布時對業務的影響降到了最低；

八、停服/啟服后小范圍驗證
1.灰度驗證--不影響線上用戶
2.部分實例發布-- 導部分流量到新實例（可通過網關路由規則：用戶ID取模，區域限制等等）
3.全部發布