淺談 RPC、RMI、REST 這些很繞的概念
最近準備詳細看一下 RPC 相關的知識，這是第一篇
什麼是 RPC
RPC（Remote Procedure Call) 翻譯過來叫遠端過程呼叫，加上 Protocol 之後也有稱之為遠端過程呼叫協議，可以由不同的語言實現，根據維基百科的解釋 —— RPC 指在分散式環境下，一個計算機程式能呼叫另一個不同地址空間裡的方法（不同地址空間通常指區域網下的另一臺計算機），但是編碼的形式就像呼叫一個本地方法一樣，程式設計師不用去關心背後的細節。
為什麼要有 RPC 呢？因為你的程式碼所依賴的服務可能部署在不同的伺服器上，而你的程式需要通過網路呼叫另一臺伺服器中的某個方法得到結果，在分散式系統中這種場景很常見，微服務的興起也使得程式間的呼叫鏈變得非常複雜、有時候眼花繚亂，RPC 就是為了解決這種問題而誕生的。
常見的 RPC 框架
目前流行的 RPC 框架有阿里的 Dubbo，微博開源的 Motan，Google 開源的 gRpc，百度開源的 brpc，螞蟻金服開源的 sofa-rpc 等等，Github 上還有數不清的又個人自己實現的簡單 RPC 框架，雖然沒有什麼企業級利用價值，但是對於想了解 RPC 框架原理的新手來說是很寶貴的學習資料。
RPC 和 RMI 的區別
網上一搜這種答案寫得都不太好，以我自己來看，二者區別有
- RPC 更像一種協議，可以跨語言實現，而 RMI 僅支援 Java，需要雙方都執行在 JVM 中
- RPC 通過傳入 class 和 methodName 的形式利用反射和代理類呼叫該方法；RMI 需要依靠方法簽名去 lookUp，找到了該方法之後呼叫它
- RMI 可以 Java 物件和基本資料型別，而 RPC 通常藉助不同的序列化協議來進行網路傳輸，有編解碼的過程
REST 和 RPC 的區別
看了上述的應用場景後，你可能覺得易用的 RESTful API 不也是差不多的麼，也是呼叫一個地址，傳入引數，返回結果，而且簡單易用，為什麼還要有 RPC 框架呢？
回答這個問題不太容易，因為其中的概念很繞。一般來說，在企業級應用中，外部請求進入系統通常使用 RESTful API 的形式，例如使用者在 APP 端點選推薦列表；請求在內部系統間處理，服務之間的呼叫通常採用 RPC 的方式，例如根據演算法返回該使用者的推薦列表資料。
REST 風格
REST 是一種架構風格，面向資源（由一個 URL 唯一指定），主要是名詞，它很好的利用了 HTTP 中已有的請求方法（PUT、POST、GET、DELETE）做操作形式的區分，例如以下場景，左邊是錯誤的 RESTful API 定義（注意，這就是普通的 HTTP 請求地址，這種技術很早就有了，Spring 中你完全可以這樣編碼去實現功能，只是你的這種風格不叫 RESTful API，而就是普通的 HTTP 請求而已），右邊才是符合 REST 風格的定義：
| 普通HTTP請求 | REST 風格請求 |
|---|---|
| GET /rest/api/getBooks | GET /rest/api/books |
| GET /rest/api/addBooks | POST /rest/api/books |
| GET /rest/api/editBooks/:bookId | PUT /rest/api/books/:bookId |
RPC
而 RPC 主要是動片語成，面向方法，例如方法名為 queryAllBooks，通過客戶端和服務端共有的一個方法來進行呼叫，編碼的時候可以像使用本地方法一樣，編碼效率更高。
二者區別
- REST 基於 HTTP 傳輸協議，RPC 的傳輸協議可以不基於 HTTP，可以採用 TCP、UDP、HTTP、管道通訊等技術去實現
- 後端服務間呼叫 RPC 效能通常更高，因為實現更底層、封裝的資料量更小；而前端請求則通常採用 REST，因為一定要走 HTTP 協議
- 採用 REST 風格的 API，如果一旦要新增一個刪除書籍的方法，那麼 URL 地址依據不變，變化的僅是請求方法改為 DELETE；而 RPC 如果要增加這個方法，那麼必須新建一個 deleteBook(int bookId) 的方法，客戶端需要呼叫這個新方法達成功能
- 但是因為 REST 基於 HTTP 協議，因此通常會有前端代理進行請求分發，這種前端代理層的水平擴充套件不太容易；但 RPC 服務藉助註冊中心可以輕易實現服務節點的增刪和動態調整