服務器通訊原理就是一臺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

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的RPC的发展历史的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。