2.1.5　分裂的RPC

由于一直沒有一個同時滿足以上三點的“完美RPC協議”出現，所以遠程服務器調用這個小小的領域，逐漸進入群雄混戰、百家爭鳴的戰國時代，距離“統一”越來越遠，并一直延續至今?，F在，已經相繼出現過RMI（Sun/Oracle）、Thrift（Facebook/Apache）、Dubbo（阿里巴巴/Apache）、gRPC（Google）、Motan1/2（新浪）、Finagle（Twitter）、brpc（百度/Apache）、.NET Remoting（微軟）、Arvo（Hadoop）、JSON-RPC 2.0（公開規范，JSON-RPC工作組）等難以窮舉的協議和框架。這些RPC功能、特點不盡相同，有的是某種語言私有，有的支持跨越多種語言，有的運行在應用層HTTP協議之上，有的直接運行于傳輸層TCP/UDP協議之上，但并不存在哪一款是“最完美的RPC”。今時今日，任何一款具有生命力的RPC框架，都不再去追求大而全的“完美”，而是以某個具有針對性的特點作為主要的發展方向，舉例分析如下。

·朝著面向對象發展，不滿足于RPC將面向過程的編碼方式帶到分布式，希望在分布式系統中也能夠進行跨進程的面向對象編程，代表為RMI、.NET Remoting，之前的CORBA和DCOM也可以歸入這類。這種方式有一個別名叫作分布式對象（Distributed Object）。

·朝著性能發展，代表為gRPC和Thrift。決定RPC性能的主要因素有兩個：序列化效率和信息密度。序列化效率很好理解，序列化輸出結果的容量越小，速度越快，效率自然越高；信息密度則取決于協議中有效負載（Payload）所占總傳輸數據的比例大小，使用傳輸協議的層次越高，信息密度就越低，SOAP使用XML拙劣的性能表現就是前車之鑒。gRPC和Thrift都有自己優秀的專有序列化器，而傳輸協議方面，gRPC是基于HTTP/2的，支持多路復用和Header壓縮，Thrift則直接基于傳輸層的TCP協議來實現，省去了應用層協議的額外開銷。

·朝著簡化發展，代表為JSON-RPC，說要選功能最強、速度最快的RPC可能會很有爭議，但選功能弱的、速度慢的，JSON-RPC肯定會是候選人之一。犧牲了功能和效率，換來的是協議的簡單輕便，接口與格式都更為通用，尤其適合用于Web瀏覽器這類一般不會有額外協議支持、額外客戶端支持的應用場合。

經歷了RPC框架的“戰國時代”，開發者們終于認可了不同的RPC框架所提供的特性或多或少是有矛盾的，很難有某一種框架能滿足所有需求。若要朝著面向對象發展，就注定不會太簡單，如建Stub、Skeleton就很煩了，即使由IDL生成也很麻煩；功能多起來，協議就會更復雜，效率一般也會受影響；要簡單易用，那很多事情就必須遵循約定而不是自行配置；要重視效率，那就需要采用二進制的序列化器和較底層的傳輸協議，支持的語言范圍容易受限。也正是每一種RPC框架都有不完美的地方，所以才導致不斷有新的RPC輪子出現，也決定了在選擇框架時，在獲得一些利益的同時，要付出另外一些代價。

到了最近幾年，RPC框架有明顯向更高層次（不僅僅負責調用遠程服務，還管理遠程服務）與插件化方向發展的趨勢，不再追求獨立地解決RPC的全部三個問題（表示數據、傳遞數據、表示方法），而是將一部分功能設計成擴展點，讓用戶自己選擇。框架聚焦于提供核心的、更高層次的能力，譬如提供負載均衡、服務注冊、可觀察性等方面的支持。這一類框架的代表有Facebook的Thrift與阿里的Dubbo，尤其是斷更多年后重啟的Dubbo表現得更為明顯。Dubbo默認有自己的傳輸協議（Dubbo協議），同時也支持其他協議；默認采用Hessian 2作為序列化器，如果你有JSON的需求，可以替換為Fastjson，如果你對性能有更高的追求，可以替換為Kryo、FST、Protocol Buffers等效率更好的序列化器，如果你不想依賴其他組件庫，也可以直接使用JDK自帶的序列化器。這種設計在一定程度上緩和了RPC框架必須取舍、難以完美的缺憾。

最后，筆者提個問題，大家不妨來反思一下：開發一個分布式系統，是不是就一定要用RPC呢？RPC的三大問題源自于對本地方法調用的類比模擬，如果我們把思維從“方法調用”的約束中掙脫，那在解決參數與結果如何表示、數據如何傳遞、方法如何表示這些問題時都會有煥然一新的視角。但是我們寫程序，真的可能不面向方法來編程嗎？這就是筆者下一節準備談的話題了。

后記

前文提及DCOM、CORBA、Web Service的失敗時，可能筆者的口吻多少有一些戲謔，這只是落筆行文的方式。這些框架即使沒有成功，但作為早期的探索先驅，并沒有什么該去諷刺的地方。而且它們的后續發展，都稱得上是知恥后勇，都值得我們贊賞。譬如說到CORBA的消亡，OMG痛定思痛之后，提出了基于RTPS協議棧的“數據分發服務”（Data Distribution Service，DDS）商業標準（就是要付費使用的意思），如今主要流行于物聯網領域，能夠做到微秒級延時，還能支持大規模并發通信。譬如說到DCOM的失敗和Web Service的式微，微軟在它們的基礎上推出的.NET WCF（Windows Communication Foundation，Windows通信基礎），不僅同時將REST、TCP、SOAP等不同形式的調用自動封裝為完全一致的如同本地方法調用一般的程序接口，還依靠自家的“地表最強IDE”Visual Studio將工作量減少到只需要指定一個遠程服務地址，就可以獲取服務描述、綁定各種特性（譬如安全傳輸）、自動生成客戶端調用代碼，甚至還能選擇同步或者異步之類細節的程度。盡管.NET WCF只支持.NET平臺，而且與傳統Web Service一樣采用XML描述，但使用體驗異常暢快，能挽回Web Service中得罪開發者丟掉的全部印象分。