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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！