在 RPC Benchmark Round 1 中余爆，Turbo 性能炸裂表現(xiàn)強悍戴差，并且在 listUser 這一項目中庐杨，取得了 10x dubbo 性能的好成績衅檀。本文將介紹 Turbo 強悍性能背后的原理招刨，并探討如何編寫高性能的 RPC 框架。

過早的優(yōu)化是萬惡之源它浅？

這句話是 The Art of Computer Programming 作者脆栋，圖領獎得主 Donald Knuth 大神說的双肤。不過對于框架設計者而言，這句話并不正確谎倔。在設計一款高性能的基礎框架時，必須始終重視性能優(yōu)化淘衙，并將性能測試貫穿于整個設計開發(fā)過程中传藏。這方面做到極致的類庫有 Disruptor JCTools Agrona DSL-JSON 等等，這幾個高性能類庫都堅持一個原則：不了解性能的外部類庫堅決不用彤守，如果現(xiàn)有的類庫不能滿足性能要求毯侦，那就重新設計一個。作為 Turbo 的設計者具垫，我也盡量堅持這一原則侈离，努力做到 Benchmark 驅動開發(fā)。

JMH 讓 Benchmark 驅動開發(fā)成為可能

在 JMH 出現(xiàn)之前筝蚕，要對某個類庫進行微基準性能測試是一件非常困難的事情卦碾。很難保證公平的測試條件铺坞，預熱次數(shù)難以確定，預熱效果也不好觀察洲胖。JMH 的出現(xiàn)讓性能測試變得 標準化 簡單化济榨，也讓 Benchmark 驅動開發(fā)成為可能。Turbo 在開發(fā)過程中用 JMH 進行了充分的 Benchmark绿映，以確定核心環(huán)節(jié)的性能開銷擒滑，選擇合適的實現(xiàn)方案。更多關于 JMH 的介紹請參考下面的鏈接：

• OpenJDK: jmh
• JMH - Java Microbenchmark Harness
• ImportNew JMH簡介

RPC 的主要流程

1. 客戶端 獲取到 UserService 接口的 Refer: userServiceRefer
2. 客戶端 調用 userServiceRefer.verifyUser(email, pwd)
3. 客戶端 獲取到 請求方法 和 請求數(shù)據(jù)
4. 客戶端 把 請求方法 和 請求數(shù)據(jù) 序列化為 傳輸數(shù)據(jù)
5. 進行網絡傳輸
6. 服務端 獲取到 傳輸數(shù)據(jù)
7. 服務端 反序列化獲取到 請求方法 和 請求數(shù)據(jù)
8. 服務端 獲取到 UserService 的 Invoker: userServiceInvoker
9. 服務端 userServiceInvoker 調用 userServiceImpl.verifyUser(email, pwd) 獲取到 響應結果
10. 服務端 把 響應結果 序列化為 傳輸數(shù)據(jù)
11. 進行網絡傳輸
12. 客戶端 接收到 傳輸數(shù)據(jù)
13. 客戶端 反序列化獲取到 響應結果
14. 客戶端 userServiceRefer.verifyUser(email, pwd) 返回 響應結果

整個流程中對性能影響比較大的環(huán)節(jié)有：序列化[4, 7, 10, 13]叉弦，方法調用[2, 3, 8, 9, 14]丐一，網絡傳輸[5, 6, 11, 12]。本文后續(xù)內容將著重介紹這3個部分淹冰。

序列化方案

Java 世界最常用的幾款高性能序列化方案有 Kryo Protostuff FST Jackson Fastjson库车。只需要進行一次 Benchmark，然后從這5種序列化方案中選出性能最高的那個就行了樱拴。DSL-JSON 使用起來過于繁瑣柠衍，不在考慮之列。Colfer Protocol Thrift 因為必須預先定義描述文件晶乔，使用起來太麻煩拧略，所以不在考慮之列。至于 Java 自帶的序列化方案瘪弓，早就因為性能問題被大家所拋棄垫蛆，所以也不考慮。下面的表格列出了在考慮之列的5種序列化方案的性能腺怯。

1. User 序列化+反序列化 性能

2. 包含15個 User 的 Page 序列化+反序列化 性能

從這個 benchmark 中可以得出明確的結論：二進制協(xié)議的 protostuff kryo fst 要比文本協(xié)議的 jackson fastjson 有明顯優(yōu)勢袱饭；文本協(xié)議中，jackson(開啟了afterburner) 要比 fastjson 有明顯的優(yōu)勢呛占。

無法確定的是：3個二進制協(xié)議到底哪個更好一些虑乖，畢竟 速度 和 size 對于 RPC 都很重要。直觀上 kryo 或許是最佳選擇晾虑，而且 kryo 也廣受各大型系統(tǒng)的青睞疹味。不過最終還是決定把這3個類庫都留作備選，通過集成傳輸模塊后的 Benchmark 來決定選用哪個帜篇。

