拼顏值、拼才藝、更拼價值。
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 特性！
負載均衡
Motan：我支持 ActiveWeight 、Random 、 RoundRobin 、LocalFirst 、 Consistent 、ConfigurableWeight 。
Dubbo：我可以支持 Random 、RoundRobin 、ConsistentHash 、 LeastActive。
gRPC：我，我提供了可插拔負載均衡器的機制。
主持人：這裡讓我來解釋下每種負載均衡的模式吧 ！
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 框架的你們，經過反覆的對比研究，也能找到你們心中的那個唯一！
閱讀更多 架構師的修煉之路 的文章
