公司內部的RPC框架，經過長時間的發展，已經由完全自研演進到底層替換為Dubbo實現，但使用方式（API）還是不變。由于使用了PB序列化協議，以及業務碼+操作碼定義接口的方式，非常影響開發效率，可理解性差，鏈路排查困難等問題，不斷被業務方吐槽。因此就有了第三個版本，繼續基于Dubbo擴展點，設計開發提供接近Dubbo原生的使用方式。

由于Dubbo原生提供的Http rpc協議的實現，不僅使用了Spring框架的API，還使用了Java的原生序列化，所以我們基于擴展點自實現了Http rpc協議，移除對Spring的強依賴，并使用json序列化協議。此次性能測試對比的是我們基于Dubbo擴展點自實現的Http rpc協議，與Dubbo原生Dubbo rpc協議的單次請求響應平均耗時、吞吐量。

• Dubbo rpc：Dubbo rpc協議 + hessian2序列化協議

• Http rpc：Http rpc協議（服務端使用jetty，客戶端使用netty） + json序列化協議（使用fastjson）

基準測試目的

• 在最初設計評審時，關于是采用http協議還是dubbo協議，我們對這兩者在性能方面的影響還存在疑慮。

• 有Dubbo rpc的性能數據做對比，對自實現的Http rpc，性能應該優化到多少才算最優，心里有個底。

基準測試接口

接口實現不做任何業務處理，排除業務耗時對基準測試的影響。

RPC接口定義：

public interface DemoeService {Result<String> sayHello(String name); }

提供者實現：

@ServiceProvider public class DemoeServiceImpl implements DemoeService {@Overridepublic Result<String> sayHello(String name) {Result<String> result = new Result<>(0, name);return result;} }

基準測試說明

一、以相同配置，不同rpc協議實現注冊DemoService服務提供者。

服務提供者參數配置如下：

• 工作線程數：200 （處理業務）

• IO線程數：4 （處理數據包的讀寫、編解碼）

二、以相同配置，不同rpc協議創建DemoService服務消費者。

唯一的區別是，使用http rpc協議需要配置連接池，使用dubbo rpc協議只配置單一長連接。

使用http rpc協議，服務消費者連接池配置：

• 最大連接數：無最大連接數限制；

• 最大空閑連接數：1024；

三、使用open-jdk官方開源的JMH基準測試工具對DemoService接口分別進行平均耗時測量、吞吐量測量。

環境

• 本地測試，MacBook Pro 8核16G

• 盡量關閉多余進程

• 先啟動dubbo協議服務提供者和消費者，測完dubbo協議后，再測http協議

• dubbo版本：2.6.4 （二次開發過，增加了一些功能特性）

基準測試結果

Http rpc與Dubbo rpc基準測試：

• 測量指標：平均耗時、吞吐量

• 預熱1次，每次5秒鐘

• 測量5次，每次5秒鐘

• 消費者線程數200（模擬并發）

• 數據包足夠小（調用的接口信息+參數，數據包小于1KB）

初次測試

Http rpc測量結果：

Benchmark Mode Cnt Score Error Units HttpConsumerBenchmarkTest.testHttp thrpt 5 1.408 ± 0.235 ops/ms HttpConsumerBenchmarkTest.testHttp avgt 5 233.966 ± 163.614 ms/op

Dubbo rpc測量結果：

Benchmark Mode Cnt Score Error Units DubboConsumerBenchmarkTest.testDubbo thrpt 5 42.829 ± 24.597 ops/ms DubboConsumerBenchmarkTest.testDubbo avgt 5 4.739 ± 0.192 ms/op

測量結果對比

	吞吐量	平均耗時
http rpc	1408ops	233.966ms
dubbo rpc	42829ops	4.739ms

此次測試結果數據差別有些大，初步定位耗時在服務端。

經關鍵步驟打印日記后發現，數據序列化和反序列化耗時比較嚴重。

經驗證后，發現fastjson序列化和反序列化泛型非常耗時，并且改用gson后耗時降低，性能數據表現接近Dubbo rpc。

優化后重新測試

HTTP rpc（使用json + gson）

Benchmark Mode Cnt Score Error Units HttpConsumerBenchmarkTest.testHttp thrpt 5 31.550 ± 6.477 ops/ms HttpConsumerBenchmarkTest.testHttp avgt 5 6.487 ± 1.512 ms/op

Dubbo rpc（使用hessian2）

Benchmark Mode Cnt Score Error Units DubboConsumerBenchmarkTest.testDubbo thrpt 5 42.829 ± 24.597 ops/ms DubboConsumerBenchmarkTest.testDubbo avgt 5 4.739 ± 0.192 ms/op

考慮到序列化協議也是影響性能的重要因素，因此我們增加了Dubbo rpc使用json序列化協議的基準測試。

Dubbo（序列化使用fastjson）

Benchmark Mode Cnt Score Error Units DubboConsumerBenchmarkTest.testDubbo thrpt 5 21.416 ± 7.571 ops/ms DubboConsumerBenchmarkTest.testDubbo avgt 5 9.687 ± 2.329 ms/op

Dubbo（序列化使用gson）

Benchmark Mode Cnt Score Error Units DubboConsumerBenchmarkTest.testDubbo thrpt 5 24.460 ± 7.396 ops/ms DubboConsumerBenchmarkTest.testDubbo avgt 5 7.743 ± 1.256 ms/op

可以看到，同樣使用json序列化協議，且使用gson工具，Http rpc與Dubbo rpc性能相差在0.5～1ms之間，并且Http rpc的耗時略低，吞吐量更高；Dubbo rpc同樣使用json序列化協議，使用gson工具與fastjson工具性能相差2ms左右，fastjson性能表現較差。

此測試數據僅供參考！

官方性能壓測報告：性能測試報告

總結

以上是生活随笔為你收集整理的Dubbo之HTTP RPC vs Dubbo RPC性能压测的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。