本文來源：公眾號「 Coder的技術之路」

本篇帶大家來看下RPC的一些高級特性和其背后的原因。（還是以開源的dubbo和sofa為例來說明）。

Part1RPC為了性能做了哪些努力

1.1Provider分組和直連

路由尋址，負載均衡是很好，可以保證流量均勻從而保護服務節(jié)點穩(wěn)定。

但是，我們有的時候其實不希望我們的請求亂跑，最好能打到指定的機器上。比如聯(lián)調和測試的時候，直連功能就顯得很重要了。

只有經(jīng)歷過多方合作聯(lián)調時請求到處亂跑的痛，才知道分組和直連的功能對開發(fā)是多么的友好。

//以sofa為例
@Extension(value?=?"directUrl",?order?=?-20000)
@AutoActive(consumerSide?=?true)
public?class?DirectUrlRouter?extends?Router?{
??//...
}
我們可以看到直連路由策略的order屬性，被賦予了一個極小的值，變成了優(yōu)先級最高的路由策略，所以只要配置的直連列表，則會優(yōu)先走配置中的列表地址。

1.2異步調用

異步調用對服務性能和并發(fā)的支持起到很大的作用。

一般異步調用有Futurn和callback等方式，這里我們說下Future的原理：

調用下游之后，先返回一個Future，上游通過Future.get()方法對結果進行獲取，如果結果未返回則會讓出CPU資源進入等待，直到結果到達或超時后觸發(fā)回調方法才被喚醒。由于篇幅問題，F(xiàn)uture的核心邏輯的相關注釋就不放了，之前的消息消費順序保障的文章中也有敘述，有興趣的同學可以看下~

1.3本地優(yōu)先、遠程優(yōu)先

很多時候，我們會遇到消費端和服務端可能都是自己的情況。這個時候，在常規(guī)的路由尋址之外，又提供給我們一種調用的可能性，就是直接調用當前服務器上的程序，這樣做的好處比較明顯，省去了網(wǎng)絡傳輸?shù)葧r間損耗，效率更高。

List?localProviderInfo?=?new?ArrayList();
//?解析IP，看是否和本地一致
for?(ProviderInfo?providerInfo?:?providerInfos)?{?
????if?(localhost.equals(providerInfo.getHost()))?{
????????localProviderInfo.add(providerInfo);
????}
}
//?命中本機的服務端
if?(CommonUtils.isNotEmpty(localProviderInfo))?{?
????return?super.doSelect(invocation,?localProviderInfo);
}?else?{?
??//?沒有命中本機上的服務端
???return?super.doSelect(invocation,?providerInfos);
}
當然，也需要看業(yè)務和內(nèi)部服務路由的實際情況，比如在阿里的單元化部署下，需要根據(jù)用戶ID路由到對應的zone進行處理，如果還是優(yōu)先本機，那就可能在操作數(shù)據(jù)庫的時候涉及到跨zone調用，比走遠程rpc更加耗時。因此這種情況下就需要禁用本機優(yōu)先策略。

1.4延遲暴露

很多時候，我們的服務需要依賴一些其他內(nèi)容才可以正常提供服務，比如緩存預熱、線程池預熱等等，所以，在服務真正就緒之后再注冊到配置中心是很有必要的。

//服務注冊之前，先延遲
public?void?export()?{
????//?根據(jù)配置延遲加載
????if?(providerConfig.getDelay()?>?0)?{?
????????Thread?thread?=?factory.newThread(new?Runnable()?{
?????????@Override
?????????public?void?run()?{
?????????????try?{
??????????????????Thread.sleep(providerConfig.getDelay());
?????????????}?catch?(Throwable?ignore)?{?
?????????????}
??????????????//真正的服務注冊邏輯
??????????????doExport();
?????????}
??????});
??????thread.start();
???}?else?{
???????doExport();
???}
}


1.5粘滯連接

問：?我們需要每次都進行路由尋址和負載均衡來確定服務地址么？
答：?大部分情況是有利的，不過有些特殊的場景，更希望多次請求連接到同一臺服務器。

比如，有狀態(tài)的服務（很多帶數(shù)據(jù)功能的服務都是有狀態(tài)的，比如很久之前的帶登陸session的Tomcat服務、存儲集群服務等），其實希望每次請求都連接到相同的服務器。

這就用到了粘滯連接功能。

protected?ProviderInfo?select(...)throws?SofaRpcException?{
????//?判斷isSticky?粘滯連接配置
????if?(consumerConfig.isSticky())?{
????????//如果最后一次使用的provider不為空，則使用
????????if?(lastProviderInfo?!=?null)?{
????????????ProviderInfo?providerInfo?=?lastProviderInfo;????????
????????????//獲取對應連接
????????????ClientTransport?lastTransport?=?connectionHolder.getAvailableClientTransport(providerInfo);
????????????if?(lastTransport?!=?null?