微服務RPC框架選美

原標題：微服務RPC框架選美

轉載本文需註明出處：EAII企業架構創新研究院（微信號：eaworld），違者必究。如需加入微信群參與微課堂、架構設計與討論直播請直接回復此公眾號：「加群 姓名 公司 職位 微信號」。

1、RPC 框架誰最美？

Hello，everybody！說到RPC框架，可能大家能想到一堆RPC開源框架，那麼在微服務平臺中，微服務間的服務調用，不可避免的會遇到一個問題，該選用哪一個RPC框架好呢？今天我們就請到三位RPC框架，來進行一場選美大賽，看看誰更適合微服務平臺中的服務間調用。

大家好，我是Dubbo！我是阿里開源的分布式服務框架，最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地鬆耦合）。

大家好，我是Motan！我是微博開源的一套高性能、易於使用的分布式遠程服務調用(RPC)框架。

大家好，我是gRPC！我是Google開源的一套面向移動和HTTP/2設計的，高性能的、通用的遠程調用框架。

2、RPC框架的形體爭美

• 配置方式

  Motan：我支持 Xml 配置和 Spring註解配置。

  Dubbo：我支持 Xml 配置 、 註解配置、 屬性配置 、 API 配置 ！

  gRPC：我，我只支持 API 配置 。

  主持人： Xml 配置是用 xml 文件來配置協議 、 服務 、 註冊中心等信息 ，這是 rpc 框架最常用的配置方式，也是最基本的配置方式； 屬性配置 是 用 properties 文件來配置協議 、 服務 、 註冊中心等信息 ， 和Xml 配置使用上異曲同工 ； 注釋配置是聲明 Annotation 用來指定需要解析的包名 ， 使用 spring-boot 啟動服務 ，這是很多 RPC 所追求的，簡化了我們代碼的書寫， Maton 也是最新版本才開始支持的； API 配置是 Dubbo 的 API 配置僅用於 OpenAPI, ESB, Test, Mock 等系統集成 ， API 屬性與配置項一對一。

• 服務通信協議

  Motan：我支持 Motan 協議，使用tcp 長連接模式，基於 netty通信。

  Dubbo：我支持 Dubbo 協議、 Rmi 協議、 Hessian 協議、 HTTP 協議、 WebService 協議、Dubbo Thrift 協議、Memcached 協議！

  gRPC：我，我支持 HTTP/2.0 協議，基於 Netty4.1.3 通信。

• 序列化

  Motan：我默認使用對 java 更友好的 hessian2 進行序列化，還支持 Json 格式。

  Dubbo：Dubbo 協議預設序列化為hessian2 ， rmi 協議預設為java ， http 協議預設為 json！

  gRPC：哼！說到序列化，我是獨一無二的！我使用 ProtoBuf 來定義服務！

  主持人： gRPC 使用的 ProtoBuf 是由 Google 開發的一種數據序列化協議，用戶使用 .proto 文件定義服務，並支持定義多種類型的方法參數。 ProtoBuf 能夠將數據進行序列化，並廣泛應用在數據存儲、通信協議等方面。不過，當前 gRPC 僅支持 Protobuf ，且不支持在瀏覽器中使用。但由於 gRPC 的設計能夠支持支持多種數據格式，所以能夠很容易實現對其他數據格式（如 XML 、 JSON 等）的支持。這就是我強大的 IDL 特性！

• ActiveWeight / LeastActive ：低並發度優先， referer 的某時刻的 call 數越小優先級越高。

• Random ：隨機，按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

• RoundRobin ：輪循，按公約後的權重設置輪循比率。存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。

• LocalFirst ：本地服務優先獲取策略。

• Consistent ：一致性 Hash ，相同參數的請求總是發到同一提供者。當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

• ConfigurableWeight ：權重可配置的負載均衡策略。

• 容錯

  Motan：我支持 Failover 失效切換、Failfast 快速失敗。

  Dubbo：我支持 Failover 、 Failfast 、Failsafe 、 Failback 、 Forking、 Broadcast 。

  gRPC：我，我 具有 Failover 失效切換的容錯策略。

  主持人：依舊由我給大家介紹下各種容錯機制 ！

• Failover ：失敗自動切換，當出現失敗，重試其它伺服器。通常用於讀操作，但重試會帶來更長延遲。

• Failfast ：快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。

• Failsafe ：失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。

• Failback ：失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。

• Forking ：並行調用多個伺服器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。

• Broadcast ：廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。通常用於通知所有提供者更新緩存或日誌等本地資源信息。

• 註冊中心與服務發現

  Motan：我支持使用 Consul 作為註冊中心、使用 Zookeeper 作為註冊中心、點對點直連。

  Dubbo：我支持使用 Zookeeper 作為註冊中心、使用 Redis 註冊中心、使用 Multicast 註冊中心、使用 Simple 註冊中心。

  gRPC：我，我只能讓用戶自己擴展註冊中心 。

