RPC基本原理

RPC很是重要，不少人面試的時候都掛在了這個地方！你要是還不懂RPC是什麼？他的基本原理是什麼？你必定要把下邊的內容記起來！好好研究一下！特別是文中給出的一張關於RPC的基本流程圖，重點中的重點，Dubbo RPC的基本執行流程就是他，RPC框架的基本原理也是他，別說我沒告訴你！看了下邊的內容你要掌握的內容以下，固然還有不少：

一、RPC的由來，是怎樣一步步演進出來的；

二、RPC的基本架構是什麼；

三、RPC的基本實現原理，就是下邊的這張圖，重點中的重點；

四、REST 和 SOAP、RPC 有何區別呢?

五、整個調用的過程經歷了哪幾步和Spring MVC的執行流程同樣，至關重要；

1、爲何要有RPC

隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已沒法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

 

 

一、單一應用架構

當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。此時，用於簡化增刪改查工做量的數據訪問框架(ORM) 是關鍵。

二、垂直應用架構

當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。

三、分佈式服務架構

當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。

此時，用於提升業務複用及整合的分佈式服務框架(RPC)，提供統一的服務是關鍵。

例如：各個團隊的服務提供方就不要各自實現一套序列化、反序列化、網絡框架、鏈接池、收發線程、超時處理、狀態機等「業務以外」的重複技術勞動，形成總體的低效。

流動計算架構

PS：這個屬於擴展內容，摘自Dubbo官網，屬於架構演進的一個過程

當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。此時，用於提升機器利用率的資源調度和治理中心(SOA)是關鍵。

四、另一個緣由

就是由於在幾個進程內（應用分佈在不一樣的機器上），沒法共用內存空間，或者在一臺機器內經過本地調用沒法完成相關的需求，好比不一樣的系統之間的通信，甚至不一樣組織之間的通信。此外因爲機器的橫向擴展，須要在多臺機器組成的集羣上部署應用等等。

因此，統一RPC框架來解決提供統一的服務。

2、什麼是RPC

RPC（Remote Procedure Call Protocol）遠程過程調用協議，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。簡言之，RPC使得程序可以像訪問本地系統資源同樣，去訪問遠端系統資源。比較關鍵的一些方面包括：通信協議、序列化、資源（接口）描述、服務框架、性能、語言支持等。

 

簡單的說，RPC就是從一臺機器(客戶端)上經過參數傳遞的方式調用另外一臺機器(服務器)上的一個函數或方法(能夠統稱爲服務)並獲得返回的結果。

 

3、PRC架構組件

一個基本的RPC架構裏面應該至少包含如下4個組件：

一、客戶端（Client）:

服務調用方（服務消費者）

二、客戶端存根（Client Stub）:

存放服務端地址信息，將客戶端的請求參數數據信息打包成網絡消息，再經過網絡傳輸發送給服務端

三、服務端存根（Server Stub）:

接收客戶端發送過來的請求消息並進行解包，而後再調用本地服務進行處理

四、服務端（Server）:

服務的真正提供者

 

具體調用過程：

一、服務消費者（client客戶端）經過調用本地服務的方式調用須要消費的服務；

二、客戶端存根（client stub）接收到調用請求後負責將方法、入參等信息序列化（組裝）成可以進行網絡傳輸的消息體；

三、客戶端存根（client stub）找到遠程的服務地址，而且將消息經過網絡發送給服務端；

四、服務端存根（server stub）收到消息後進行解碼（反序列化操做）；

五、服務端存根（server stub）根據解碼結果調用本地的服務進行相關處理；

六、本地服務執行具體業務邏輯並將處理結果返回給服務端存根（server stub）；

七、服務端存根（server stub）將返回結果從新打包成消息（序列化）並經過網絡發送至消費方；

八、客戶端存根（client stub）接收到消息，並進行解碼（反序列化）；

九、服務消費方獲得最終結果；

而RPC框架的實現目標則是將上面的第2-10步無缺地封裝起來，也就是把調用、編碼/解碼的過程給封裝起來，讓用戶感受上像調用本地服務同樣的調用遠程服務。

4、RPC和SOA、SOAP、REST的區別

一、REST

能夠看着是HTTP協議的一種直接應用，默認基於JSON做爲傳輸格式,使用簡單,學習成本低效率高,可是安全性較低。

二、SOAP

