微服務 Rpc和Rest協議

介面呼叫通常包含兩個部分，序列化和通訊協議。常見的序列化協議包括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則會有很多約束

微服務 Rpc和Rest協議

微服務 Rpc和Rest協議

微服務 Rpc和Rest協議

Rpc和Rest介面，微服務之Rpc

相關推薦