[[413783]]

之前的文章中，我們詳細闡述了RPC的調用過程，分析了其耗時組成，為我們日常性能調優提供了理論支持。

為了更好的體驗和更優的性能，其實RPC悄悄的做了很多工作，本篇就帶大家來看下RPC的一些高級特性和其背后的原因。(還是以開源的dubbo和sofa為例來說明)

Part1 RPC為了性能做了哪些努力

1.1 Provider分組和直連

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

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

只有經歷過多方合作聯調時請求到處亂跑的痛，才知道分組和直連的功能對開發是多么的友好。

//以sofa為例 
@Extension(value = "directUrl", order = -20000) 
@AutoActive(consumerSide = true) 
public class DirectUrlRouter extends Router { 
  //... 
} 

我們可以看到直連路由策略的order屬性，被賦予了一個極小的值，變成了優先級最高的路由策略，所以只要配置的直連列表，則會優先走配置中的列表地址。

摘自:www.sofastack.tech

1.2 異步調用

Future異步調用

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

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

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

1.3 本地優先、遠程優先

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

List<ProviderInfo> localProviderInfo = new ArrayList<ProviderInfo>(); 
// 解析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); 
} 

當然，也需要看業務和內部服務路由的實際情況，比如在阿里的單元化部署下，需要根據用戶ID路由到對應的zone進行處理，如果還是優先本機，那就可能在操作數據庫的時候涉及到跨zone調用，比走遠程rpc更加耗時。因此這種情況下就需要禁用本機優先策略。

1.4 延遲暴露

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

//服務注冊之前，先延遲 
public void export() { 
    // 根據配置延遲加載 
    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 粘滯連接

問： 我們需要每次都進行路由尋址和負載均衡來確定服務地址么?

答： 大部分情況是有利的，不過有些特殊的場景，更希望多次請求連接到同一臺服務器。

比如，有狀態的服務(很多帶數據功能的服務都是有狀態的，比如很久之前的帶登陸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 && lastTransport.isAvailable()) { 
               checkAlias(providerInfo, message); 
               return providerInfo; 
            } 
        } 
    } 
    ... 
} 

1.6 預熱轉發

前面扯了那么多，其實，這個才是我們今天想說的重點。

預熱轉發是針對服務節點的負載均衡來說的。因為在服務剛啟動的時候，如果請求過多可能會影響機器性能和正常業務，如果將處于預熱期的機器的請求轉發到集群內其它機器，過了預熱期之后再恢復正常，則可以保證服務節點的性能和服務整體的可用性。

那么這個功能是怎么實現的呢?--帶權重的隨機負載均衡。

摘自sofastack：權重隨機的原理

 //累加總權重totalWeight，代碼忽略。。。 
  
 //在總權重內隨機得到一個值 
 int offset = random.nextInt(totalWeight); 
  
 //確定隨機值落在哪個片斷上 
 for (int i = 0; i < size; i++) { 
     offset -= getWeight(providerInfos.get(i)); 
     if (offset < 0) { 
        providerInfo = providerInfos.get(i); 
        break; 
     } 
} 

配置示例:

core_proxy_url=weightStarting:0.2,during:60,weightStarted:0.2,address:x.x.x.x,uniqueId:core_unique 

如上，預熱權重20%，預熱持續時長60s。這樣，按照上述計算方式，權重小的服務節點被選到的幾率就相對小，以此達到權重隨機的效果。

那么，為什么剛發布的服務需要預熱呢?預熱可以起到什么作用呢?

Part2 什么是JIT優化

都說C++快，Java慢，都是高級語言，是什么導致了運行速度的差別呢?

這個涉及到了兩種執行方式：解釋執行 和 編譯執行。

相對于C++直接將代碼編譯成機器碼運行的方式，Java為了實現跨平臺、高度抽象等特性，增加了虛擬機層來實現Java代碼到機器碼的轉換，Java程序先是被編譯成符合虛擬機規范的.class字節碼逐條將字節碼翻譯成機器碼然后執行，所以，速度上就慢一些。

雖然，JVM的加入，給Java的運行速度增加了不少損耗，但是好處也很多，除了跨平臺，還為我們實現了諸如內存管理、垃圾回收等容器級通用功能，讓研發人員可以更加聚焦業務。

不過，Java也是要面子的，我允許自己慢，但我不允許自己慢那么多!

怎么辦呢?遵循二八原則，是不是可以找尋程序當中的貢獻了大部分調用量的核心代碼，把這部分編譯成機器碼，提升其速度，不就把整體的速度提上去了么，JVM也是這么做的~

所以，JVM兼容了解釋執行和編譯執行兩種方式，也就是我們常說的即時編譯。

前面的問題到這里其實就可以回答了。為什么需要預熱轉發呢?是為了用小流量對程序進行預熱，目的是為了讓核心代碼進行及時編譯，提高峰值運行速率，提升服務響應~

