灰度调节_网关实现灰度发布
一、背景互聯網產品開發有個非常特別的地方，就是不停的升級，升級，再升級。采用敏捷開發的方式，基本上保持每周或者每兩周一次的發布頻率，系統升級總是伴隨著各種風險，新舊版本兼容的風險，用戶使用習慣突然改變而造成用戶流失的風險，系統宕機的風險，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.全部發布
歡迎關注運維自研堂訂閱號，運維自研堂是一個技術分享平臺，主要是運維自動化開發：linux、python、django、saltstack、tornado、bootstrap、redis、golang、docker、etcd、k8s、ci/cd、devops等經驗分享。
容器平臺自動化CI/CD流水線實操
云原生語義化 CI/CD最佳實踐
【提速500%】讓Drone飛起來
小孩子也能看懂的kubernetes教程
谷歌開源 Kubernetes 原生 CI/CD 構建框架 Tekton
架構師是怎么煉成的
IPv6時代對業務的挑戰
如何打造一個安全穩定高效的容器云平臺
深入理解無服務器架構(Faas/Serverless)
CI/CD 場景價值
云原生架構及設計原則
Jira與Zabbix結合
【Zabbix】告警事件歸檔與提取
【HMonitor】Zabbix告警管理平臺
Zabbix 告警收斂
Zabbix v3.0微信報警及API使用
zabbix v3.0安裝部署及使用
Web權限設計
搭建 kubernetes 容器編排平臺
區塊鏈入門教程
基于Gogs+Drone搭建的私有CI/CD平臺
WEB架構設計心得
Docker與CI/CD
【實戰篇】Docker的CI/CD流水線實踐
基于 Harbor 搭建 Docker 私有鏡像倉庫
利用helm部署應用到kubernetes
開源 ? ?創新 ? ? 共享
投稿&商務合作
Mail：idevops168@163.com?? ? ??QQ:785249378? ? ?微信：Idevops001
牛人并不可怕，可怕的是牛人比我們還努力！
長按圖片，識別加入我們！
總結
以上是生活随笔為你收集整理的灰度调节_网关实现灰度发布的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mysql table keys_MyS
- 下一篇： canvas 插件_基于Angular的