SOAP是一種數據交換協議規範,是一種輕量的、簡單的、基於XML的協議的規範。而SOAP能夠看着是一個重量級的協議，基於XML、SOAP在安全方面是經過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的,當前已經獲得了各個廠商的支持 。

三、SOA

面向服務架構，它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。服務層是SOA的基礎，能夠直接被應用調用，從而有效控制系統中與軟件代理交互的人爲依賴性。

SOA是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。SOA能夠看做是B/S模型、XML（標準通用標記語言的子集）/Web Service技術以後的天然延伸。

四、REST 和 SOAP、RPC 有何區別呢？

沒什麼太大區別，他們的本質都是提供可支持分佈式的基礎服務，最大的區別在於他們各自的的特色所帶來的不一樣應用場景 。

5、RPC框架須要解決的問題？

一、如何肯定客戶端和服務端之間的通訊協議？

二、如何更高效地進行網絡通訊？

三、服務端提供的服務如何暴露給客戶端？

四、客戶端如何發現這些暴露的服務？

五、如何更高效地對請求對象和響應結果進行序列化和反序列化操做？

6、RPC的實現基礎？

一、須要有很是高效的網絡通訊，好比通常選擇Netty做爲網絡通訊框架；

二、須要有比較高效的序列化框架，好比谷歌的Protobuf序列化框架；

三、可靠的尋址方式（主要是提供服務的發現），好比可使用Zookeeper來註冊服務等等；

四、若是是帶會話（狀態）的RPC調用，還須要有會話和狀態保持的功能；

7、RPC使用了哪些關鍵技術？

一、動態代理

生成Client Stub（客戶端存根）和Server Stub（服務端存根）的時候須要用到Java動態代理技術，可使用JDK提供的原生的動態代理機制，也可使用開源的：CGLib代理，Javassist字節碼生成技術。

二、序列化和反序列化

在網絡中，全部的數據都將會被轉化爲字節進行傳送，因此爲了可以使參數對象在網絡中進行傳輸，須要對這些參數進行序列化和反序列化操做。

序列化：把對象轉換爲字節序列的過程稱爲對象的序列化，也就是編碼的過程。

反序列化：把字節序列恢復爲對象的過程稱爲對象的反序列化，也就是解碼的過程。

目前比較高效的開源序列化框架：如Kryo、FastJson和Protobuf等。

三、NIO通訊

出於併發性能的考慮，傳統的阻塞式 IO 顯然不太合適，所以咱們須要異步的 IO，即 NIO。Java 提供了 NIO 的解決方案，Java 7 也提供了更優秀的 NIO.2 支持。能夠選擇Netty或者MINA來解決NIO數據傳輸的問題。

四、服務註冊中心

可選：Redis、Zookeeper、Consul 、Etcd。通常使用ZooKeeper提供服務註冊與發現功能，解決單點故障以及分佈式部署的問題(註冊中心)。

8、主流RPC框架有哪些

一、RMI

利用java.rmi包實現，基於Java遠程方法協議(Java Remote Method Protocol) 和java的原生序列化。

二、Hessian

是一個輕量級的remoting onhttp工具，使用簡單的方法提供了RMI的功能。基於HTTP協議，採用二進制編解碼。

三、protobuf-rpc-pro

是一個Java類庫，提供了基於 Google 的 Protocol Buffers 協議的遠程方法調用的框架。基於 Netty 底層的 NIO 技術。支持 TCP 重用/ keep-alive、SSL加密、RPC 調用取消操做、嵌入式日誌等功能。

四、Thrift

是一種可伸縮的跨語言服務的軟件框架。它擁有功能強大的代碼生成引擎，無縫地支持C + +，C#，Java，Python和PHP和Ruby。thrift容許你定義一個描述文件，描述數據類型和服務接口。依據該文件，編譯器方便地生成RPC客戶端和服務器通訊代碼。整編：微信公衆號，搜雲庫技術團隊，ID：souyunku

最初由facebook開發用作系統內個語言之間的RPC通訊，2007年由facebook貢獻到apache基金 ，如今是apache下的opensource之一 。支持多種語言之間的RPC方式的通訊：php語言client能夠構造一個對象，調用相應的服務方法來調用java語言的服務，跨越語言的C/S RPC調用。底層通信基於SOCKET。

五、Avro

