文章目錄

• RPC-概述
• 簡介
• 1.服務的調(diào)用過程
• 2.RPC框架
• • 1.Dubbo–電商
  • 2.Motan–互聯(lián)網(wǎng)
  • 3.Thrift
  • 4.gRPC
  • 5.RPCX
• 3.RPC 和 RESTful
• • 1.RPC over HTTP 和 RESTful
  • 2.RPC over TCP 和 RESTful

RPC-概述

簡介

遠程過程調(diào)用（Remote Procedure Call，縮寫為 RPC）是一個計算機通信協(xié)議。
該協(xié)議允許運行于一臺計算機的程序調(diào)用另一臺計算機的子程序，而程序員無需額外地為這個交互作用編程。
遠程過程調(diào)用是一個分布式計算的客戶端-服務器（Client/Server） ，簡單而又廣受歡迎。
遠程過程調(diào)用總是由客戶端對服務器發(fā)出一個執(zhí)行若干過程請求，并用客戶端提供的參數(shù)。執(zhí)行結果將返回給客戶端。
類似遠程訪問或者web請求差不多，都是一個client向遠端服務器請求服務返回結果，但是web請求使用的網(wǎng)絡協(xié)議是http高層協(xié)議，而rpc所使用的協(xié)議多為TCP，是網(wǎng)絡層協(xié)議，減少了信息的包裝，加快了處理速度。
由于存在各式各樣的變體和細節(jié)差異，對應地派生了各式遠程過程調(diào)用協(xié)議，而且它們并不互相兼容。為了允許不同的客戶端均能訪問服務器，許多標準化的 RPC 系統(tǒng)應運而生了。其中大部分采用接口描述語言（Interface Description Language，IDL），方便跨平臺的遠程過程調(diào)用。

RPC 本身是 client-server模型，也是一種request-response 協(xié)議【請求-應答】。

1.服務的調(diào)用過程

• 1.client調(diào)用client stub，這是一次本地過程調(diào)用
• 2.client stub將參數(shù)打包成一個消息，然后發(fā)送這個消息。打包過程也叫做 marshalling
• 3.client所在的系統(tǒng)將消息發(fā)送給server
• 4.server的的系統(tǒng)將收到的包傳給server stub
• 5.server stub解包得到參數(shù)。 解包也被稱作 unmarshalling
• 6.最后server stub調(diào)用服務過程. 返回結果按照相反的步驟傳給client

注意：

• 客戶端（Client）： 服務的調(diào)用方
• 服務端（Server）：真正的服務提供者
• 客戶端存根（client stub）：存放服務端的地址消息，再將客戶端的請求參數(shù)打包成網(wǎng)絡消息，然后通過網(wǎng)絡遠程發(fā)送給服務方
• 服務端存根（server stub）：接收客戶端發(fā)送過來的消息，將消息解包，并調(diào)用本地的方法

調(diào)用客戶端句柄；執(zhí)行傳送參數(shù)；

調(diào)用本地系統(tǒng)內(nèi)核發(fā)送網(wǎng)絡消息；

消息傳送到遠程主機；

服務器句柄得到消息并取得參數(shù)；

執(zhí)行遠程過程；

執(zhí)行的過程將結果返回服務器句柄；

服務器句柄返回結果，調(diào)用遠程系統(tǒng)內(nèi)核；

消息傳回本地主機；

客戶句柄由內(nèi)核接收消息；

客戶接收句柄返回的數(shù)據(jù)。

2.RPC框架

RPC只是描繪了 Client 與 Server 之間的點對點調(diào)用流程，包括 stub（存根）、通信、RPC 消息解析等部分，在實際應用中，還需要考慮服務的高可用、負載均衡等問題，所以產(chǎn)品級的 RPC 框架除了點對點的 RPC 協(xié)議的具體實現(xiàn)外，還應包括服務的發(fā)現(xiàn)與注銷、提供服務的多臺Server 的負載均衡、服務的高可用等更多的功能。
目前的 RPC 框架大致有兩種不同的側(cè)重方向，一種偏重于服務治理，另一種偏重于跨語言調(diào)用。

RPC側(cè)重方向常見RPC特點缺點

服務治理型RPC	Alibab Dubbo、Motan 等	功能豐富，提供高性能的遠程調(diào)用以及服務發(fā)現(xiàn)和治理功能，適用于大型服務的微服務化拆分以及管理，對于特定語言（Java）的項目可以十分友好的透明化接入。	語言耦合度較高，跨語言支持難度較大。
跨語言調(diào)用型RCP	Thrift、gRPC、rpcx等	關注于服務的跨語言調(diào)用，能夠支持大部分的語言進行語言無關的調(diào)用，非常適合于為不同語言提供通用遠程服務的場景 。	沒有服務發(fā)現(xiàn)相關機制，實際使用時一般需要代理層進行請求轉(zhuǎn)發(fā)和負載均衡策略控制。

1.Dubbo–電商

