最近上手公司一個老項目, 遇到了一個RPC服務調用失敗的問題, 由于之前只接觸過RestCilent這一種遠程服務調用的方法, 對RPC服務調用不是很了解, 所以查了一些資料, 現(xiàn)在開一個專題, 總結一下自己的學習到的東西.
RPC 是什么
RPC（Remote Procedure Call Protocol）——遠程過程調用協(xié)議，它是一種通過網(wǎng)絡從遠程計算機程序上請求服務，而不需要了解底層網(wǎng)絡技術的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發(fā)包括網(wǎng)絡分布式多程序在內的應用程序更加容易。
RPC采用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發(fā)送一個有進程參數(shù)的調用信息到服務進程，然后等待應答信息。在服務器端，進程保持睡眠狀態(tài)直到調用信息到達為止。當一個調用信息到達，服務器獲得進程參數(shù)，計算結果，發(fā)送答復信息，然后等待下一個調用信息，最后，客戶端調用進程接收答復信息，獲得進程結果，然后調用執(zhí)行繼續(xù)進行。
RPC 使用背景
隨著業(yè)務擴展, 系統(tǒng)訪問量增多, 我們會發(fā)現(xiàn)單機部署的系統(tǒng)已經(jīng)無法滿足我們的需求, 此時我們會自然而然地想到需要對業(yè)務進行拆分, 不同的模塊部署到不同的機器上去, 來劃清邏輯并且減少系統(tǒng)壓力. 這就是當下很火的微服務, 微服務雖然解決了系統(tǒng)壓力大的問題, 但是又引入了新的問題, 模塊部署在不同的機器上, 模塊與模塊之間該如何進行通信? 業(yè)界主要有兩種流行的解決方案, 一種是Spring Cloud 全家桶, 還有一種是Dubbo + Zookeeper. Spring Cloud 是一種基于Rest請求的分布式方案, 而Dubbo 則是基于RPC服務的分布式方案.
RPC 通信流程
RPC 技術要點
服務暴露
遠程提供者需要以某種形式提供服務調用相關的信息，包括但不限于服務接口定義、數(shù)據(jù)結構、或者中間態(tài)的服務定義文件。例如Facebook的Thrift的IDL文件，Web service的WSDL文件；服務的調用者需要通過一定的途徑獲取遠程服務調用相關的信息。
目前，大部分跨語言平臺 RPC 框架采用根據(jù) IDL 定義通過 code generator 去生成 stub 代碼，這種方式下實際導入的過程就是通過代碼生成器在編譯期完成的。代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對于同一語言平臺的 RPC 則可以通過共享接口定義來實現(xiàn)。這里的導入方式本質也是一種代碼生成技術，只不過是在運行時生成，比靜態(tài)編譯期的代碼生成看起來更簡潔些。
遠程代理對象
服務調用者用的服務實際是遠程服務的本地代理。本質上來說就是通過動態(tài)代理來實現(xiàn)。
java 里至少提供了兩種技術來提供動態(tài)代碼生成，一種是 jdk 動態(tài)代理，另外一種是字節(jié)碼生成。動態(tài)代理相比字節(jié)碼生成使用起來更方便，但動態(tài)代理方式在性能上是要遜色于直接的字節(jié)碼生成的，而字節(jié)碼生成在代碼可讀性上要差很多。兩者權衡起來，個人認為犧牲一些性能來獲得代碼可讀性和可維護性顯得更重要。
通信方式
RPC框架與具體的協(xié)議無關。RPC 可基于 HTTP 或 TCP 協(xié)議，Web Service 就是基于 HTTP 協(xié)議的 RPC，它具有良好的跨平臺性，但其性能和安全性卻不如基于 TCP 協(xié)議的 RPC.
TCP/HTTP：眾所周知，TCP 是傳輸層協(xié)議，HTTP 是應用層協(xié)議，而傳輸層較應用層更加底層，在數(shù)據(jù)傳輸方面，越底層越快，因此，在一般情況下，TCP 一定比 HTTP 快。
消息ID：RPC 的應用場景實質是一種可靠的請求應答消息流，和 HTTP 類似。因此選擇長連接方式的 TCP 協(xié)議會更高效，與 HTTP 不同的是在協(xié)議層面我們定義了每個消息的唯一 id，因此可以更容易的復用連接。
IO方式：為了支持高并發(fā)，傳統(tǒng)的阻塞式 IO 顯然不太合適，因此我們需要異步的 IO，即 NIO。Java 提供了 NIO 的解決方案，Java 7 也提供了更優(yōu)秀的 NIO.2 支持。
多連接：既然使用長連接，那么第一個問題是到底 client 和 server 之間需要多少根連接？實際上單連接和多連接在使用上沒有區(qū)別，對于數(shù)據(jù)傳輸量較小的應用類型，單連接基本足夠。單連接和多連接最大的區(qū)別在于，每根連接都有自己私有的發(fā)送和接收緩沖區(qū)，因此大數(shù)據(jù)量傳輸時分散在不同的連接緩沖區(qū)會得到更好的吞吐效率。所以，如果你的數(shù)據(jù)傳輸量不足以讓單連接的緩沖區(qū)一直處于飽和狀態(tài)的話，那么使用多連接并不會產(chǎn)生任何明顯的提升，反而會增加連接管理的開銷。
心跳：連接是由 client 端發(fā)起建立并維持。如果 client 和 server 之間是直連的，那么連接一般不會中斷（當然物理鏈路故障除外）。如果 client 和 server 連接經(jīng)過一些負載中轉設備，有可能連接一段時間不活躍時會被這些中間設備中斷。為了保持連接有必要定時為每個連接發(fā)送心跳數(shù)據(jù)以維持連接不中斷。心跳消息是 RPC 框架庫使用的內部消息，在前文協(xié)議頭結構中也有一個專門的心跳位，就是用來標記心跳消息的，它對業(yè)務應用透明。
序列化
兩方面會直接影響 RPC 的性能，一是傳輸方式，二是序列化。
序列化方式：畢竟是遠程通信，需要將對象轉化成二進制流進行傳輸。不同的RPC框架應用的場景不同，在序列化上也會采取不同的技術。 就序列化而言，Java 提供了默認的序列化方式，但在高并發(fā)的情況下，這種方式將會帶來一些性能上的瓶頸，于是市面上出現(xiàn)了一系列優(yōu)秀的序列化框架，比如：Protobuf、Kryo、Hessian、Jackson 等，它們可以取代 Java 默認的序列化，從而提供更高效的性能。
編碼內容：出于效率考慮，編碼的信息越少越好（傳輸數(shù)據(jù)少），編碼的規(guī)則越簡單越好（執(zhí)行效率高）
JAVA 中常見的RPC框架
目前常用的RPC框架如下：
Thrift：thrift是一個軟件框架，用來進行可擴展且跨語言的服務的開發(fā)。它結合了功能強大的軟件堆棧和代碼生成引擎，以構建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語言間無縫結合的、高效的服務。
Dubbo：Dubbo是一個分布式服務框架，以及SOA治理方案。其功能主要包括：高性能NIO通訊及多協(xié)議集成，服務動態(tài)尋址與路由，軟負載均衡與容錯，依賴分析與降級等。 Dubbo是阿里巴巴內部的SOA服務化治理方案的核心框架，Dubbo自2011年開源后，已被許多非阿里系公司使用。
Spring Cloud：Spring Cloud由眾多子項目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系統(tǒng)及微服務常用的工具，如配置管理、服務發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、一次性token、全局鎖、選主、分布式會話和集群狀態(tài)等，滿足了構建微服務所需的所有解決方案。Spring Cloud基于Spring Boot, 使得開發(fā)部署極其簡單。
本篇文章參考博主Zenhobby的RPC入門總結（一）RPC定義和原理所寫, 感謝博主的分享
