在微服務中，使用什么協議來構建服務體系，一直是個熱門話題。 爭論的焦點集中在兩個候選技術： (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方式的微服務，則只要增加一個服務節點即可，注冊中心可自動感知到節點的變化，通知調用客戶端進行負載的動態控制，更為智能，省去運維的操作。
http://blog.lixf.cn/essay/2017/02/17/microservice-7-rpc/
https://www.zhihu.com/question/28570307