網關實現灰度發佈

1、背景
互聯網產品開發有個很是特別的地方，就是不停的升級，升級，再升級。採用敏捷開發的方式，基本上保持每週或者每兩週一次的發佈頻率，系統升級老是伴隨着各類風險，新舊版本兼容的風險，用戶使用習慣忽然改變而形成用戶流失的風險，系統宕機的風險，500錯誤服務不可用的風險等等。爲了不這些風險，不少產品都採用了灰度發佈的策略，其主要思想就是把影響集中到一個點，而後再發散到一個面，出現意外狀況後很容易就回退，即便影響也是可控的。
任何脫離實際業務的技術工做都是耍流氓，技術須要服務於業務。所以，本文儘可能淡化了業務方面的因素，聚焦於技術層面，建議在實際運用中仍是要根據各自的業務場景去變化和調整。

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

3、灰度的優點
一、 在發佈過程當中下降上線風險
二、 下降影響範圍，而且範圍可控
三、 下降對測試的依賴，減小線下自測的數據構形成本
四、 特定的請求可以指向特定的服務器，方便集中監控日誌，方便跟蹤完整的調用鏈路
五、 方便系統流量切入
六、 便於隨時回滾
七、 指定特定人羣，方便系統回訪，方便產品需求收集，完善產品功能，提高產品質量
八、 在無狀態的狀況下保障用戶使用到的版本一致
九、 避免宕機給用戶帶來很差的體驗和使用

4、目標
一、 作到對現有業務系統無侵入性
二、 可以發揮以上提到的灰度的優點
三、 發佈系統的靈活配置
四、 發佈系統和業務系統的鬆耦合
五、 和網關係統結合，讓操做平滑

5、功能
一、 路由策略管理/配置
二、 灰度規則管理
三、 開啓/關閉開關

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

一、http方式接入

其中分爲幾個重要的部分：
接入層網關，接入客戶端請求，根據下發的配置將符合條件的請求轉發到新舊系統上．
配置管理後臺，這個後臺能夠配置不一樣的轉發策略給接入層網關．
穩定和灰度兩種處理客戶端請求的業務服務器．

http請求的入口都落在網關上，網關會根據管控平臺(admin dashboard)的配置進行uri的選擇。此時請求數據會判斷當前應用是否已經開啓灰度，再次判斷是應用級別的灰度仍是服務級別的灰度，而後根據管控平臺配置的灰度策略進行灰度，能夠支持白名單、權重、ip段、業務域等。
管控平臺會調用引擎管理執行相應的指令，進行關閉、開啓、更新策略和白名單數據等，每次網關從新reload和重啓時會從灰度管理系統調用接口讀取配置應用的信息，加入緩存。
爲了提高性能，應用的基本信息、灰度策略、白名單等數據緩存在內存或者類redis這樣的緩衝中，靈活的進行緩存數據的更新。
實現功能：
一、動態路由
二、服務動態編排，實現流量的自由切換
三、啓服/停服
四、服務自檢

二、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。

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

7、檢查機制

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

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

8、停服/啓服後小範圍驗證1.灰度驗證--不影響線上用戶2.部分實例發佈-- 導部分流量到新實例（可經過網關路由規則：用戶ID取模，區域限制等等）3.所有發佈