一、問題背景
在vivo網際網路業務高速發展的同時，支撐的服務例項規模也越來越大，然而單個機房能承載的機器容量是有限的，於是同城多機房甚至多地域部署就成為了業務在實際部署過程中不得不面臨的場景。
一般情況下，同一個機房內部的網路呼叫平均時延在0.1ms左右，同城多個機房之間的平均時延在1ms左右，跨地域機房之間的網路時延則更大，例如北京到上海的平均時延達到了30ms以上。
在業務多機房部署場景中，內部服務如果存在大量的跨機房、甚至跨地域的網路呼叫，則請求時延會顯著加大，會直接影響到服務質量，甚至是使用者體驗。
二、解決方案
要解決以上問題，只需要實現服務消費者和服務提供者之間的網路調用盡量是同機房內部、或者是同地域即可，即服務消費者在呼叫服務提供者時，優先呼叫部署在本機房的服務提供者，當本機房沒有部署該服務提供者時，再跨機房呼叫同地域的同城機房、甚至是跨地域機房的服務。
以上策略我們內部稱為 就近路由。業務的就近路由示意圖如下：
為了簡單易用，vivo內部的服務間呼叫均使用了RPC框架來實現，在Java技術棧方向，我們選擇了阿里巴巴開源的RPC框架 Dubbo，針對該場景的問題，我們擴充套件了Dubbo框架的原始碼實現，提供了 Dubbo就近路由能力。
三、技術原理說明
在服務提供者註冊服務時，把該例項節點的機房資訊【我們內部將機房標籤定義為 app_loc 欄位】註冊到註冊中心，在開啟了就近路由策略後，消費者在過濾服務列表時，會自動篩選、匹配和消費者自己 app_loc 欄位相同的服務提供者列表，從而實現就近路由訪問。我們實現的就近路由策略，在本機房存在對應服務提供者的情況下，消費者會優先呼叫本機房的服務。
四、實現方案
開源版本的Dubbo框架並不提供就近路由能力，我們需要基於Dubbo框架原始碼擴充套件實現。Dubbo框架整體設計如下：【左側為服務消費者使用的介面，右側為服務提供方使用的介面】。
我們知道，Dubbo框架中服務消費者選擇具體的服務提供者例項呼叫的匹配、篩選邏輯是在 Consumer 側完成的，在 Cluster 層中，消費者會先應用使用者配置的 Router 規則，然後再符合規則的服務提供者列表中，使用 LoadBalance 策略選擇具體的服務提供者節點進行呼叫。
結合Dubbo框架原始碼實現，我們選擇基於Dubbo 2.7.x版本的router層擴充套件口 org.apache.dubbo.rpc.cluster.Router 實現一種新的路由方式，即就近路由(我們內部標識為 NearestRouter)。
有了具體的解決方案，我們很快就完成了程式碼開發，內部也釋出了一個整合就近路由策略的Dubbo版本，但在實際的線上灰度和業務推廣過程中，我們實現的初版就近路由碰到了新的問題：
- 基於機房容量、機器成本等因素考慮，並不是所有的業務都實現了多機房部署，即有部分業務只實現了單機房部署，這部分業務的消費方無法實現同機房內部呼叫；
- 即使部分業務實現了多機房部署，但多個機房之間能提供的服務容量並不是相同的，對於服務容量較小的機房，如果一部分服務節點不可用，剩下的服務節點能提供的服務容量無法支撐本機房的消費方呼叫時，會造成該機房內的服務節點雪崩；
- 業務側在開啟就近路由策略時，希望消費服務的業務方能逐個開啟，有一段時間的灰度觀察過程，保證更平滑的升級驗證；而不是比較粗暴的要麼開啟，要麼關閉；
- 部分消費者的Dubbo版本較低，不支援就近路由功能，或者不支援配置應用維度的就近路由，在業務灰度過程中，希望能實現向前相容，業務側不報錯。
基於以上問題，我們細化了實現方案：
- 就近路由策略預設不強制執行，即當本機房不存在服務提供者時，不再區分本機房、跨機房，就近路由策略自動失效，優先保障服務之間的正常呼叫；
- 支援設定就近路由策略的降級閾值，在呼叫本機房服務的過程中，當 本機房服務例項數量 / 叢集服務例項數量 得到的數值小於設定的降級閾值時，我們認為當前機房的服務容量無法支撐本機房的消費方呼叫，就近路由策略自動失效；
- 支援配置應用維度的就近路由策略，即配置的就近路由策略可只針對配置的應用生效，實現應用維度的灰度效果；
- 實現Dubbo版本自動校驗能力，不滿足開啟就近路由策略條件的業務，提示使用者不開啟。
有了以上細化方案，我們梳理的就近路由大致邏輯流程如下：
擴充套件Dubbo框架 Router 介面實現的 NearestRouter 核心程式碼如下：
public <T> List<Invoker<T>> route(List<Invoker<T>> 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<Invoker<T>> result = new ArrayList<Invoker<T>>();
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 = 當前機房可用服務節點數量 ／ 叢集可用服務節點數量
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內部的服務治理平臺上，我們提供了視覺化的配置能力，頁面內容如下：
透過擴充套件Dubbo框架，服務治理平臺能力支援，我們以上問題都得到了較好的解決。
五、寫在將來
雖然以上解決方案能覆蓋我們當前業務場景中的大部分問題，隨著業務的高速發展，新的業務問題也接踵而至。
- 當前就近路由策略程式碼實現整合在Dubbo框架中，業務側需升級Dubbo框架版本才能完成升級，升級週期長，框架碎片化問題趨向嚴重；
- 當前業務服務註冊時攜帶的機房資訊比較有限，例如缺失服務例項所在的機架資訊，和當前服務同城的其他機房資訊等，該類資訊可支援我們實現更豐富的就近路由策略；
- 業務側的流量灰度策略較豐富，除了就近路由策略之外、往往還需要結合Dubbo框架自帶的條件路由、標籤路由策略才能實現；
- 在特定場景下，就近路由策略失效由框架自動完成，業務側缺少及時的感知能力。
針對以上問題，我們的解決思路如下：
- 適配雲原生ServiceMesh技術方案，實現RPC框架複雜邏輯和業務程式碼的分層解耦，業務側整合的SDK功能偏向簡單，版本迭代較少，版本碎片化問題能得到較好解決；框架的複雜邏輯下沉到Agent端，框架升級業務基本無感知。幸運的是Dubbo 3.0 版本已規劃增加對雲原生的支援，我們將持續關注；
- Dubbo框架的註冊中心和內部CMDB系統結合，可以獲取到更多維度的資訊，不限於該服務節點所在的機架、同城的其他機房資訊等。目前vivo內部已啟動自研註冊中心，可在該場景的能力建設上走的更遠；
- 服務治理平臺結合業務側常用的流量灰度策略，提供結合就近路由、條件路由、標籤路由的組合式路由策略，提供更豐富的流量路由能力；
- 針對框架錯誤、異常、自適應變更等的告警需求，vivo內部規劃建設統一的框架SDK側的監控告警能力，對於常見的錯誤、異常、自適應變更等，從SDK側直接捕獲，並和告警中心進行聯動，縮短整個監控告警的鏈路路徑，讓業務側能及時感知，甚至是提前感知。
