漫話：如何給女友解釋什麼是RPC

週末一大早，我正在電腦前面看新聞，忽然女友大喊起來：哇，杭州下大雪啦，快來看啊。我並無理她，因而她跑過來拉我。

雪後杭州

RPC 是Remote Procedure Call的縮寫，譯爲遠程過程調用。是一個計算機通訊協議。

爲何須要遠程調用

在如何給女友解釋什麼是分佈式這一篇文章中介紹過，爲了提高飯店的服務能力，飯店從一開始只有一個負責全部事情的廚師發展成有廚師、切菜師、備菜師等多個角色。

在飯店只有一個廚師的時候，廚師想要作出一道美味的番茄炒蛋的時候，他須要本身洗番茄、切番茄、打雞蛋、炒菜。整個過程不須要其餘人蔘與本身就徹底能夠完成了。這就是古老的集中式應用中，一臺單體計算機就能夠搞定全部事情了。

製做番茄炒蛋{
    廚師->洗菜->切菜->炒菜
}
複製代碼

隨着飯店發展，須要明確分工，讓專業的人負責專業的事兒。因此，整個作菜過程當中再也不只有廚師參與了。須要有多個角色，備菜師傅負責準備番茄和雞蛋、切菜師傅負責切菜、廚師只要負責炒菜就好了。

可是，隨着分工明確，製做番茄炒蛋的過程再也不是隻有一我的參與的過程了。這個過程當中須要多方協做。廚師準備炒菜以前，須要先通知備菜師傅和切菜師傅，前序工做準備好以後才能進行炒菜。

製做番茄炒蛋{
    備菜師->洗菜
    切菜師->切菜
    廚師->炒菜
}
複製代碼

這種狀況下，廚師就要依賴不少外人來參與這個炒菜工做。而他在通知備菜師幫他洗菜，通知切菜師傅幫他切菜的時候，這個過程就是遠程過程調用。

大多數狀況下，通常是服務員直接到廚房下單，而後後廚有一我的員分別把菜單分發給備菜師、切菜師和廚師。

這個過程就和計算機系統很像了。現在的大型網站都是分佈式部署的。拿一個下單流程來講，可能涉及到物流、支付、庫存、紅包等多個系統後，而多個系統又是分別部署在不一樣的機器上的，分別由不一樣的團隊負責。而要想實現下單流程，就須要用到遠程調用。

下單{
    庫存->減小庫存
    支付->扣款
    紅包->紅包抵用
    物流->生成物流信息
}
複製代碼

到底什麼是遠程過程調用

RPC 是指計算機 A 上的進程，調用另一臺計算機 B 上的進程，其中 A 上的調用進程被掛起，而 B 上的被調用進程開始執行，當值返回給 A 時，A 進程繼續執行。調用方能夠經過使用參數將信息傳送給被調用方，然後能夠經過傳回的結果獲得信息。而這一過程，對於開發人員來講是透明的。

就像後廚的例子同樣，服務員把菜單傳給後廚，廚師告訴備菜師和洗菜師開始工做，而後他等待他們完成工做。備菜師和洗菜師工做完以後，廚師開始炒菜。這個過程對於服務員來講實際上是透明的，他不須要關心到底後廚是怎麼作菜的。



因爲各服務部署在不一樣機器上，要想在服務間進行遠程調用免不了網絡通訊過程，服務消費方每調用一個服務都要寫一坨網絡通訊相關的代碼，不只複雜並且極易出錯。

若是有一種方式能讓咱們像調用本地服務同樣調用遠程服務，而讓調用者對網絡通訊這些細節透明，那麼將大大提升生產力，好比服務消費方在執行orderService.buy("HHKB鍵盤")時，實質上調用的是遠端的服務。這種方式其實就是RPC。而提供了這種功能的工具咱們稱之爲RPC框架。

在RPC框架中主要有三個角色：Provider、Consumer和Registry。以下圖所示：



Server: 暴露服務的服務提供方。 Client: 調用遠程服務的服務消費方。 Registry: 服務註冊與發現的註冊中心。

服務提供方和服務消費方都比較好理解，就是後廚的洗菜師和廚師啦。廚師就是服務消費方，洗菜師就是服務提供方。廚師依賴洗菜師提供的服務。

服務註冊中心又是個什麼東西呢？

其實這個也比較好理解。對於那種很大的飯店來講，廚師可能有不少（集羣部署），洗菜師也有不少（集羣部署）。而廚師想要洗菜師幫忙洗菜的時候，他不會直接找某個洗菜師，而是通知一箇中間人，這我的多是洗菜師團隊的領導，也可能就是一個專門協調後廚的人員。他知道整個廚房有多少洗菜師，也知道哪一個洗菜師今天來上班了（須要先進行服務註冊）。並且，他還能夠根據各個洗菜師的忙碌狀況動態分配任務（負載均衡）。

這個中間人就是服務註冊中心。



服務提供者啓動後主動向註冊中心註冊機器ip、port以及提供的服務列表； 服務消費者啓動時向註冊中心獲取服務提供方地址列表，可實現軟負載均衡和Failover；

實現RPC須要用到的技術

一個成熟的RPC框架須要考慮的問題有不少，這裏只介紹實現一個遠程調用須要用到的基本技術，感興趣的朋友能夠找一些開源的RPC框架代碼來看下。

動態代理

生成 client stub和server stub須要用到Java 動態代理技術，咱們可使用JDK原生的動態代理機制，可使用一些開源字節碼工具框架 如：CgLib、Javassist等。

序列化

爲了能在網絡上傳輸和接收 Java對象，咱們須要對它進行序列化和反序列化操做。

可使用Java原生的序列化機制，可是效率很是低，推薦使用一些開源的、成熟的序列化技術，例如：protobuf、Thrift、hessian、Kryo、Msgpack

NIO

當前不少RPC框架都直接基於netty這一IO通訊框架，好比阿里巴巴的HSF、dubbo，Hadoop Avro，推薦使用Netty 做爲底層通訊框架。

服務註冊中心

可選技術： Redis、Zookeeper、Consul、Etcd

參考資料 ：https://www.jianshu.com/p/dbfac2b876b1

開源RPC框架

Dubbo

Dubbo 是阿里巴巴公司開源的一個Java高性能優秀的服務框架，使得應用可經過高性能的 RPC 實現服務的輸出和輸入功能，能夠和 Spring框架無縫集成。目前已經進入Apache孵化器。

Motan

Motan是新浪微博開源的一個Java RPC框架。2016年5月開源。Motan 在微博平臺中已經普遍應用，天天爲數百個服務完成近千億次的調用。

gRPC

gRPC是Google開發的高性能、通用的開源RPC框架，其由Google主要面向移動應用開發並基於HTTP/2協議標準而設計，基於ProtoBuf(Protocol Buffers)序列化協議開發，且支持衆多開發語言。自己它不是分佈式的，因此要實現上面的框架的功能須要進一步的開發。

thrift

thrift是Apache的一個跨語言的高性能的服務框架，也獲得了普遍的應用。