1.深入淺出瞭解RPC與RestFul
1.首先了解一下restful API
詳細講解如下：
http://www.runoob.com/w3cnote/restful-architecture.html
REST全稱是Representational State Transfer，中文意思是表述性狀態轉移。符合架構原理的前提下，理解和評估以網路為基礎的應用軟體的架構設計，得到一個功能好，效能好，適宜通訊的架構。
如果一個架構符合REST的約束條件和原則，我們就稱它為RESTful架構。
其根本就是使用web現有的特徵和能力。
（1）資源與URI
(2)統一資源介面
（3）資源的表述
（4）資源的連線
（5）狀態的轉移
2.針對restful與RPC的對比實踐；
在微服務中，使用什麼協議來構建服務體系，一直是個熱門話題。 爭論的焦點集中在兩個候選技術： (binary) RPC or Restful。
-
以Apache Thrift為代表的二進位制RPC，支援多種語言（但不是所有語言），四層通訊協議，效能高，節省頻寬。相對Restful協議，使用Thrifpt RPC，在同等硬體條件下，頻寬使用率僅為前者的20%，效能卻提升一個數量級。但是這種協議最大的問題在於，無法穿透防火牆。
-
以Spring Cloud為代表所支援的Restful 協議，優勢在於能夠穿透防火牆，使用方便，語言無關，基本上可以使用各種開發語言實現的系統，都可以接受Restful 的請求。 但效能和頻寬佔用上有劣勢。
所以，業內對微服務的實現，基本是確定一個組織邊界，在該邊界內，使用RPC; 邊界外，使用Restful。這個邊界，可以是業務、部門，甚至是全公司。
使用RPC遠端服務呼叫方式與傳統http介面直接呼叫方式的差別在於：
1. 從使用方面看，Http介面只關注服務提供方，對於客戶端怎麼呼叫，呼叫方式怎樣並不關心，通常情況下，我們使用Http方式進行呼叫時，只要將內容進行傳輸即可，這樣客戶端在使用時，需要更關注網路方面的傳輸，比較不適用與業務方面的開發；而RPC服務則需要客戶端介面與服務端保持一致，服務端提供一個方法，客戶端通過介面直接發起呼叫，業務開發人員僅需要關注業務方法的呼叫即可，不再關注網路傳輸的細節，在開發上更為高效。
2. 從效能角度看，使用Http時，Http本身提供了豐富的狀態功能與擴充套件功能，但也正由於Http提供的功能過多，導致在網路傳輸時，需要攜帶的資訊更多，從效能角度上講，較為低效。而RPC服務網路傳輸上僅傳輸與業務內容相關的資料，傳輸資料更小，效能更高。
3. 從運維角度看，使用Http介面時，常常使用一個前端代理，來進行Http轉發代理請求的操作，需要進行擴容時，則需要去修改代理伺服器的配置，較為繁瑣，也容易出錯。而使用RPC方式的微服務，則只要增加一個服務節點即可，註冊中心可自動感知到節點的變化，通知呼叫客戶端進行負載的動態控制，更為智慧，省去運維的操作。