建站
咨詢
售后
建站咨詢
新聞中心
一、背景簡介
分布式系統(tǒng)中會存在這樣的開發(fā)場景，不同需求可能涉及到對同一個服務(wù)的開發(fā)，那么該服務(wù)在研發(fā)期間就會存在多個版本并行的狀態(tài)，為了保持不同版本之間的隔離性，驗收需要將請求路由到指定版本號的服務(wù)上處理；
專注于為中小企業(yè)提供網(wǎng)站設(shè)計制作、網(wǎng)站制作服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)城陽免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了成百上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
假設(shè)存在三個服務(wù)：A、B、C，且服務(wù)B和C都存在多個版本，那么讓請求按照即定的路由規(guī)則執(zhí)行，即可保證研發(fā)期間的驗收是版本間隔離的，并且可以實現(xiàn)灰度部署的策略；
二、負(fù)載策略
在微服務(wù)系統(tǒng)架構(gòu)中，請求在服務(wù)間轉(zhuǎn)發(fā)時會執(zhí)行負(fù)載的策略，尤其當(dāng)服務(wù)存在多版本號的集群模式時，很顯然常規(guī)的輪詢、權(quán)重、隨機等策略無法滿足需求；進行路由規(guī)則的自定義設(shè)計和開發(fā)是常見方式；
經(jīng)典應(yīng)用場景：在請求發(fā)起時，可以通過Header、Cookie、Parameter等不同的方式，攜帶路由規(guī)則的方式與參數(shù)執(zhí)行匹配邏輯，從而將請求路由到指定版本的服務(wù)；
默認(rèn)主分支路由
通常來說請求會在主干分支上執(zhí)行，或者其他分支路由規(guī)則不匹配，也可以通過標(biāo)識配置，判斷是否由主分支兜底，甚至是存活的任意服務(wù)兜底；
存活的服務(wù)中可能存在多個版本，但是主分支Master是否存活是服務(wù)健康與否的基本標(biāo)志，常規(guī)應(yīng)用中路由規(guī)則如果不匹配，會由Master服務(wù)進行兜底；
版本號統(tǒng)一路由
請求通過攜帶分支號進行統(tǒng)一版本路由是常用的輕量級方案，即如果請求攜帶的是??2.0.0??的分支，則在路由時優(yōu)先匹配相關(guān)版本的服務(wù)，不匹配時由Master服務(wù)處理即可；
服務(wù)定制化路由
在請求或配置中指定各個服務(wù)的路由分支號，也是常見的匹配方案，如上圖在請求時指定服務(wù)B由??1.0.0???分支執(zhí)行，服務(wù)C由??3.0.0??分支執(zhí)行，其余服務(wù)在主干分支執(zhí)行；
路由規(guī)則可以看做是對可用服務(wù)的匹配篩選，如果篩選出來的服務(wù)存在集群部署時，還要去執(zhí)行相應(yīng)的負(fù)載均衡策略，例如上圖中當(dāng)服務(wù)C的??3.0.0??分支是集群時，路由匹配到該版本后，再通過負(fù)載均衡的策略選中其中一個服務(wù)處理請求；
三、灰度部署
當(dāng)負(fù)載均衡的策略可以按照定制化開發(fā)的規(guī)則執(zhí)行時，那服務(wù)的灰度發(fā)布就會容易很多，在不影響現(xiàn)有服務(wù)的情況下發(fā)布新版本，同時將請求按照規(guī)則分流，完成對新服務(wù)的驗收后，替換掉舊版本即可；
分布式系統(tǒng)中子服務(wù)的拆分非常多，版本開發(fā)通常只會涉及其中部分子服務(wù)，通過灰度模式將相關(guān)服務(wù)部署到線上，并且不會影響主干的服務(wù)，只有開啟特定的配置才會將請求分流到灰度服務(wù)；
流程細(xì)節(jié)
- 1、做好路由配置和管理，請求默認(rèn)在主干服務(wù)執(zhí)行；
- 2、部署版本涉及的相關(guān)服務(wù)，灰度層面默認(rèn)不會處理請求；
- 3、驗收階段基于配置，將指定規(guī)則的請求路由到灰度層；
- 4、常用規(guī)則：攜帶分支號、灰度用戶群、比例分流、IP等；
- 5、完成灰度服務(wù)驗收后，將相關(guān)服務(wù)標(biāo)記為主干服務(wù)；
- 6、將舊的主干服務(wù)下線后，即本次上線流程完整結(jié)束；
- 7、若發(fā)現(xiàn)灰度服務(wù)驗收失敗，撤掉灰度層或修改都可以；
灰度發(fā)布的模式即依賴于自定義的路由規(guī)則，以及服務(wù)在負(fù)載均衡時權(quán)重比例傾斜，這些都可以在配置中心管理，在測試時動態(tài)修改即可；
在這種模式下，灰度服務(wù)的上線或者下線幾乎是沒有明顯感知的，如果是相對簡單的流程，由測試人員驗收灰度層服務(wù)即可，如果是復(fù)雜的流程，放開一定比例的用戶流量，流程觀察沒有問題后完成升級；
四、實踐方案
1、流程設(shè)計
在灰度方案落地實踐的過程中，通?？蛻舳藭y帶路由規(guī)則的標(biāo)識，從而將請求發(fā)送到指定服務(wù)，在規(guī)則無法正常匹配的時候，由主干服務(wù)處理，對于一些核心的開關(guān)標(biāo)識在配置中心統(tǒng)一維護；
2、路由標(biāo)識
標(biāo)識獲取
通常情況下，路由的標(biāo)識是在請求頭中攜帶的，這樣比較方便統(tǒng)一管理，常用的傳遞格式如下:
- 版本號統(tǒng)一路由：routeId:2.0.0，即所有請求優(yōu)先在?
?2.0.0??分支執(zhí)行； - 服務(wù)定制化路由：serverC:3.0.0，請求服務(wù)C時優(yōu)先在?
?3.0.0??分支執(zhí)行；
在微服務(wù)的組件中獲取請求頭的方式很多，比如Gateway網(wǎng)關(guān)中的路由過濾器，或者服務(wù)中的攔截器，都可以獲取請求的相關(guān)參數(shù)信息，從而執(zhí)行路由規(guī)則；
標(biāo)識管理
自定義路由規(guī)則需要客戶端標(biāo)識，雖然獲取請求中的標(biāo)識并不復(fù)雜，但是將標(biāo)識傳遞到路由規(guī)則中就涉及到上下文參數(shù)管理：
- 寫階段：在過濾或攔截中獲取路由標(biāo)識，寫入上下文容器；
- 讀階段：路由時從容器中讀取標(biāo)識，基于配置信息執(zhí)行規(guī)則；
請求從進入網(wǎng)關(guān)開始，在服務(wù)間通信時會涉及負(fù)載均衡的策略，在過濾或攔截器中將標(biāo)識寫到上下文容器，執(zhí)行路由規(guī)則需要讀取上下文容器，如果標(biāo)識不存在則默認(rèn)選擇主干服務(wù)執(zhí)行請求；
3、服務(wù)選中
微服務(wù)之間通信時，選中一個服務(wù)執(zhí)行請求的邏輯比較復(fù)雜，尤其在灰度模式下涉及到對路由規(guī)則的改造，即策略指定的服務(wù)優(yōu)先被選中；
1、從注冊中心查詢相應(yīng)服務(wù)的可用列表；
2、基于路由規(guī)則，匹配符合請求標(biāo)識的服務(wù)；
3、對篩選的結(jié)果列表執(zhí)行負(fù)載均衡，選中服務(wù)；
在整個路由機制中，會涉及到匹配規(guī)則自定義改造，從常規(guī)的手段來看，將版本的分支號加載到服務(wù)的元數(shù)據(jù)信息中，再結(jié)合服務(wù)名稱或者IP地址，來實現(xiàn)對服務(wù)列表的多維度過濾，可以支撐大部分輕量級灰度策略的實現(xiàn)。
五、參考源碼
應(yīng)用倉庫：https://gitee.com/cicadasmile/butte-flyer-parent
組件封裝：https://gitee.com/cicadasmile/butte-frame-parent
本文名稱：聊聊分布式中灰度方案實踐
轉(zhuǎn)載注明：http://www.dlmjj.cn/article/dpgchgj.html
