看到了一些關(guān)于RPC的框架 比如 soap，yar，phprpc,thrift。對這些東西不怎么了解，有什么樣的作用

回答第一個問題：什么是RPC框架？ 如果用一句話概括RPC就是：遠(yuǎn)程調(diào)用框架

通常我們調(diào)用一個方法，譬如: localAdd(10, 20)，localAdd方法的具體實現(xiàn)要么是用戶自己定義，要么存在于該語言的庫函數(shù)中，也就說在localAdd方法的代碼實現(xiàn)在本地，它是一個本地調(diào)用！

“遠(yuǎn)程調(diào)用”意思就是：被調(diào)用方法的具體實現(xiàn)不在程序運(yùn)行本地，而是在別的某個地方；

譬如 A調(diào)用B提供的remoteAdd方法：,

1. 首先A與B之間建立一個TCP連接；

2. 然后A把需要調(diào)用的方法名（這里是remoteAdd）以及方法參數(shù)（10， 20）序列化成字節(jié)流發(fā)送出去；

3. B接受A發(fā)送過來的字節(jié)流，然后反序列化得到目標(biāo)方法名，方法參數(shù)，接著執(zhí)行相應(yīng)的方法調(diào)用（可能是localAdd）并把結(jié)果30返回；

4. A接受遠(yuǎn)程調(diào)用結(jié)果

RPC框架無非就是把我剛才說的那些細(xì)節(jié)通通封裝起來，給用戶暴露簡單友好的API使用（ps：有些遠(yuǎn)程調(diào)用選擇比較底層的socket協(xié)議，有些遠(yuǎn)程調(diào)用選擇比較上層的HTTP協(xié)議）；

• 解耦：當(dāng)方法提供者需要對方法內(nèi)實現(xiàn)修改時，調(diào)用者完全感知不到，不用做任何變更；這種方式在跨部門，跨公司合作的時候經(jīng)常用到，并且方法的提供者我們通常稱為：服務(wù)的暴露方

至于soap，yar，phprpc,thrift這幾樣的東西，一個都沒用過，所以不好評價

關(guān)于比較經(jīng)典和流行的RPC框架應(yīng)該是facebook開源的thirft框架。可以參考下這篇博文
淺談Facebook的服務(wù)器架構(gòu)

RPC(遠(yuǎn)程過程調(diào)用)是什么

• 簡單的說，RPC就是從一臺機(jī)器（客戶端）上通過參數(shù)傳遞的方式調(diào)用另一臺機(jī)器（服務(wù)器）上的一個函數(shù)或方法（可以統(tǒng)稱為服務(wù)）并得到返回的結(jié)果。
• RPC 會隱藏底層的通訊細(xì)節(jié)（不需要直接處理Socket通訊或Http通訊）
• RPC 是一個請求響應(yīng)模型?？蛻舳税l(fā)起請求，服務(wù)器返回響應(yīng)（類似于Http的工作方式）
• RPC 在使用形式上像調(diào)用本地函數(shù)（或方法）一樣去調(diào)用遠(yuǎn)程的函數(shù)（或方法）。

遠(yuǎn)程過程調(diào)用發(fā)展歷程

• ONC RPC （開放網(wǎng)絡(luò)計算的遠(yuǎn)程過程調(diào)用），OSF RPC（開放軟件基金會的遠(yuǎn)程過程調(diào)用）
• CORBA（Common Object Request Broker Architecture公共對象請求代理體系結(jié)構(gòu)）
• 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 太復(fù)雜，各種不同實現(xiàn)不兼容，一般程序員也玩不轉(zhuǎn)。
• DCOM，COM+ 逃不出 Windows 的手掌心。
• RMI 只能在 Java 里面玩。
• .NET Remoting 只能在 .NET 平臺上玩。

XML-RPC，SOAP，WebService

