vivo?互聯(lián)網(wǎng)業(yè)務(wù)就近路由技術(shù)實(shí)戰(zhàn)

一、問題背景

在vivo互聯(lián)網(wǎng)業(yè)務(wù)高速發(fā)展的同時(shí)，支撐的服務(wù)實(shí)例規(guī)模也越來越大，然而單個(gè)機(jī)房能承載的機(jī)器容量是有限的，于是同城多機(jī)房甚至多地域部署就成為了業(yè)務(wù)在實(shí)際部署過程中不得不面臨的場景。

一般情況下，同一個(gè)機(jī)房內(nèi)部的網(wǎng)絡(luò)調(diào)用平均時(shí)延在0.1ms左右，同城多個(gè)機(jī)房之間的平均時(shí)延在1ms左右，跨地域機(jī)房之間的網(wǎng)絡(luò)時(shí)延則更大，例如北京到上海的平均時(shí)延達(dá)到了30ms以上。

在業(yè)務(wù)多機(jī)房部署場景中，內(nèi)部服務(wù)如果存在大量的跨機(jī)房、甚至跨地域的網(wǎng)絡(luò)調(diào)用，則請求時(shí)延會(huì)顯著加大，會(huì)直接影響到服務(wù)質(zhì)量，甚至是用戶體驗(yàn)。

二、解決方案

要解決以上問題，只需要實(shí)現(xiàn)服務(wù)消費(fèi)者和服務(wù)提供者之間的網(wǎng)絡(luò)調(diào)用盡量是同機(jī)房內(nèi)部、或者是同地域即可，即服務(wù)消費(fèi)者在調(diào)用服務(wù)提供者時(shí)，優(yōu)先調(diào)用部署在本機(jī)房的服務(wù)提供者，當(dāng)本機(jī)房沒有部署該服務(wù)提供者時(shí)，再跨機(jī)房調(diào)用同地域的同城機(jī)房、甚至是跨地域機(jī)房的服務(wù)。

以上策略我們內(nèi)部稱為?就近路由。業(yè)務(wù)的就近路由示意圖如下：

為了簡單易用，vivo內(nèi)部的服務(wù)間調(diào)用均使用了RPC框架來實(shí)現(xiàn)，在Java技術(shù)棧方向，我們選擇了阿里巴巴開源的RPC框架 Dubbo，針對(duì)該場景的問題，我們擴(kuò)展了Dubbo框架的源碼實(shí)現(xiàn)，提供了?Dubbo就近路由能力。

三、技術(shù)原理說明

在服務(wù)提供者注冊服務(wù)時(shí)，把該實(shí)例節(jié)點(diǎn)的機(jī)房信息【我們內(nèi)部將機(jī)房標(biāo)簽定義為 app_loc 字段】注冊到注冊中心，在開啟了就近路由策略后，消費(fèi)者在過濾服務(wù)列表時(shí)，會(huì)自動(dòng)篩選、匹配和消費(fèi)者自己 app_loc 字段相同的服務(wù)提供者列表，從而實(shí)現(xiàn)就近路由訪問。我們實(shí)現(xiàn)的就近路由策略，在本機(jī)房存在對(duì)應(yīng)服務(wù)提供者的情況下，消費(fèi)者會(huì)優(yōu)先調(diào)用本機(jī)房的服務(wù)。

四、實(shí)現(xiàn)方案

開源版本的Dubbo框架并不提供就近路由能力，我們需要基于Dubbo框架源碼擴(kuò)展實(shí)現(xiàn)。Dubbo框架整體設(shè)計(jì)如下：【左側(cè)為服務(wù)消費(fèi)者使用的接口，右側(cè)為服務(wù)提供方使用的接口】。

我們知道，Dubbo框架中服務(wù)消費(fèi)者選擇具體的服務(wù)提供者實(shí)例調(diào)用的匹配、篩選邏輯是在 Consumer 側(cè)完成的，在 Cluster 層中，消費(fèi)者會(huì)先應(yīng)用用戶配置的 Router 規(guī)則，然后再符合規(guī)則的服務(wù)提供者列表中，使用 LoadBalance 策略選擇具體的服務(wù)提供者節(jié)點(diǎn)進(jìn)行調(diào)用。

結(jié)合Dubbo框架源碼實(shí)現(xiàn)，我們選擇基于Dubbo 2.7.x版本的router層擴(kuò)展接口?org.apache.dubbo.rpc.cluster.Router?實(shí)現(xiàn)一種新的路由方式，即就近路由(我們內(nèi)部標(biāo)識(shí)為 NearestRouter)。