最終的結果也還是各有千秋難以抉擇糙捺，所以 Turbo 保留了 protostuff 和 kryo 的實現(xiàn)，并允許用戶自行替換為自己的實現(xiàn)笙隙。

方法調用

可用的 動態(tài)方法調用 方案有：Reflection ClassGeneration MethodHandle洪灯。Reflection 是最古老的技術，據(jù)說性能不佳竟痰。ClassGeneration 動態(tài)類生成签钩，從原理上說應該是跟直接調用一樣的性能掏呼。MethodHandle 是從 Java 7 開始出現(xiàn)的技術，據(jù)說能達到跟直接調用一樣的性能铅檩。實際結果如下：

結論非常明顯：使用類生成技術的 javassist 跟直接調用幾乎一樣的性能憎夷，就用 javassist 了。

MethodHandle 表現(xiàn)并沒有宣傳的那么好昧旨，怎么回事岭接？原來 MethodHandle 只有在明確知道調用 參數(shù)數(shù)量 參數(shù)類型 的情況下才能調用高性能的 invokeExact(Object... args)，所以它并不適合作為動態(tài)調用的方案臼予。

As is usual with virtual methods, source-level calls to invokeExact and invoke compile to an invokevirtual instruction. More unusually, the compiler must record the actual argument types, and may not perform method invocation conversions on the arguments. Instead, it must push them on the stack according to their own unconverted types. The method handle object itself is pushed on the stack before the arguments. The compiler then calls the method handle with a symbolic type descriptor which describes the argument and return types.
refer: https://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandle.html

網絡傳輸

Netty 已經成為事實上的標準，所有主流的項目現(xiàn)在使用的都是 Netty啃沪。Mina Grizzly 已經失去市場粘拾，所以也就不用考慮了。還好也不至于這么無聊创千，Aeron 的閃亮登場讓 Netty 多了一個有力的競爭對手缰雇。Aeron 是一個可靠高效的 UDP 單播 UDP 多播和 IPC 消息傳遞工具。性能是消息傳遞中的關鍵追驴。Aeron 的設計旨在達到 高吞吐量 低開銷 和 低延遲械哟。實際效果到底如何呢？很遺憾殿雪，在 RPC Benchmark Round 1 中的表現(xiàn)一般暇咆。跟他們開發(fā)團隊溝通后，最終確認其無法對超過 64k 的消息進行 zero-copy 處理丙曙，我覺得這可能是 Aeron 表現(xiàn)不佳的一個原因爸业。Aeron 或許更適合 微小消息 極端低延遲 的場景，而不適用于更加通用的 RPC 場景亏镰。所以暫時還沒有出現(xiàn)能夠跟 Netty 一爭高下的通用網絡傳輸框架扯旷，現(xiàn)階段 Netty 依然是 RPC 系統(tǒng)的最佳選擇。

• existUser 判斷某個 email 是否存在

消息格式

我們先來看一下 Dubbo 的消息格式

public class RpcInvocation implements Invocation, Serializable {
    private String methodName;
    private Class<?>[] parameterTypes;
    private Object[] arguments;
    ...
}

可以說是非常經典的設計索抓，Client 必須告知 Server 要調用的 方法名稱 參數(shù)類型 參數(shù)钧忽。Server 獲取到這3個參數(shù)后，通過 方法名稱 com.alibaba.service.auth.UserService.verifyUser 和
參數(shù)類型 (String, String) 獲取到 Invoker逼肯，然后通過 Invoker 實際調用 userServiceImpl 的 verifyUser(String, String) 方法耸黑。其他的眾多 RPC 框架也都采取了這一經典設計。

但是篮幢，這是正確的做法嗎崎坊？當然不是，這種做法非常浪費空間洲拇，每次請求消息體的大概內存布局應該是下面的樣子：

public boolean verifyUser(String email, String pwd);

|com.alibaba.service.auth.UserService.verifyUser|java.lang.String,java.lang.String|實際的參數(shù)|

啰里啰嗦的奈揍，浪費了 80 byte 來定義 方法 和 參數(shù)曲尸，并沒有比 http+json 的方式高效多少。實際的 性能測試 也證明了這一點男翰，undertow+jackson 要比 dubbo motan 的成績都要好另患。

那什么才是正確的做法？Turbo 在消息格式上做出了非常大的改變蛾绎。

public class Request implements Serializable {
    private int requestId;
    private int serviceId;
    private MethodParam methodParam;
    ...
}

大致的內存布局：

public boolean verifyUser(String email, String pwd);
|int|int|實際的參數(shù)|

高效多了昆箕，只用了 4 byte 就做到了 方法 和 參數(shù) 的定義。大大減小了 傳輸數(shù)據(jù) 的 size租冠，同時 int 類型的 serviceId 也降低了 Invoker 的查找開銷鹏倘。

