原文：https://blog.csdn.net/king866/article/details/54174665
接口調用通常包含兩個部分，序列化和通信協議。常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等；通信比較流行的是http、soap、websockect，RPC通常基於TCP實現，常用框架例如dubbo，netty、mina、thrift
首先解釋下兩種接口調用：
Rest：嚴格意義上說接口很規范，操作對象即為資源，對資源的四種操作（post、get、put、delete），並且參數都放在URL上,但是不嚴格的說Http+json、Http+xml，常見的http api都可以稱為Rest接口。
Rpc：我們常說的遠程方法調用，就是像調用本地方法一樣調用遠程方法，通信協議大多采用二進制方式
http vs 高性能二進制協議
http相對更規范，更標准，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平台，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，相應的，如果采用http，無疑在你實現SDK之前，支持了所有語言，所以，現在開源中間件，基本最先支持的幾個協議都包含RESTful。
RPC協議性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能達到http的二倍。響應時間也更為出色。千萬不要小看這點性能損耗，公認的，微服務做的比較好的，例如，netflix、阿里，曾經都傳出過為了提升性能而合並服務。如果是交付型的項目，性能更為重要，因為你賣給客戶往往靠的就是性能上微弱的優勢。RESTful
你可以看看，無論是Google、Amazon、netflix（據說很可能轉向grpc），還是阿里，實際上內部都是采用性能更高的RPC方式。而對外開放的才是RESTful。
Rest 調用及測試都很方便，Rpc就顯得有點麻煩，但是Rpc的效率是毋庸置疑的，所以建議在多系統之間采用Rpc，對外提供服務，Rest是很適合的
duboo在生產者和消費者兩個微服務之間的通信采用的就是Rpc,無疑在服務之間的調用Rpc更變現的優秀
Rpc在微服務中的利用
1、 RPC 框架是架構微服務化的首要基礎組件 ，它能大大降低架構微服務化的成本，提高調用方與服務提供方的研發效率，屏蔽跨進程調用函數（服務）的各類復雜細節
2、 RPC 框架的 職責 是： 讓調用方感覺就像調用本地函數一樣調用遠端函數、讓服務提供方感覺就像實現一個本地函數一樣來實現服務
RPC的好處：
RPC 的主要功能目標是讓構建分布式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。 為實現該目標，RPC 框架需提供一種透明調用機制讓使用者不必顯式的區分本地調用和遠程調用。
服務化的一個好處就是，不限定服務的提供方使用什么技術選型，能夠實現大公司跨團隊的技術解耦。
如果沒有統一的服務框架，RPC框架，各個團隊的服務提供方就需要各自實現一套序列化、反序列化、網絡框架、連接池、收發線程、超時處理、狀態機等“業務之外”的重復技術勞動，造成整體的低效。所以，統一RPC框架把上述“業務之外”的技術勞動統一處理，是服務化首要解決的問題
幾種協議
Socket使用時可以指定協議Tcp,Udp等；
RIM使用Jrmp協議，Jrmp又是基於TCP/IP；
RPC底層使用Socket接口，定義了一套遠程調用方法；
HTTP是建立在TCP上，不是使用Socket接口，需要連接方主動發數據給服務器，服務器無法主動發數據個客戶端；
Web Service提供的服務是基於web容器的，底層使用http協議，類似一個遠程的服務提供者，比如天氣預報服務，對各地客戶端提供天氣預報，是一種請求應答的機制，是跨系統跨平台的。就是通過一個servlet，提供服務出去。
hessian是一套用於建立web service的簡單的二進制協議，用於替代基於XML的web service，是建立在rpc上的，hessian有一套自己的序列化格式將數據序列化成流，然后通過http協議發送給服務器
在微服務架構中，各個服務之間可能千差萬別，rest接口更加靈活，如果使用RPC則會有很多約束