有了具體的解決方案，我們很快就完成了代碼開發(fā)，內(nèi)部也發(fā)布了一個(gè)集成就近路由策略的Dubbo版本，但在實(shí)際的線上灰度和業(yè)務(wù)推廣過程中，我們實(shí)現(xiàn)的初版就近路由碰到了新的問題：

• 基于機(jī)房容量、機(jī)器成本等因素考慮，并不是所有的業(yè)務(wù)都實(shí)現(xiàn)了多機(jī)房部署，即有部分業(yè)務(wù)只實(shí)現(xiàn)了單機(jī)房部署，這部分業(yè)務(wù)的消費(fèi)方無法實(shí)現(xiàn)同機(jī)房內(nèi)部調(diào)用；

• 即使部分業(yè)務(wù)實(shí)現(xiàn)了多機(jī)房部署，但多個(gè)機(jī)房之間能提供的服務(wù)容量并不是相同的，對(duì)于服務(wù)容量較小的機(jī)房，如果一部分服務(wù)節(jié)點(diǎn)不可用，剩下的服務(wù)節(jié)點(diǎn)能提供的服務(wù)容量無法支撐本機(jī)房的消費(fèi)方調(diào)用時(shí)，會(huì)造成該機(jī)房內(nèi)的服務(wù)節(jié)點(diǎn)雪崩；
  
  

• 業(yè)務(wù)側(cè)在開啟就近路由策略時(shí)，希望消費(fèi)服務(wù)的業(yè)務(wù)方能逐個(gè)開啟，有一段時(shí)間的灰度觀察過程，保證更平滑的升級(jí)驗(yàn)證；而不是比較粗暴的要么開啟，要么關(guān)閉；

• 部分消費(fèi)者的Dubbo版本較低，不支持就近路由功能，或者不支持配置應(yīng)用維度的就近路由，在業(yè)務(wù)灰度過程中，希望能實(shí)現(xiàn)向前兼容，業(yè)務(wù)側(cè)不報(bào)錯(cuò)。

基于以上問題，我們細(xì)化了實(shí)現(xiàn)方案：

• 就近路由策略默認(rèn)不強(qiáng)制執(zhí)行，即當(dāng)本機(jī)房不存在服務(wù)提供者時(shí)，不再區(qū)分本機(jī)房、跨機(jī)房，就近路由策略自動(dòng)失效，優(yōu)先保障服務(wù)之間的正常調(diào)用；
  
  

• 支持設(shè)置就近路由策略的降級(jí)閾值，在調(diào)用本機(jī)房服務(wù)的過程中，當(dāng) 本機(jī)房服務(wù)實(shí)例數(shù)量 / 集群服務(wù)實(shí)例數(shù)量 得到的數(shù)值小于設(shè)置的降級(jí)閾值時(shí)，我們認(rèn)為當(dāng)前機(jī)房的服務(wù)容量無法支撐本機(jī)房的消費(fèi)方調(diào)用，就近路由策略自動(dòng)失效；
  
  

• 支持配置應(yīng)用維度的就近路由策略，即配置的就近路由策略可只針對(duì)配置的應(yīng)用生效，實(shí)現(xiàn)應(yīng)用維度的灰度效果；
  
  

• 實(shí)現(xiàn)Dubbo版本自動(dòng)校驗(yàn)?zāi)芰Γ粷M足開啟就近路由策略條件的業(yè)務(wù)，提示用戶不開啟。

有了以上細(xì)化方案，我們梳理的就近路由大致邏輯流程如下：

擴(kuò)展Dubbo框架 Router 接口實(shí)現(xiàn)的 NearestRouter 核心代碼如下：

