什麼是RPC呢？百度百科給出的解釋是這樣的：“RPC（Remote Procedure Call Protocol）——遠程過程調用協議，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議”。REST這個詞，是Roy Thomas Fielding在他2000年的博士論文中提出的。現在貌似流行了起來，甚至出現過：RESTful API是目前比較成熟的一套互聯網應用程序的API設計理論，作爲前端設備與後端(主要用於B/S架構)進行通信的架構，有必要好好熟悉一下。
既 REST ，何 RPC ？
在 OpenStack 裏的進程間通信方式主要有兩種，一種是基於HTTP協議的RESTFul API方式，另一種則是RPC調用。
那麼這兩種方式在應用場景上有何區別呢？
有使用經驗的人，會說：
前者（RESTful）主要用於各組件之間的通信（如nova與glance的通信），或者說用於組件對外提供調用接口而後者（RPC）則用於同一組件中各個不同模塊之間的通信（如nova組件中nova-compute與nova-scheduler的通信）。首先，給你提兩個問題，帶着這兩個問題再往下看：
RPC 和 REST 區別是什麼？2、爲什麼要採用RPC呢？
首先，第一個問題：RPC 和 REST 區別是什麼？(如下圖)
你一定會覺得這個問題很奇怪，是的，包括我，但是你在網絡上一搜，會發現類似對比的文章比比皆是，我在想可能很多初學者由於基礎不牢固，纔會將不相干的二者拿出來對比吧。既然是這樣，那爲了讓你更加了解陌生的RPC，就從你熟悉得不能再熟悉的 REST 入手吧。
01、所屬類別不同
REST，是Representational State Transfer 的簡寫，中文描述表述性狀態傳遞（是指某個瞬間狀態的資源數據的快照，包括資源數據的內容、表述格式(XML、JSON)等信息。）
REST 是一種軟件架構風格。這種風格的典型應用，就是HTTP。其因爲簡單、擴展性強的特點而廣受開發者的青睞。
而RPC 呢，是 Remote Procedure Call Protocol 的簡寫，中文描述是遠程過程調用，它可以實現客戶端像調用本地服務(方法)一樣調用服務器的服務(方法)。
而 RPC 可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的，按理說它和REST不是一個層面意義上的東西，不應該放在一起討論，但是誰讓REST這麼流行呢，它是目前最流行的一套互聯網應用程序的API設計標準，某種意義下，我們說 REST 可以其實就是指代 HTTP 協議。
02、使用方式不同
從使用上來看，HTTP 接口只關注服務提供方，對於客戶端怎麼調用並不關心。接口只要保證有客戶端調用時，返回對應的數據就行了。而RPC則要求客戶端接口保持和服務端的一致。
REST 是服務端把方法寫好，客戶端並不知道具體方法。客戶端只想獲取資源，所以發起HTTP請求，而服務端接收到請求後根據URI經過一系列的路由才定位到方法上面去RPC是服務端提供好方法給客戶端調用，客戶端需要知道服務端的具體類，具體方法，然後像調用本地方法一樣直接調用它。03、面向對象不同
從設計上來看，RPC，所謂的遠程過程調用 ，是面向方法的 ，REST：所謂的 Representational state transfer ，是面向資源的，除此之外，還有一種叫做 SOA，所謂的面向服務的架構，它是面向消息的，這個接觸不多，就不多說了。
03、序列化協議不同
接口調用通常包含兩個部分，序列化和通信協議。
通信協議，上面已經提及了，REST 是 基於 HTTP 協議，而 RPC 可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的。
常見的序列化協議，有：json、xml、hession、protobuf、thrift、text、bytes等，REST 通常使用的是 JSON或者XML，而 RPC 使用的是 JSON-RPC，或者 XML-RPC。
04、應用場景
REST和RPC都常用於微服務架構中。
1、HTTP相對更規範，更標準，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平臺，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，現在開源中間件，基本最先支持的幾個協議都包含RESTful。
RPC在微服務中的利用
2、 RPC 框架作爲架構微服務化的基礎組件，它能大大降低架構微服務化的成本，提高調用方與服務提供方的研發效率，屏蔽跨進程調用函數（服務）的各類複雜細節。讓調用方感覺就像調用本地函數一樣調用遠端函數、讓服務提供方感覺就像實現一個本地函數一樣來實現服務。
REST調用及測試都很方便，RPC就顯得有點繁瑣，但是RPC的效率是毋庸置疑的，所以建議在多系統之間的內部調用採用RPC。對外提供的服務，Rest更加合適。
REST與RPC比較：
通過以上幾點，我們知道了 REST 和 RPC 之間有很明顯的差異。
然後第二個問題：爲什麼要採用RPC呢？
那到底爲何要使用 RPC，單純的依靠RESTful API不可以嗎？爲什麼要搞這麼多複雜的協議。
關於這一點，以下幾點僅僅個人觀點，僅供交流：
RPC 和 REST 兩者的定位不同，REST 面向資源，更注重接口的規範，因爲要保證通用性更強，所以對外最好通過 REST。而 RPC 面向方法，主要用於函數方法的調用，可以適合更復雜通信需求的場景。RESTful API客戶端與服務端之間採用的是同步機制，當發送HTTP請求時，客戶端需要等待服務端的響應。當然對於這一點是可以通過一些技術來實現異步的機制的。採用RESTful API，客戶端與服務端之間雖然可以獨立開發，但還是存在耦合。比如，客戶端在發送請求的時，必須知道服務器的地址，且必須保證服務器正常工作。而 rpc + ralbbimq中間件可以實現低耦合的分佈式集羣架構。說了這麼多，我們該如何選擇這兩者呢？我總結了如下兩點，供你參考：
REST 接口更加規範，通用適配性要求高，建議對外的接口都統一成 REST。而組件內部的各個模塊，可以選擇 RPC，一個是不用耗費太多精力去開發和維護多套的HTTP接口，一個RPC的調用性能更高（見下條）從性能角度看，由於HTTP本身提供了豐富的狀態功能與擴展功能，但也正由於HTTP提供的功能過多，導致在網絡傳輸時，需要攜帶的信息更多，從性能角度上講，較爲低效。而RPC服務網絡傳輸上僅傳輸與業務內容相關的數據，傳輸數據更小，性能更高。RPC注重安全性、高性能、跨平臺、跨語言、天生支持分佈式、客戶端服務端完全解耦，工程師們在做技術選型的時候酌情考慮。