從零開始的高併發（七）--- RPC的介紹，協議及框架

前言

前情概要

上一篇中咱們有簡單提到master選舉與代碼實現，官網的一些模塊劃分和它們對於以往文章主題的幫助。畢竟不能只吃官網給出來的東西，因此仍是要靠本身多找資料吧。

關於master選舉的代碼中，重點其實也就是最後經過一個線程去執行這個master的選舉，咱們在master的選舉中要不停地監聽咱們的master，在master被搶到了之後，須要對這個線程，也就是負責搶master的線程進行阻塞操做，但是若是這時候主線程阻塞了，整個程序就不跑了，因此咱們就使用了一個子線程去幫咱們去搶master，此時就算搶不到master且阻塞了該線程，也能保證整個程序能夠繼續往下執行。

瀏覽官網的順序很大程度上幫助了咱們如何去了解這個框架，保證基礎紮實的前提下，對於擴展類的知識也須要花挺多心思，好比paxos這些。對於這種知識官網就算沒法提供一個最完美的學習方案，可是也給咱們指示了方向，並且其實在不少狀況下，咱們並非理解能力薄弱，而是苦於東西太多而無從下手。在知道了存在這些東西的時候去查閱一下不少大佬們的分享，相信必定不難學會。

以往連接

從零開始的高併發（一）--- Zookeeper的基礎概念

從零開始的高併發（二）--- Zookeeper實現分佈式鎖

從零開始的高併發（三）--- Zookeeper集羣的搭建和leader選舉

從零開始的高併發（四）--- Zookeeper的分佈式隊列

從零開始的高併發（五）--- Zookeeper的配置中心應用

從零開始的高併發（六）--- Zookeeper的Master選舉及官網小覽

內容一：RPC理論

1.什麼是RPC

① RPC簡介

RPC(Remote Procedure Call Protocol)-遠程過程調用協議。經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。它假定某種傳輸協議的存在，如TCP，UDP，爲通訊程序之間攜帶信息數據。在OSI網絡通訊模型中，RPC跨越了傳輸層和應用層，因分佈式，微服務等而興起

其實簡單點來理解，就是好比有一個應用1，經過網絡調用了應用2的服務，而不用關心應用2的協議。這就是最簡單的示例。

② 爲何是遠程過程調用協議？

這裏的過程指的是業務處理，計算任務，更直白一點，就是程序，就像是在調用本地方法同樣

與本地調用的區別能夠用異地戀這個場景來理解，本地調用便是，你們同居了，都住在一塊兒，而遠程調用就像異地戀，想要見面就要不男坐車過來要不女坐車過來，並且也說異地戀通常沒有好結果。遠程調用中間須要網絡，因此咱們就能夠明白

由於是經過網絡通訊的，因此
    響應會慢上幾個數量級
    不像本地如此可靠
複製代碼

③ RPC的C/S模式

RPC採用client-server結構，經過request-response消息模式實現，若是服務器的程序進行了更新，那客戶端方面也須要同步更新才能正常使用

④ RPC的三個過程

1.通信協議：相似於在中國須要聯繫美國的朋友同樣，咱們會有多種聯繫他的方式，好比打電話，好比本身去美國等
2.尋址：咱們須要知道怎麼聯繫，好比打電話咱們須要知道電話號碼，本身去須要知道美國在哪兒這樣的，
也就是，必需要知道一個具體的地址。
3.數據序列化：序列化的做用也很簡單，好比咱們已經撥通了這個外國人的電話，或者說已經去到他面前了
可咱們說的是中文，他說英語，你們互相都聽不懂你們說話，這就無法溝通了，因此序列化其實就是一個翻譯做用
複製代碼

把這三個過程都作好以後RPC才能正常工做

⑤ 咱們爲何要使用RPC

微服務，分佈式系統架構的興起，爲了實現服務可重用或者說系統間的交互調用

⑥ RPC與其餘協議的區別

RPC和RMI的區別，RMI遠程方法調用是OOP領域中RPC的一種具體實現。也就是RPC是父，RMI是子，且RMI僅能存在Java中調用

WebService，restful接口調用其實都是RPC，只是它們的消息組織方式和消息協議不一樣而已

⑥ 與MQ的使用場景對比：

RPC就像打電話，須要一個迅速的迴應（接通或者不接通），而MQ就像發微信QQ的消息，發過去了，不急着等回

架構上它們的差別是：MQ有一箇中間節點Queue做爲消息存儲點

RPC是同步調用，對於要等待返回結果的實例，RPC處理的比較天然，因爲等待結果時Consumer會有線程消耗，
若是以異步的方式使用，能夠避免Consumer的線程消耗，
但它不能作到像MQ同樣暫存請求，壓力會堆積在服務Provider那