public List> route(List> invokers, URL consumerUrl, Invocation invocation) throws RpcException { // validate application name (this.url -> routerUrl) String applicationName = getProperty(APP_NAME, consumerUrl.getParameter(CommonConstants.APPLICATION_KEY, "")); boolean validAppFlag = application.equals(applicationName) || CommonConstants.ANY_VALUE.equals(application); if (!validAppFlag) { return invokers; } String local = getProperty(APP_LOC); if (invokers == null || invokers.size() == 0) { return invokers; } List> result = new ArrayList>(); for (Invoker invoker: invokers) { String invokerLoc = getProperty(invoker, invocation, APP_LOC); if (local.equals(invokerLoc)) { result.add(invoker); } } if (result.size() > 0) { if (fallback){ // 開啟服務(wù)降級(jí)，available.ratio = 當(dāng)前機(jī)房可用服務(wù)節(jié)點(diǎn)數(shù)量 ／ 集群可用服務(wù)節(jié)點(diǎn)數(shù)量 int curAvailableRatio = (int) Math.floor(result.size() * 100.0d / invokers.size()); if (curAvailableRatio <= availableRatio) { return invokers; } } return result; } else if (force) { LOGGER.warn("The route result is empty and force execute. consumerIp: " NetUtils.getLocalHost() ", service: " consumerUrl.getServiceKey() ", appLoc: " local ", routerName: " this.getUrl().getParameterAndDecoded("name")); return result; } else { return invokers; }}

在vivo內(nèi)部的服務(wù)治理平臺(tái)上，我們提供了可視化的配置能力，頁面內(nèi)容如下：

通過擴(kuò)展Dubbo框架，服務(wù)治理平臺(tái)能力支持，我們以上問題都得到了較好的解決。

五、寫在將來

雖然以上解決方案能覆蓋我們當(dāng)前業(yè)務(wù)場景中的大部分問題，隨著業(yè)務(wù)的高速發(fā)展，新的業(yè)務(wù)問題也接踵而至。

• 當(dāng)前就近路由策略代碼實(shí)現(xiàn)集成在Dubbo框架中，業(yè)務(wù)側(cè)需升級(jí)Dubbo框架版本才能完成升級(jí)，升級(jí)周期長，框架碎片化問題趨向嚴(yán)重；
  
  

• 當(dāng)前業(yè)務(wù)服務(wù)注冊時(shí)攜帶的機(jī)房信息比較有限，例如缺失服務(wù)實(shí)例所在的機(jī)架信息，和當(dāng)前服務(wù)同城的其他機(jī)房信息等，該類信息可支持我們實(shí)現(xiàn)更豐富的就近路由策略；
  
  

• 業(yè)務(wù)側(cè)的流量灰度策略較豐富，除了就近路由策略之外、往往還需要結(jié)合Dubbo框架自帶的條件路由、標(biāo)簽路由策略才能實(shí)現(xiàn)；
  
  

• 在特定場景下，就近路由策略失效由框架自動(dòng)完成，業(yè)務(wù)側(cè)缺少及時(shí)的感知能力。

針對(duì)以上問題，我們的解決思路如下：

• 適配云原生ServiceMesh技術(shù)方案，實(shí)現(xiàn)RPC框架復(fù)雜邏輯和業(yè)務(wù)代碼的分層解耦，業(yè)務(wù)側(cè)集成的SDK功能偏向簡單，版本迭代較少，版本碎片化問題能得到較好解決；框架的復(fù)雜邏輯下沉到Agent端，框架升級(jí)業(yè)務(wù)基本無感知。幸運(yùn)的是Dubbo 3.0 版本已規(guī)劃增加對(duì)云原生的支持，我們將持續(xù)關(guān)注；
  
  
  

• Dubbo框架的注冊中心和內(nèi)部CMDB系統(tǒng)結(jié)合，可以獲取到更多維度的信息，不限于該服務(wù)節(jié)點(diǎn)所在的機(jī)架、同城的其他機(jī)房信息等。目前vivo內(nèi)部已啟動(dòng)自研注冊中心，可在該場景的能力建設(shè)上走的更遠(yuǎn)；
  
  

• 服務(wù)治理平臺(tái)結(jié)合業(yè)務(wù)側(cè)常用的流量灰度策略，提供結(jié)合就近路由、條件路由、標(biāo)簽路由的組合式路由策略，提供更豐富的流量路由能力；
  
  

• 針對(duì)框架錯(cuò)誤、異常、自適應(yīng)變更等的告警需求，vivo內(nèi)部規(guī)劃建設(shè)統(tǒng)一的框架SDK側(cè)的監(jiān)控告警能力，對(duì)于常見的錯(cuò)誤、異常、自適應(yīng)變更等，從SDK側(cè)直接捕獲，并和告警中心進(jìn)行聯(lián)動(dòng)，縮短整個(gè)監(jiān)控告警的鏈路路徑，讓業(yè)務(wù)側(cè)能及時(shí)感知，甚至是提前感知。