• 性能

  Motan：在高並發、高負載場景的場景下，我的 平均 TPS 和平均響應時間依舊保持良好，我具備在高壓力場景下的高可用能力。

  Dubbo：Dubbo2.0 相比較 Dubbo1.0（默認使用的都是 hessian2序列化）性能均有提升。如對性能有更高要求可以使用dubbo 序列化，由其是在處理複雜對象時。 Dubbo 的設計目的是為了滿足高並發小數據量的 rpc 調用，在大數據量下的性能表現並不好，建議使用 rmi 或 http 協議。

  gRPC：我採用的是 ProtoBuf 序列化協議 ， ProtoBuf 與其他協議的性能對比 ，非常明顯 的ProtoBuf 要遠遠優於其他 。

  主持人：三者的性能測試在各自官方說明上都可以看到詳細的性能測試報告 ， 這裡我們 並不做 詳細說明 。

3、RPC框架的才藝角逐

Motan ：通過 spring 配置方式集成，無需額外編寫代碼即可為服務提供分布式調用能力完全不需要任何 xml 配置文件， Dubbo 的註解配置還需要配合 xml 文件的哦 。

Dubbo ：無論從支持的註冊中心還是容錯機制上看，都是我 Dubbo 的優勢更大！

Motan ： 明顯支持負載均衡的模式我更多 。 我 擁有自定義動態負載均衡、跨機房流量調整等高級服務調度能力。

Dubbo ：成熟度更高的我在健壯性和伸縮性上還能比你們差麼？讓我來一一例舉。 說到健壯性 ，監控中心宕掉不影響使用，只是丟失部分採樣數據；資料庫宕掉後，註冊中心仍能通過緩存提供服務列表查詢，但不能註冊新服務；註冊中心對等集群，任意一臺宕掉後，將自動切換到另一臺；註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地緩存通訊；服務提供者無狀態，任意一臺宕掉後，不影響使用；服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復。至於伸縮性，註冊中心為對等集群，可動態增加機器部署實例，所有客戶端將自動發現新的註冊中心；服務提供者無狀態，可動態增加機器部署實例，註冊中心將推送新的服務提供者信息給消費者。

Motan ：對，我在功能上或許不是那麼全面，但我更注重簡單、易用以及在高並發高可用場景的使用。服務發現靈活支持多種配置管理組件，基於高並發高負載場景的高可用策略優化，良好的 SPI(Service Provider Interface) 擴展，詳細的調用統計，靈活支持多種 RPC 傳輸協議。

Dubbo ：說了這麼多你能支持泛型調用麼？我能！ Dubbo 提供 GenericService 泛型調用接口 ， 讓用戶的調用更加靈活 。

Motan ： 我的 工程依賴只涉及核心 5 個模塊，且可以按需依賴，不要的說捨棄就捨棄。看看你那麼一堆堆的工程，嘖嘖嘖 ……

gRPC ： 哼 ！ 本寶寶支持 服務的跨語言調用，目前所支持語言類型有 C++ 、 JAVA 、 GO 、 Python 、 Ruby 、 Node.js 、 Android 、 C# 、 PHP 、 Objective-C ，你們可以麼？

Motan ： 額 ，是啊，我們不能，可是你有服務發現相關機制麼？

Dubbo ：而且你的負載均衡和容錯也太弱了 …..

gRPC ： 嚶嚶嚶 ……

4、RPC框架的終極PK

Dubbo作為阿里開源的分布式服務框架，實現高性能的 RPC 調用同時提供了豐富的管理功能，是一款應用廣泛的優秀的 RPC 框架，但現在較少維護更新。如果你需要一款高成熟度的服務治理型的RPC框架，不如選我！

Motan作為微博的 Motan RPC 傾向於服務治理型，與 Dubbo 系列相比在功能上或許不是那麼全，擴展實現也沒有那麼多，但如果你需要一款高性能輕量級易上手的RPC框架，記得選我！

gRPC作為google2015年才開源的跨語言調用型的RPC框架，側重於服務的跨語言調用，能夠支持大部分的語言進行語言無關的調用，非常適合多語言調用場景。如果你需要支持多語言，跨語言調用的RPC框架，選我吧！

看了以上三位RPC框架的選美比賽不知道大家是否都有了自己的選擇。當然，現如今的市場中開源的RPC遠遠不止這三個，到底哪個才是你現在所需要的，這裡也只是個參考，也是我們在微服務中RPC框架選擇的一個方向，最終的選擇還是要「因地制宜」。

作為踏入微服務行列的普元，我們的微服務平臺採用了 Maton RPC 框架，高並發高負載 、輕量易維護 以及無需任何額外代碼和配置的 Spring 註解配置，都是我們所需要的。當然我們也並不是完全滿足於當前的Maton 功能，不過 Motan 良好的擴展機制，也給我們提供了便利，我們擴展了 ETCD 註冊中心以及我們自己的日誌記錄方式，當然還有更多的貼合我們實際應用的改造。相信在每個正在尋找微服務交互的 RPC 框架的你們，經過反覆的對比研究，也能找到你們心中的那個唯一！

關於作者

葉婉婷

現任普元信息SOA產品部高級軟體工程師，為普元新一代數位化企業雲平臺開發團隊一員。在過去的兩年參與流程平臺項目，主要負責Eclipse插件開發及自動化測試平臺開發。在數位化企業雲平臺項目中參與了業務平臺領域系統的開發。愛好：旅遊、電影、美食、遊泳。

關於EAII

EAII（Enterprise Architecture Innovation Institute）企業架構創新研究院，致力於軟體架構創新與實踐，加速企業數位化轉型。

eaworld項目（微信號：eaworld，長按二維碼關注）

eaworld是EAII的官方微信帳號。返回搜狐，查看更多

責任編輯：