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

一、問題背景

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

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

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

二、解決方案

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

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

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

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

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

四、實現(xiàn)方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

擴展Dubbo框架 Router 接口實現(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ù)降級，available.ratio = 當前機房可用服務(wù)節(jié)點數(shù)量 ／ 集群可用服務(wù)節(jié)點數(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ù)治理平臺上，我們提供了可視化的配置能力，頁面內(nèi)容如下：

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

五、寫在將來

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

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

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

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

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

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

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

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

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

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