文章目錄

• RPC-概述
• 簡介
• 1.服務的調用過程
• 2.RPC框架
• • 1.Dubbo–電商
  • 2.Motan–互聯網
  • 3.Thrift
  • 4.gRPC
  • 5.RPCX
• 3.RPC 和 RESTful
• • 1.RPC over HTTP 和 RESTful
  • 2.RPC over TCP 和 RESTful

RPC-概述

簡介

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

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

1.服務的調用過程

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

注意：

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

調用客戶端句柄；執行傳送參數；

調用本地系統內核發送網絡消息；

消息傳送到遠程主機；

服務器句柄得到消息并取得參數；

執行遠程過程；

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

服務器句柄返回結果，調用遠程系統內核；

消息傳回本地主機；

客戶句柄由內核接收消息；

客戶接收句柄返回的數據。

2.RPC框架

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

RPC側重方向常見RPC特點缺點

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

1.Dubbo–電商

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

2.Motan–互聯網

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

3.Thrift

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

4.gRPC

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

5.RPCX

rpcx 是一個分布式的Go語言的 RPC 框架，支持Zookepper、etcd、consul多種服務發現方式，多種服務路由方式， 是目前性能最好的 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 的客戶端和服務器端是緊耦合的，客戶端需要知道調用的過程的名字，過程的參數以及它們的類型、順序等。一旦服務器更改了過程的實現，客戶端的實現很容易出問題。	RESTful基于HTTP的語義操作資源，參數的順序一般沒有關系，也很容易的通過代理轉換鏈接和資源位置，故而RESTful 更靈活。
RPC 操作的是方法和過程，要操作的是方法對象。	RESTful 操作的是資源(resource)，而不是方法。
RPC提供方法調用，如果實現一個特定目的的操作，比如為名字姓張的學生的數學成績都加上10這樣的操作，可以實現一個 Student.Increment(Name, Score) 的方法供客戶端調用。	RESTful執行的是對資源的操作，增加、查找、修改和刪除等，主要是CURD，如果實現一個特定目的的操作，比如為名字姓張的學生的數學成績都加上10這樣的操作，RESTful的API設計起來就不是那么直觀或者有意義。

2.RPC over TCP 和 RESTful

RPC over TCPRESTful

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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。