看到了一些關于RPC的框架 比如 soap，yar，phprpc,thrift。對這些東西不怎么了解，有什么樣的作用 回復內容： 看到了一些關于RPC的框架 比如 soap，yar，phprpc,thrift。對這些東西不怎么了解，有什么樣的作用
回答第一個問題：什么是RPC框架？ 如果用一句話概括RPC就是：遠程調用框架
那什么是“遠程調用”？通常我們調用一個方法，譬如: localAdd(10, 20)，localAdd方法的具體實現要么是用戶自己定義，要么存在于該語言的庫函數中，也就說在localAdd方法的代碼實現在本地，它是一個本地調用！
“遠程調用”意思就是：被調用方法的具體實現不在程序運行本地，而是在別的某個地方；
遠程調用原理譬如 A調用B提供的remoteAdd方法：,
首先A與B之間建立一個TCP連接；
然后A把需要調用的方法名（這里是remoteAdd）以及方法參數（10， 20）序列化成字節流發送出去；
B接受A發送過來的字節流，然后反序列化得到目標方法名，方法參數，接著執行相應的方法調用（可能是localAdd）并把結果30返回；
- A接受遠程調用結果
RPC框架無非就是把我剛才說的那些細節通通封裝起來，給用戶暴露簡單友好的API使用（ps：有些遠程調用選擇比較底層的socket協議，有些遠程調用選擇比較上層的HTTP協議）；
遠程調用好處：- 解耦：當方法提供者需要對方法內實現修改時，調用者完全感知不到，不用做任何變更；這種方式在跨部門，跨公司合作的時候經常用到，并且方法的提供者我們通常稱為：服務的暴露方
至于soap，yar，phprpc,thrift這幾樣的東西，一個都沒用過，所以不好評價
關于比較經典和流行的RPC框架應該是facebook開源的thirft框架?？梢詤⒖枷逻@篇博文
淺談Facebook的服務器架構
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 技術的跨語言html' target='_blank'>面向對象的回歸。
- 仍然需要通過中間語言來編寫類型和接口定義。
- 仍然需要用代碼生成器來將中間語言編寫的類型和接口定義翻譯成你所使用的編程語言的客戶端和服務器端的占位程序（stub）。
- 你必須要基于生成的服務器代碼來單獨編寫服務，而不能將已有代碼直接作為服務發布。
- 你必須要用生成的客戶端代碼來調用服務，而沒有其它更靈活的方式。
- 如果你的中間代碼做了修改，以上所有步驟你都要至少重復一遍。
Hprose
- 無侵入式設計，不需要單獨定義類型，不需要單獨編寫服務，已有代碼可以直接發布為服務。
- 具有豐富的數據類型和完美的跨語言類型映射，支持自引用，互引用和循環引用數據。
- 支持眾多傳輸方式，如 HTTP、TCP、Websocket 等。
- 客戶端具有更靈活的調用方式，支持同步調用，異步調用，動態參數，可變參數，引用參數傳遞，多結果返回（Golang）等語言特征，Hprose 2.0 甚至支持推送。
- 具有良好的可擴展性，可以通過過濾器和中間件實現加密、壓縮、緩存、代理等各種功能性擴展。
- 兼容的無差別跨語言調用
- 支持更多的常用語言和平臺
- 支持瀏覽器端的跨域調用
- 沒有中間語言，無需學習成本
- 性能卓越，使用簡單
Web Service 里就會用到soap的方式啊。
RPC是Remote Procedure Call的縮寫
Procedure就是function的另類寫法，RPC就是在本地調用遠程服務器上的一個function，僅此而已。
RPC有多種協議。SOAP是HTTP+XML base的RPC protocol。Thrift是binary的RPC protocol。
RPC的主要目的是解決不同語言間互相調用的問題。一個足夠復雜的集群中，有的服務器跑PHP，有的服務器跑Python，有的服務器跑C++，互相之間怎么傳遞信息？這需要有一個約定：函數名有什么要求？函數參數支持什么類型？int類型的變量是32bit unsigned還是16bit signed？服務器和客戶端之間通訊的字節流是big endian還是little endian？這些約定就是所謂的RPC協議。
至于什么是RPC框架？這個真不知道。第一次聽說。
我也是醉了，這個和API有什么區別？ API還可以更方便的做限制，RPC對于PHP意義不大啊
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