• 冗余數(shù)據(jù)太多，處理速度太慢。
• RPC 風(fēng)格的 Web Service 跨語言性不佳，而 Document 風(fēng)格的 Web Service 又太過難用。
• Web Service 沒有解決用戶的真正問題，只是把一個問題變成了另一個問題。
• Web Service 的規(guī)范太過復(fù)雜，以至于在 .NET 和 Java 平臺以外沒有真正好用的實現(xiàn)，甚至沒有可用的實現(xiàn)。
• 跨語言跨平臺只是 Web Service 的一個口號，雖然很多人迷信這一點(diǎn)，但事實上它并沒有真正實現(xiàn)。

PHPRPC

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

Hessian

• 二進(jìn)制的數(shù)據(jù)格式完全不具有可讀性。
• 官方只提供了兩個半語言的實現(xiàn)（Java，ActionScript 和不怎么完美的 Python 實現(xiàn)），其它語言的第三方實現(xiàn)良莠不齊。
• 支持的語言不夠多，對 Web 前端的 JavaScript 完全無視。
• 雖然是動態(tài) RPC，但動態(tài)性仍然欠佳。
• 雖然比基于 XML 的 RPC 速度快，但還不是足夠快。

JSON-RPC

• JSON 具有文本可讀性，且比 XML 更簡潔。
• JSON 受 JavaScript 語言子集的限制，可表示的數(shù)據(jù)類型不夠多。
• JSON 格式無法表示數(shù)據(jù)內(nèi)的自引用，互引用和循環(huán)引用。
• 某些語言具有多種版本的實現(xiàn)，但在類型影射上沒有統(tǒng)一標(biāo)準(zhǔn)，存在兼容性問題。
• JSON-RPC 雖然有規(guī)范，但是卻沒有統(tǒng)一的實現(xiàn)。在不同語言中的各自實現(xiàn)存在兼容性問題，無法真正互通。

Microsoft WCF，WebAPI

• 它們是微軟對已有技術(shù)的一個 .NET 平臺上的統(tǒng)一封裝，是對 .NET Remoting、WebService 和基于 JSON 、XML 等數(shù)據(jù)格式的 REST 風(fēng)格的服務(wù)等技術(shù)的一個整合。
• 雖然號稱可以在 .NET 平臺以外來調(diào)用它的這些服務(wù)，但實際上跟在 .NET 平臺內(nèi)調(diào)用完全是兩碼事。它沒有提供任何在其他平臺的語言中可以使用的任何工具。

ZeroC Ice，Thrift，GRPC

• 初代 RPC 技術(shù)的跨語言html' target='_blank'>面向?qū)ο?/u>的回歸。
• 仍然需要通過中間語言來編寫類型和接口定義。
• 仍然需要用代碼生成器來將中間語言編寫的類型和接口定義翻譯成你所使用的編程語言的客戶端和服務(wù)器端的占位程序（stub）。
• 你必須要基于生成的服務(wù)器代碼來單獨(dú)編寫服務(wù)，而不能將已有代碼直接作為服務(wù)發(fā)布。
• 你必須要用生成的客戶端代碼來調(diào)用服務(wù)，而沒有其它更靈活的方式。
• 如果你的中間代碼做了修改，以上所有步驟你都要至少重復(fù)一遍。

Hprose

• 無侵入式設(shè)計，不需要單獨(dú)定義類型，不需要單獨(dú)編寫服務(wù)，已有代碼可以直接發(fā)布為服務(wù)。
• 具有豐富的數(shù)據(jù)類型和完美的跨語言類型映射，支持自引用，互引用和循環(huán)引用數(shù)據(jù)。
• 支持眾多傳輸方式，如 HTTP、TCP、Websocket 等。
• 客戶端具有更靈活的調(diào)用方式，支持同步調(diào)用，異步調(diào)用，動態(tài)參數(shù)，可變參數(shù)，引用參數(shù)傳遞，多結(jié)果返回（Golang）等語言特征，Hprose 2.0 甚至支持推送。
• 具有良好的可擴(kuò)展性，可以通過過濾器和中間件實現(xiàn)加密、壓縮、緩存、代理等各種功能性擴(kuò)展。
• 兼容的無差別跨語言調(diào)用
• 支持更多的常用語言和平臺
• 支持瀏覽器端的跨域調(diào)用
• 沒有中間語言，無需學(xué)習(xí)成本
• 性能卓越，使用簡單