RPC的發展歷史（本質就是雙方定義好協議，傳遞參數後遠程調用）

服務器通信原理就是一臺socket服務器A,另外一臺socket客戶端B,如今若是要通信的話直接以流方式寫入或讀出。

這樣能實現通信，但有個問題。如何知道更多信息？好比須要發送流大小，編碼，Ip等。

這樣就有了協議，協議就是規範，就是發送的流中攜帶了不少的內容。

RPC的實現就是一種規範。可參考http://javatar.iteye.com/blog/1123915 這個簡單RPC實現。

RPC(遠程過程調用)是什麼

• 簡單的說，RPC就是從一臺機器（客戶端）上經過參數傳遞的方式調用另外一臺機器（服務器）上的一個函數或方法（能夠統稱爲服務）並獲得返回的結果。
• RPC 會隱藏底層的通信細節（不須要直接處理Socket通信或Http通信）
• RPC 是一個請求響應模型。客戶端發起請求，服務器返回響應（相似於Http的工做方式）
• RPC 在使用形式上像調用本地函數（或方法）同樣去調用遠程的函數（或方法）。

遠程過程調用發展歷程

• ONC RPC （開放網絡計算的遠程過程調用），OSF RPC（開放軟件基金會的遠程過程調用）
• CORBA（Common Object Request Broker Architecture公共對象請求代理體系結構）
• DCOM（分佈式組件對象模型），COM+
• Java RMI
• .NET Remoting
• XML-RPC，SOAP，Web Service
• PHPRPC，Hessian，JSON-RPC
• Microsoft WCF，WebAPI
• ZeroC Ice，Thrift，GRPC
• Hprose

早期的 RPC

• 第一代 RPC（ONC RPC，OSF RPC）不支持對象的傳遞。
• CORBA 太複雜，各類不一樣實現不兼容，通常程序員也玩不轉。
• DCOM，COM+ 逃不出 Windows 的手掌心。
• RMI 只能在 Java 裏面玩。
• .NET Remoting 只能在 .NET 平臺上玩。

XML-RPC，SOAP，WebService

• 冗餘數據太多，處理速度太慢。
• RPC 風格的 Web Service 跨語言性不佳，而 Document 風格的 Web Service 又太過難用。
• Web Service 沒有解決用戶的真正問題，只是把一個問題變成了另外一個問題。
• Web Service 的規範太過複雜，以致於在 .NET 和 Java 平臺之外沒有真正好用的實現，甚至沒有可用的實現。
• 跨語言跨平臺只是 Web Service 的一個口號，雖然不少人迷信這一點，但事實上它並無真正實現。

PHPRPC

• 基於 PHP 內置的序列化格式，在跨語言的類型映射上存在硬傷。
• 通信上依賴於 HTTP 協議，沒有其它底層通信方式的選擇。
• 內置的加密傳輸既是特色，也是缺點。
• 雖然比基於 XML 的 RPC 速度快，但還不是足夠快。

Hessian

• 二進制的數據格式徹底不具備可讀性。
• 官方只提供了兩個半語言的實現（Java，ActionScript 和不怎麼完美的 Python 實現），其它語言的第三方實現參差不齊。
• 支持的語言不夠多，對 Web 前端的 JavaScript 徹底無視。
• 雖然是動態 RPC，但動態性仍然欠佳。
• 雖然比基於 XML 的 RPC 速度快，但還不是足夠快。

JSON-RPC

• JSON 具備文本可讀性，且比 XML 更簡潔。
• JSON 受 JavaScript 語言子集的限制，可表示的數據類型不夠多。
• JSON 格式沒法表示數據內的自引用，互引用和循環引用。
• 某些語言具備多種版本的實現，但在類型影射上沒有統一標準，存在兼容性問題。
• JSON-RPC 雖然有規範，可是卻沒有統一的實現。在不一樣語言中的各自實現存在兼容性問題，沒法真正互通。

Microsoft WCF，WebAPI

• 它們是微軟對已有技術的一個 .NET 平臺上的統一封裝，是對 .NET Remoting、WebService 和基於 JSON 、XML 等數據格式的 REST 風格的服務等技術的一個整合。
• 雖然號稱能夠在 .NET 平臺之外來調用它的這些服務，但實際上跟在 .NET 平臺內調用徹底是兩碼事。它沒有提供任何在其餘平臺的語言中可使用的任何工具。

ZeroC Ice，Thrift，GRPC

• 初代 RPC 技術的跨語言面向對象的迴歸。
• 仍然須要經過中間語言來編寫類型和接口定義。
• 仍然須要用代碼生成器來將中間語言編寫的類型和接口定義翻譯成你所使用的編程語言的客戶端和服務器端的佔位程序（stub）。
• 你必需要基於生成的服務器代碼來單獨編寫服務，而不能將已有代碼直接做爲服務發佈。
• 你必需要用生成的客戶端代碼來調用服務，而沒有其它更靈活的方式。
• 若是你的中間代碼作了修改，以上全部步驟你都要至少重複一遍。

Hprose

• 無侵入式設計，不須要單獨定義類型，不須要單獨編寫服務，已有代碼能夠直接發佈爲服務。
• 具備豐富的數據類型和完美的跨語言類型映射，支持自引用，互引用和循環引用數據。
• 支持衆多傳輸方式，如 HTTP、TCP、Websocket 等。
• 客戶端具備更靈活的調用方式，支持同步調用，異步調用，動態參數，可變參數，引用參數傳遞，多結果返回（Golang）等語言特徵，Hprose 2.0 甚至支持推送。
• 具備良好的可擴展性，能夠經過過濾器和中間件實現加密、壓縮、緩存、代理等各類功能性擴展。
• 兼容的無差異跨語言調用
• 支持更多的經常使用語言和平臺
• 支持瀏覽器端的跨域調用
• 沒有中間語言，無需學習成本
• 性能卓越，使用簡單

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

http://www.cnblogs.com/ningskyer/articles/5518600.html