一、問題背景

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

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

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

二、解決方案

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

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

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

三、技術原理說明

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

四、實現(xiàn)方案

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

我們知道，Dubbo框架中服務消費者選擇具體的服務提供者實例調(diào)用的匹配、篩選邏輯是在 Consumer 側(cè)完成的，在 Cluster 層中，消費者會先應用用戶配置的 Router 規(guī)則，然后再符合規(guī)則的服務提供者列表中，使用 LoadBalance 策略選擇具體的服務提供者節(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è)務推廣過程中，我們實現(xiàn)的初版就近路由碰到了新的問題：

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

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

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

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

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

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

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

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

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

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

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

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

五、寫在將來

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

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

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

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

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

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

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

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

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

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