Dubbo 是阿里巴巴公司開源的一個Java高性能優(yōu)秀的服務框架，使得應用可通過高性能的 RPC 實現(xiàn)服務的輸出和輸入功能，可以和 Spring框架無縫集成。Dubbo由于跟淘寶另一個類似的框架HSF（非開源）有競爭關系，導致dubbo團隊已經(jīng)解散；在電商圈如當當 (dubbox)、京東、國美維護了自己的分支或者在dubbo的基礎開發(fā)，但是官方的實現(xiàn)缺乏維護，其它電商雖然維護了自己的版本，但是還是不能做大的架構的改動和提升，相關的依賴類比如Spring，Netty還是很老的版本(Spring 3.2.16.RELEASE, netty3.2.5.Final)，而且Dubbo的代碼結構過于復雜。

2.Motan–互聯(lián)網(wǎng)

Motan是新浪微博開源的一個Java 框架。它誕生的比較晚，起于2013年，2016年5月開源。Motan 在微博平臺中已經(jīng)廣泛應用，每天為數(shù)百個服務完成近千億次的調(diào)用。Motan的架構相對簡單，功能也能滿足微博內(nèi)部架構的要求,雖然Motan的架構的目的主要不是跨語言，但是目前也在開發(fā)支持php client和C server特性。

3.Thrift

Thrift是Apache的一個跨語言的高性能的服務框架，也得到了廣泛的應用。它的功能類似 gRPC, 支持跨語言，不支持服務治理。

4.gRPC

gRPC是Google開發(fā)的高性能、通用的開源RPC框架，其由Google主要面向移動應用開發(fā)并基于HTTP/2協(xié)議標準而設計，基于ProtoBuf(Protocol Buffers)序列化協(xié)議開發(fā)，且支持眾多開發(fā)語言。目標是跨語言開發(fā)，支持多種語言， 服務治理方面需要自行實現(xiàn)，所以實現(xiàn)一個綜合的產(chǎn)品級的分布式RPC平臺還需要擴展開發(fā)，Google內(nèi)部使用的也不是gRPC，而是Stubby。

5.RPCX

rpcx 是一個分布式的Go語言的 RPC 框架，支持Zookepper、etcd、consul多種服務發(fā)現(xiàn)方式，多種服務路由方式， 是目前性能最好的 RPC 框架之一。

3.RPC 和 RESTful

RPC 的消息傳輸可以通過 TCP、UDP 或者 HTTP等，所以稱之為 RPC over TCP、 RPC over HTTP。RPC 通過 HTTP 傳輸消息的時候和 RESTful的架構是類似的，但也有不同。

1.RPC over HTTP 和 RESTful

RPC over HTTPRESTful

RPC 的客戶端和服務器端是緊耦合的，客戶端需要知道調(diào)用的過程的名字，過程的參數(shù)以及它們的類型、順序等。一旦服務器更改了過程的實現(xiàn)，客戶端的實現(xiàn)很容易出問題。	RESTful基于HTTP的語義操作資源，參數(shù)的順序一般沒有關系，也很容易的通過代理轉(zhuǎn)換鏈接和資源位置，故而RESTful 更靈活。
RPC 操作的是方法和過程，要操作的是方法對象。	RESTful 操作的是資源(resource)，而不是方法。
RPC提供方法調(diào)用，如果實現(xiàn)一個特定目的的操作，比如為名字姓張的學生的數(shù)學成績都加上10這樣的操作，可以實現(xiàn)一個 Student.Increment(Name, Score) 的方法供客戶端調(diào)用。	RESTful執(zhí)行的是對資源的操作，增加、查找、修改和刪除等，主要是CURD，如果實現(xiàn)一個特定目的的操作，比如為名字姓張的學生的數(shù)學成績都加上10這樣的操作，RESTful的API設計起來就不是那么直觀或者有意義。

2.RPC over TCP 和 RESTful

RPC over TCPRESTful

通過長連接減少建立簡介產(chǎn)生的資源消耗，高并發(fā)場合愈發(fā)重要。	通過在請求頭中設置Connection: keep-alive實現(xiàn)長連接**，request-response模型阻塞嚴重，必須等前一個請求發(fā)送并完成響應后，才能發(fā)送后續(xù)請求，即使在HTTP1.1中使用了Pipeline管線化技術，依然是一個串行化的方案，且服務器端開啟Pipeline管線化很可能并不會帶來大幅度的性能提升，而且服務器端和代理程序?qū)芫€化的支持并不好，非標配，除非升級到HTTP2， RPC的實現(xiàn)沒有這個限制。
采用TCP通訊協(xié)議，是傳輸層的通信協(xié)議，效率和性能高于應用層協(xié)議，普遍用于微服務架構的服務之間的通訊	RESTful基于HTTP，是應用層協(xié)議，基于傳輸層協(xié)議之上，效率和性能比傳輸層的協(xié)議要低

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的RPC(一)[概述]的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。