分布式中灰度方案就該這樣設(shè)計(jì)

一、背景簡(jiǎn)介

分布式系統(tǒng)中會(huì)存在這樣的開(kāi)發(fā)場(chǎng)景，不同需求可能涉及到對(duì)同一個(gè)服務(wù)的開(kāi)發(fā)，那么該服務(wù)在研發(fā)期間就會(huì)存在多個(gè)版本并行的狀態(tài)，為了保持不同版本之間的隔離性，驗(yàn)收需要將請(qǐng)求路由到指定版本號(hào)的服務(wù)上處理；

假設(shè)存在三個(gè)服務(wù)：A、B、C，且服務(wù)B和C都存在多個(gè)版本，那么讓請(qǐng)求按照即定的路由規(guī)則執(zhí)行，即可保證研發(fā)期間的驗(yàn)收是版本間隔離的，并且可以實(shí)現(xiàn)灰度部署的策略；

二、負(fù)載策略

在微服務(wù)系統(tǒng)架構(gòu)中，請(qǐng)求在服務(wù)間轉(zhuǎn)發(fā)時(shí)會(huì)執(zhí)行負(fù)載的策略，尤其當(dāng)服務(wù)存在多版本號(hào)的集群模式時(shí)，很顯然常規(guī)的輪詢(xún)、權(quán)重、隨機(jī)等策略無(wú)法滿(mǎn)足需求；進(jìn)行路由規(guī)則的自定義設(shè)計(jì)和開(kāi)發(fā)是常見(jiàn)方式；

經(jīng)典應(yīng)用場(chǎng)景：在請(qǐng)求發(fā)起時(shí)，可以通過(guò)Header、Cookie、Parameter等不同的方式，攜帶路由規(guī)則的方式與參數(shù)執(zhí)行匹配邏輯，從而將請(qǐng)求路由到指定版本的服務(wù)；

默認(rèn)主分支路由

通常來(lái)說(shuō)請(qǐng)求會(huì)在主干分支上執(zhí)行，或者其他分支路由規(guī)則不匹配，也可以通過(guò)標(biāo)識(shí)配置，判斷是否由主分支兜底，甚至是存活的任意服務(wù)兜底；

存活的服務(wù)中可能存在多個(gè)版本，但是主分支Master是否存活是服務(wù)健康與否的基本標(biāo)志，常規(guī)應(yīng)用中路由規(guī)則如果不匹配，會(huì)由Master服務(wù)進(jìn)行兜底；

版本號(hào)統(tǒng)一路由

請(qǐng)求通過(guò)攜帶分支號(hào)進(jìn)行統(tǒng)一版本路由是常用的輕量級(jí)方案，即如果請(qǐng)求攜帶的是2.0.0的分支，則在路由時(shí)優(yōu)先匹配相關(guān)版本的服務(wù)，不匹配時(shí)由Master服務(wù)處理即可；

服務(wù)定制化路由

在請(qǐng)求或配置中指定各個(gè)服務(wù)的路由分支號(hào)，也是常見(jiàn)的匹配方案，如上圖在請(qǐng)求時(shí)指定服務(wù)B由1.0.0分支執(zhí)行，服務(wù)C由3.0.0分支執(zhí)行，其余服務(wù)在主干分支執(zhí)行；

路由規(guī)則可以看做是對(duì)可用服務(wù)的匹配篩選，如果篩選出來(lái)的服務(wù)存在集群部署時(shí)，還要去執(zhí)行相應(yīng)的負(fù)載均衡策略，例如上圖中當(dāng)服務(wù)C的3.0.0分支是集群時(shí)，路由匹配到該版本后，再通過(guò)負(fù)載均衡的策略選中其中一個(gè)服務(wù)處理請(qǐng)求；

三、灰度部署

當(dāng)負(fù)載均衡的策略可以按照定制化開(kāi)發(fā)的規(guī)則執(zhí)行時(shí)，那服務(wù)的灰度發(fā)布就會(huì)容易很多，在不影響現(xiàn)有服務(wù)的情況下發(fā)布新版本，同時(shí)將請(qǐng)求按照規(guī)則分流，完成對(duì)新服務(wù)的驗(yàn)收后，替換掉舊版本即可；

分布式系統(tǒng)中子服務(wù)的拆分非常多，版本開(kāi)發(fā)通常只會(huì)涉及其中部分子服務(wù)，通過(guò)灰度模式將相關(guān)服務(wù)部署到線(xiàn)上，并且不會(huì)影響主干的服務(wù)，只有開(kāi)啟特定的配置才會(huì)將請(qǐng)求分流到灰度服務(wù)；

流程細(xì)節(jié)

1、做好路由配置和管理，請(qǐng)求默認(rèn)在主干服務(wù)執(zhí)行；

2、部署版本涉及的相關(guān)服務(wù)，灰度層面默認(rèn)不會(huì)處理請(qǐng)求；

3、驗(yàn)收階段基于配置，將指定規(guī)則的請(qǐng)求路由到灰度層；