看到這里，有同學可能會問：那豈不是要為每個方法定義一個唯一 id 顽爹？
答案是不需要的纤泵，Turbo 解決了這一問題，詳情參考 TurboConnectService 镜粤。

MethodParam 簡介

MethodParam 才是 Turbo 性能炸裂的真正原因捏题。其基本原理是利用 ClassGeneration 對每個 Method 都生成一個 MethodParam 類，用于對方法參數(shù)的封裝肉渴。這樣做的好處有：

1. 減少基本數(shù)據(jù)類型的 裝箱 拆箱 開銷
2. 序列化時可以省略掉很多類型描述公荧，大大減小 傳輸消息 的 size
3. 使 Invoker 可以高效調用 被代理類 的方法
4. 統(tǒng)一 RPC 和 REST 的數(shù)據(jù)模型，簡化 序列化 反序列化 實現(xiàn)
5. 大大加快 json 格式數(shù)據(jù) 反序列化 速度

//方法 test(long id, int value) 將會生成下面的 MethodParam 類:     
public class TestService_test_2_MethodParam implements MethodParam {
    private long id;
    private int value;
     
    public long $param0() { return this.id; }
    public int $param1() { return this.value; }

    //... getters and setters
     
    public TestService_test_2_MethodParam(long id, int value) {
        this.id = id;
        this.value= value;
    }
}

序列化的進一步優(yōu)化

大部分 RPC 框架的 序列化 反序列化 過程都需要一個中間的 bytes

序列化過程：User > bytes > ByteBuf
反序列化過程：ByteBuf > bytes > User

而 Turbo 砍掉了中間的 bytes同规，直接操作 ByteBuf循狰，實現(xiàn)了 序列化 反序列化 的 zero-copy，大大減少了 內存分配 內存復制 的開銷券勺。具體實現(xiàn)請參考 ProtostuffSerializer 和 Codec晤揣。

對于已知類型和已知字段，Turbo 都盡量采用 手工序列化 手工反序列化 的方式來處理朱灿，以進一步減少性能開銷昧识。

ObjectPool

常見的幾個 ObjectPool 實現(xiàn)性能都很差，反而很容易成為性能瓶頸盗扒。Stormpot 性能強悍跪楞，不過存在偶爾死鎖的問題，而且作者也停止維護了侣灶。HikariCP 性能不錯甸祭，不過其本身是一款數(shù)據(jù)庫連接池，用作 ObjectPool 并不稱手褥影。我的建議是盡量避免使用 ObjectPool池户，轉而使用替代技術。更重要的是 Netty 的 Channel 是線程安全的，并不需要使用 ObjectPool 來管理校焦。只需要一個簡單的容器來存儲 Channel赊抖，用的時候使用 負載均衡策略 選出一個 Channel 出來就行了。

基礎類庫優(yōu)化

除了上述的關鍵流程優(yōu)化寨典，Turbo 還做了大量基礎類庫的優(yōu)化

• AtomicMuiltInteger 多個 int 的原子性操作
• ConcurrentArrayList 無鎖并發(fā) List 實現(xiàn)氛雪，比 CopyOnWriteArrayList 的寫入開銷低，O(1) vs O(n)
• ConcurrentIntToObjectArrayMap 以 int 數(shù)組為底層實現(xiàn)的無鎖并發(fā) Map耸成，讀多寫少情況下接近直接訪問字段的性能报亩，讀多寫多情況下是 ConcurrentHashMap 性能的 5x
• ConcurrentIntegerSequencer 快速序號生成器，并發(fā)環(huán)境下是 AtomicInteger 性能的10x
• ObjectId 全局唯一 id 生成器井氢，是 Java 自帶 UUID 性能的 200x
• HexUtils 查表 + 批量操作弦追，是 Netty 和 Guava 實現(xiàn)的 2x~5x
• URLEncodeUtils 基于 HexUtils 實現(xiàn)，是 Java 和 Commons 實現(xiàn)的 2x花竞，Guava 實現(xiàn)的 1.1x (Guava 只有 urlEncode 實現(xiàn)劲件，無 urlDecode 實現(xiàn))
• ByteBufUtils 實現(xiàn)了高效的 ZigZag 寫入操作，最高可達通常實現(xiàn)的 4x

上面的內容僅介紹了作者認為重要的東西左胞，更多內容請直接查看 Turbo 源碼

不足之處

• 有很多優(yōu)化是毫無價值的，Donald Knuth 大神說得很對
• 強制必須使用 CompletableFuture 作為返回值導致了一些性能開銷
• 濫用 ClassGeneration举户，而且并沒有考慮類的卸載烤宙，這方面需要改進
• 實現(xiàn)了 UnsafeStringUtils，這是個危險的黑魔法實現(xiàn)俭嘁，需要重新思考下
• 對性能的追求有點走火入魔躺枕，導致了很多地方的設計過于復雜