dubbo vs mac-rpc 性能評測之同步調用

  Dubbo 是阿里巴巴開源的一款Java高性能分佈式微服務框架。它以遠程方法調用功能爲基礎，將系統中的服務以遠程方法調用（RPC）的形式暴露並管理，提供配套的面向服務（SOA）的治理手段，從而造成完整的分佈式微服務框架體系。

  Dubbo項目大概始於2009年，但不知出於什麼緣由，官方於2012年中止了維護。很有戲劇性的是，牆內開花牆外香，Dubbo受到國內不少第三方廠商的歡迎，並在其項目中普遍使用。所以，官方於2017年重啓Dubbo項目的維護，目前最新版本是2.6.1。

  mac-rpc是一款新的基於Java AIO的開源RPC框架，小巧精悍。強大的異步能力是它最大的亮點。Dubbo在異步支持上比較弱，而mac-rpc天生就是異步的，使得mac-rpc在異步方法調用的性能方面頗具優點。（瞭解其實現原理請訪問官方網站 www.boarsoft.com）。

  做爲RPC框架，大多數的應用場景都是同步方法調用。而mac-rpc在同步方法調用方面的性能也很是不俗，能夠與dubbo一較高下。所以，筆者僅對二者的同步方法調用的性能進行對比測試。

    異步調用的評測見：《dubbo vs mac-rpc 性能評測之異步調用》

1、測試環境

  硬件：筆記本電腦一臺 CPU Intel i5－6300HQ @2.30GHz，8G內存

  軟件：JDK1.七、dubbo 2.6.一、mac-rpc 1.0.1

  注：筆記本電腦在CPU溫度太高時會自動降頻，致使測試結果的波動。筆者不得不採用輪流執行，屢次測試取平均值的方式進行。所得數據可能並不很準確，但能從大致上看出二者的性能水平。

2、測試場景

  Dubbo可調參數衆多，其調優過程自己就已很是複雜，費時費力。所以，本次測試將盡量採用其默認參數。通過多輪測試，Dubbo在採用固定大小線程池時性能表現最佳，同時爲了不dubbo拋出線程池耗盡的異常，咱們將服務方的線程池大小固定爲600，在消費方使用300個線程並行發起調用。

  另外，dubbo在傳輸大對象時表現不佳，過大的數據量將致使dubbo的性能嚴重降低。所以咱們只讓測試程序拼裝並返回10~1萬個字符。由於實際應用過程當中，絕大多數RPC方法調用，一次調用經過網絡往返的數據量大體都位於這個區間內。

  注：做爲RPC框架，在方法調用時只傳輸小對象是能夠的。但做爲微服務框架，系統內服務的形式多種多樣，若是限制全部服務都不能返回大對象，彷佛有一些差強人意。在這一點上mac-rpc則更具優點。

3、測試要點

  在生產實踐中，咱們能夠看到這樣一種現象，單筆測試時，只須要幾個毫秒，甚至零毫秒的服務，在壓力測試或生產環境下，延遲到幾10、數百毫秒，有的甚至數秒，直到超過規定的響應時長。致使這一現象的緣由有不少，包括：磁盤IO、網絡IO、線程切換、鎖等待、CPU負載太高，內存不足，頻繁GC、第三方系統時延等等。常常會發現系統吞吐量低，響應緩慢時，各項物理資源消耗卻不多。

  爲了更真實的模擬生產的運行環境，咱們在方法中經過Thread.sleep來模擬以上各類緣由形成的時延。觀察RPC方法調用在受這些因素影響下的實際性能表現。此外，在大壓力的狀況下，輸入輸出數據量的大小對性能也有顯著影響，咱們還須要測試不一樣數據量下的性能表現。

  還有一個重要一因素就是微服務的粒度，服務粒度越小，靈活度越高，但在系統中相互調用的開銷就越大，管理起來也更加複雜。適當的粒度對提升系統的吞吐量很是重要。

3、測試方法

  服務消費者使用300線程並行的發起同步RPC方法調用，服務提供者採用固定600個線程的線程池。模擬在0ms、10ms、20ms、50ms、100ms時延下，數據量在十、1000、5000、10000個字符時的表現。

  同時爲了不磁盤IO和網絡IO對性能的影響，測試程序不打日誌，不寫磁盤。服務消費者和服務提供者都在同一臺電腦上。

  注：因爲長時延和大數據量時，測試耗時急劇增長，爲了節省時間，隨着時延加長、數據量的加大，每線程的調用次數相應的被減小到5000次或2000次。

4、測試結果

  注：每線程 = 每線程發起的調用次數

  

5、資源消耗

  資源上看，Dubbo的線程池使用SynchronousQueue隊列，這意味着服務消費者經過300個線程發起調用時，服務提供者對應的也會調起300個線程來執行。而mac-rpc的線程池默認使用LinkedBlockingQueue,使得服務消費者的線程數對服務提供者無影響。同時，mac-rpc默認採用CallerRunsPolicy做爲線程不足的處理策略，而dubbo則採用AbortPolicy，除非採用cached線程池，不然當線程不足時，dubbo將拋出RejectedExecutionException。不管從配置方便程度，仍是靈活度，mac-rpc都更優。

  在使用固定600個線程的線程池的狀況下，mac-rpc在CPU使用（25%）上略高於dubbo（20%），在內存使用上則顯著優於dubbo（50~200M），穩定在50M左右。

dubbo 服務提供方資源消耗：

mac-rpc 服務提供方資源消耗：

6、測試結論

  當時RPC方法的時延較小，且數據量也較小，在此例中約爲小於15ms，字節數小於大約2000~3000個時，Dubbo較mac-rpc有明顯優點。以後隨着時延和數據量的增長，mac-rpc的優點逐漸顯現，響應時間和TPS都相對平穩，而dubbo的性能則顯著降低，差距較大。繼續增大壓力，dubbo的表現會更糟糕，mac-rpc則相對更好一些。

  綜合來看，mac-rpc在同步方法調用方面，相較dubbo，有着更優秀的性能表現，穩定性也更好，可以更好的承受壓力。目前mac-rpc已具有了簡單的微服務治理能力，但因爲做者精力有限，發展時間較短，在功能性和治理手段方面還有待完善和增強。