4、常用規(guī)則：攜帶分支號(hào)、灰度用戶(hù)群、比例分流、IP等；

5、完成灰度服務(wù)驗(yàn)收后，將相關(guān)服務(wù)標(biāo)記為主干服務(wù)；

6、將舊的主干服務(wù)下線(xiàn)后，即本次上線(xiàn)流程完整結(jié)束；

7、若發(fā)現(xiàn)灰度服務(wù)驗(yàn)收失敗，撤掉灰度層或修改都可以；

灰度發(fā)布的模式即依賴(lài)于自定義的路由規(guī)則，以及服務(wù)在負(fù)載均衡時(shí)權(quán)重比例傾斜，這些都可以在配置中心管理，在測(cè)試時(shí)動(dòng)態(tài)修改即可；

在這種模式下，灰度服務(wù)的上線(xiàn)或者下線(xiàn)幾乎是沒(méi)有明顯感知的，如果是相對(duì)簡(jiǎn)單的流程，由測(cè)試人員驗(yàn)收灰度層服務(wù)即可，如果是復(fù)雜的流程，放開(kāi)一定比例的用戶(hù)流量，流程觀(guān)察沒(méi)有問(wèn)題后完成升級(jí)；

四、實(shí)踐方案

1、流程設(shè)計(jì)

在灰度方案落地實(shí)踐的過(guò)程中，通?？蛻?hù)端會(huì)攜帶路由規(guī)則的標(biāo)識(shí)，從而將請(qǐng)求發(fā)送到指定服務(wù)，在規(guī)則無(wú)法正常匹配的時(shí)候，由主干服務(wù)處理，對(duì)于一些核心的開(kāi)關(guān)標(biāo)識(shí)在配置中心統(tǒng)一維護(hù)；

2、路由標(biāo)識(shí)

標(biāo)識(shí)獲取

通常情況下，路由的標(biāo)識(shí)是在請(qǐng)求頭中攜帶的，這樣比較方便統(tǒng)一管理，常用的傳遞格式如下:

版本號(hào)統(tǒng)一路由：routeId:2.0.0，即所有請(qǐng)求優(yōu)先在2.0.0分支執(zhí)行；

服務(wù)定制化路由：serverC:3.0.0，請(qǐng)求服務(wù)C時(shí)優(yōu)先在3.0.0分支執(zhí)行；

在微服務(wù)的組件中獲取請(qǐng)求頭的方式很多，比如Gateway網(wǎng)關(guān)中的路由過(guò)濾器，或者服務(wù)中的攔截器，都可以獲取請(qǐng)求的相關(guān)參數(shù)信息，從而執(zhí)行路由規(guī)則；

標(biāo)識(shí)管理

自定義路由規(guī)則需要客戶(hù)端標(biāo)識(shí)，雖然獲取請(qǐng)求中的標(biāo)識(shí)并不復(fù)雜，但是將標(biāo)識(shí)傳遞到路由規(guī)則中就涉及到上下文參數(shù)管理：

寫(xiě)階段：在過(guò)濾或攔截中獲取路由標(biāo)識(shí)，寫(xiě)入上下文容器；

讀階段：路由時(shí)從容器中讀取標(biāo)識(shí)，基于配置信息執(zhí)行規(guī)則；

請(qǐng)求從進(jìn)入網(wǎng)關(guān)開(kāi)始，在服務(wù)間通信時(shí)會(huì)涉及負(fù)載均衡的策略，在過(guò)濾或攔截器中將標(biāo)識(shí)寫(xiě)到上下文容器，執(zhí)行路由規(guī)則需要讀取上下文容器，如果標(biāo)識(shí)不存在則默認(rèn)選擇主干服務(wù)執(zhí)行請(qǐng)求；

3、服務(wù)選中

微服務(wù)之間通信時(shí)，選中一個(gè)服務(wù)執(zhí)行請(qǐng)求的邏輯比較復(fù)雜，尤其在灰度模式下涉及到對(duì)路由規(guī)則的改造，即策略指定的服務(wù)優(yōu)先被選中；

1、從注冊(cè)中心查詢(xún)相應(yīng)服務(wù)的可用列表；

2、基于路由規(guī)則，匹配符合請(qǐng)求標(biāo)識(shí)的服務(wù)；

3、對(duì)篩選的結(jié)果列表執(zhí)行負(fù)載均衡，選中服務(wù)；

在整個(gè)路由機(jī)制中，會(huì)涉及到匹配規(guī)則自定義改造，從常規(guī)的手段來(lái)看，將版本的分支號(hào)加載到服務(wù)的元數(shù)據(jù)信息中，再結(jié)合服務(wù)名稱(chēng)或者IP地址，來(lái)實(shí)現(xiàn)對(duì)服務(wù)列表的多維度過(guò)濾，可以支撐大部分輕量級(jí)灰度策略的實(shí)現(xiàn)。

審核編輯：劉清