出自Hadoop之父Doug Cutting, 在Thrift已經至關流行的狀況下推出Avro的目標不只是提供一套相似Thrift的通信中間件,更是要創建一個新的，標準性的雲計算的數據交換和存儲的Protocol。支持HTTP，TCP兩種協議。

六、Dubbo

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

9、RPC的實現原理架構圖

這張圖很是重點，是PRC的基本原理，請你們必定記住！

也就是說兩臺服務器A，B，一個應用部署在A服務器上，想要調用B服務器上應用提供的函數/方法，因爲不在一個內存空間，不能直接調用，須要經過網絡來表達調用的語義和傳達調用的數據。

好比說，A服務器想調用B服務器上的一個方法：

User getUserByName(String userName)

一、創建通訊

首先要解決通信的問題：即A機器想要調用B機器，首先得創建起通訊鏈接。

主要是經過在客戶端和服務器之間創建TCP鏈接，遠程過程調用的全部交換的數據都在這個鏈接裏傳輸。鏈接能夠是按需鏈接，調用結束後就斷掉，也能夠是長鏈接，多個遠程過程調用共享同一個鏈接。

一般這個鏈接能夠是按需鏈接（須要調用的時候就先創建鏈接，調用結束後就立馬斷掉），也能夠是長鏈接（客戶端和服務器創建起鏈接以後保持長期持有，無論此時有無數據包的發送，能夠配合心跳檢測機制按期檢測創建的鏈接是否存活有效），多個遠程過程調用共享同一個鏈接。

二、服務尋址

要解決尋址的問題，也就是說，A服務器上的應用怎麼告訴底層的RPC框架，如何鏈接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什麼。

一般狀況下咱們須要提供B機器（主機名或IP地址）以及特定的端口，而後指定調用的方法或者函數的名稱以及入參出參等信息，這樣才能完成服務的一個調用。

可靠的尋址方式（主要是提供服務的發現）是RPC的實現基石，好比能夠採用Redis或者Zookeeper來註冊服務等等。

2.一、從服務提供者的角度看：

2.1.一、當服務提供者啓動的時候，須要將本身提供的服務註冊到指定的註冊中心，以便服務消費者可以經過服務註冊中心進行查找；

2.1.二、當服務提供者因爲各類緣由導致提供的服務中止時，須要向註冊中心註銷中止的服務；

2.1.三、服務的提供者須要按期向服務註冊中心發送心跳檢測，服務註冊中心若是一段時間未收到來自服務提供者的心跳後，認爲該服務提供者已經中止服務，則將該服務從註冊中心上去掉

2.二、從調用者的角度看：

2.2.一、服務的調用者啓動的時候根據本身訂閱的服務向服務註冊中心查找服務提供者的地址等信息；

2.2.二、當服務調用者消費的服務上線或者下線的時候，註冊中心會告知該服務的調用者；

2.2.三、服務調用者下線的時候，則取消訂閱。

三、網絡傳輸

3.一、序列化

當A機器上的應用發起一個RPC調用時，調用方法和其入參等信息須要經過底層的網絡協議如TCP傳輸到B機器，因爲網絡協議是基於二進制的，全部咱們傳輸的參數數據都須要先進行序列化（Serialize）或者編組（marshal）成二進制的形式才能在網絡中進行傳輸。而後經過尋址操做和網絡傳輸將序列化或者編組以後的二進制數據發送給B機器。

3.二、反序列化

當B機器接收到A機器的應用發來的請求以後，又須要對接收到的參數等信息進行反序列化操做（序列化的逆操做），即將二進制信息恢復爲內存中的表達方式，而後再找到對應的方法（尋址的一部分）進行本地調用（通常是經過生成代理Proxy去調用,一般會有JDK動態代理、CGLIB動態代理、Javassist生成字節碼技術等），以後獲得調用的返回值。

四、服務調用

B機器進行本地調用（經過代理Proxy和反射調用）以後獲得了返回值，此時還須要再把返回值發送回A機器，一樣也須要通過序列化操做，而後再通過網絡傳輸將二進制數據發送回A機器，而當A機器接收到這些返回值以後，則再次進行反序列化操做，恢復爲內存中的表達方式，最後再交給A機器上的應用進行相關處理，通常是業務邏輯處理操做。

一般，通過以上四個步驟以後，一次完整的RPC調用算是完成了，另外可能由於網絡抖動等緣由須要重試等。