下面讓我們詳細看下JIT。

2.1 即時編譯器

為了權衡編譯時間和執行效率，JVM設置了多種即時編譯器：

• C1(Client 編譯器)：基于字節碼完成部分優化，如方法內聯、常量傳遞，相對于C2，速度快，但性能稍差。
• C2(Server 編譯器)：耗時較長的全局優化，如無用代碼消除、重排序、循環展開、公共子表達式替代、常量傳播等等。
• Graal(新的JIT編譯器)：側重于性能和語言操作性。在一些負載上提供比傳統編譯器更好的峰值性能;用 Graal 執行的語言可以互相調用，可以使用來自其他語言的庫。

2.2 JIT優化觸發條件

前面我們說過，JVM其實是希望找到承擔更多調用請求的代碼塊進行優化，那，怎么來確認哪些代碼時優化目標呢?--熱點探測

基于采樣的熱點探測：

周期采樣，檢測各線程棧頂方法，經常出現的方法即為熱點方法。好處是簡單高效，缺點是不精確，容易受線程運行狀態的影響。

基于計數的熱點探測：

(包括方法調用計數器和回邊計數器)每個方法建立計數器，用來統計調用次數。如果該方法執行次數超過閾值，則該方法被認定為熱點方法。好處是足夠精確。缺點是空間損耗大，且實現較難。

另外，可以通過如XX:CompileThreshold等參數來修改閾值，不過，沒有絕對把握，還是不要動為好。

Part3 JIT指導代碼優化

3.1 方法內聯

為什么我們在剛寫代碼的時候，總是被建議不要寫很大的方法體?方法內聯的JIT優化策略就是其中一個重要的原因。(還有GC友好等原因)

JVM內的每一次方法調用，都是棧幀在內存中出棧入棧的過程，方法多了性能損耗自然大，所以要進行方法內聯，即把方法執行邏輯直接復制到調用方內部，避免方法調用。

但是，方法內聯是有方法大小限制的，超過了一定大小的方法，沒法做內聯優化。所以，平常應該注意，盡量避免寫很大很冗長的方法。

讓我們來舉個栗子實際感受一下~

兩種書寫風格的大數相加。

如上圖所示，兩個字符串型整數相加，都能實現功能，前一種寫法，把中間過程全都拆開，羅列在的方法內，整個方法雖然理解起來稍微方便些，但整體顯得冗長;第二種方法，把各個條件都囊括在了for循環條件內，三行代碼完成整體操作。

如果要去評價，我覺得大部分人都會說第二種寫的好，但是，第二種的好難道真的局限于優雅么?

//添加JVM啟動參數，用于打印代碼執行過程中的編譯詳情 
//-XX:+PrintCompilation 
String num1 = "12345"; 
String num2 = "23456"; 
//循環15000次，因為1.8分層編譯下,各層閾值不一樣，我們取最大閾值 
for (int i=0;i<15001;i++) { 
    rejectionLB1.stringAdd(num1, num2); 
    //rejectionLB1.stringAdd2(num1, num2); 
 } 

執行15000次寫法1

(圖中編譯層次這一列中，3代表C1編譯，4代表C2編譯)

我們看到，隨著代碼的執行次數的增加，一些方法，進行了C1編譯，如我們的主方法stringAdd，而少數方法，從C1編譯提升到了C2編譯，如AbstractStringBuilder::append方法。

執行15000次寫法2

我們看到了什么，stringAdd2 居然在進行到運行后期執行了C2編譯，而且很明顯，方法二的C2編譯的方法，比方法一要多不少。所以，平常寫代碼該注意些什么，是不是顯而易見了。。。

3.2 其他優化

方法內聯雖然只是一種簡單優化，但是，是后續其他優化的基石。

而JVM的分層優化涉及的點非常多[1]：

局部優化：關注局部數據流分析，數組越界檢查消除;寄存器優化，優化跳轉、循環、異常處理等;代碼簡化，如公共表達式提取等等等。

控制流優化：專注于代碼重排序、循環縮減、循環展開、異常定位優化等等等。

全局優化：主要關注冗余消除，如方法調用、鎖;逃逸分析;GC和內存分配優化等等等。

Part4 總結

本篇從RPC的預熱轉發功能，引出了其背后的理論依據--JIT優化。闡述了JIT的基本概念，并用一個實例說明了代碼編寫風格對JIT優化的實際影響。

JIT相關的優化實現起來非常難，不過其原理和作用對我們普通研發也不是特別難理解，學習JIT優化的目的，在于了解JVM底層的運行邏輯和實現，讓我們可以更加信任托管，聚焦業務邏輯，同時在編寫代碼時，盡量用JVM友好的方式進行，從而達到更好看、更高效的目的。

本文轉載自微信公眾號「Coder的技術之路」，可以通過以下二維碼關注。轉載本文請聯系Coder的技術之路公眾號。