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