而MQ會把請求的壓力暫緩，讓處理者根據本身的節奏處理，可是因爲消息是暫存在了它的隊列中，
因此這個系統的可靠性會受到這個隊列的影響，它是異步單向，發送消息設計爲不須要等待消息處理的完成，
因此若是有須要設計爲同步返回的功能的話，MQ就會變得很差使用
複製代碼

因此若是是很是着急須要等待返回結果的，又或者說是但願使用方便簡單，RPC就比較好用，它的使用基於接口，相似於本地調用，異步編程會相對複雜，好比gRPC。而不但願發送端受限於處理端的速度時，就使用MQ。隨着業務增加，也會出現處理端的處理速度不夠，從而進行同步調用到異步消息的改造

2.RPC的流程及其協議

① RPC的流程

1.客戶端處理過程當中調用client stub（就像調用本地方法同樣），傳入參數
2.Client stub將參數編組爲消息，而後經過系統調用向服務端發送消息
3.客戶端本地操做系統將消息從客戶端機器發送到服務端機器
4.服務端操做系統將接收到的數據包傳遞給client stub
5.server stub解組消息爲參數
6.server stub再調用服務端的過程，過程執行結果以反方向的相同步驟響應給客戶端
複製代碼

stub：分佈式計算中的存根是一段代碼，它轉換在遠程過程調用期間Client和server之間傳遞的參數

② 整個流程中須要注意處理的問題

1.client stub和server stub的開發問題
2.參數如何編組爲消息，以及如何解組
3.消息如何發送
4.過程結果如何表示，異常狀況如何處理
5.如何實現安全的訪問控制
複製代碼

③ 核心概念術語

client和server，calls調用，replies響應，services，programs，procedures，version，Marshalling和unmarshalling編組和解組

關於services，programs，procedures，version

一個網絡服務由一個或者多個遠程程序集構成，而一個遠程程序實現一個或多個遠程過程。過程與過程參數，結果在程序協議說明書中定義說明，而爲兼容程序協議變動，一個服務端可能支持多個版本的遠程程序

④ RPC協議

RPC調用過程當中須要將參數編組爲消息進行發送，接收方須要解組消息爲參數，過程處理結果一樣須要通過編組解組。消息由哪些部分構成及消息的表示形式就構成了消息協議。RPC調用過程當中採用的消息協議成爲RPC協議

RPC是規定要作的事，RPC協議規定請求響應消息的格式，在TCP之上咱們能夠選用或自定義消息協議來完成咱們的RPC交互，此時咱們能夠選用http或者https這種通用的標準協議，也能夠根據自身的須要定義本身的消息協議（較多）

RPC框架

RPC框架封裝好了參數編組解組，底層網絡通訊的RPC程序開發框架，讓咱們能夠直接在其基礎之上只須要專一於過程代碼編寫

Java領域的比較常見的RPC框架：webService，Apache的CXF,Axis2，Java自帶的jax-ws，微服務常見的dubbo，spring cloud，Apache Thrift，ICE,google的GRPC等

① RPC框架的服務暴露

遠程提供者須要以某種形式提供服務調用相關的信息，包括但不限於服務接口定義，數據結構，或者中間態的服務定義文件，例如Thrift的IDL文件，webService的WSDL文件，服務的調用者須要經過必定的途徑或者遠程服務調用的相關信息，其實簡單點說，就是須要告訴別人怎麼調用服務

② RPC框架的遠程代理對象

代理處理技術：服務調用者用的服務實際是遠程服務的本地代理，其實就是經過動態代理來實現

Java裏至少提供了兩種方式來提供動態代碼生成，一種是jdk動態代理，另外一種是字節碼生成，動態代理相比字節碼生成使用起來更方便，但動態代理方式在性能上比字節碼要差，而字節碼生成在代碼可讀性上要差不少，因此咱們通常都是犧牲一些性能來得到代碼可讀性和可維護性的提升

③ RPC框架的通訊

RPC框架通訊和具體的協議是無關的，它可基於HTTP或TCP協議，webService就是基於http協議的RPC，具備更好的跨平臺性，但性能卻不如基於TCP協議的RPC

NIO其實不必定會比BIO性能要高，NIO只是爲了支持高併發而已，特色就是非阻塞的，適合小數據量高併發的場景，大數據包狀況下，BIO會更爲合適

④ RPC框架的序列化

兩個方面會直接影響RPC的性能，一是傳輸方式，二是序列化

Finally

這一篇全是理論，咱們簡單過了一遍RPC是什麼，三個過程，爲何咱們須要它，它的特性和適用場景，RPC的流程及協議定義還有它的框架的一些小知識。也是爲了方便下一篇上代碼的時候會比較方便闡述

下一篇:從零開始的高併發（八）--- RPC框架的簡單實現