轉(zhuǎn)自：https://www.cnblogs.com/111testing/p/11296880.html

什么是 RPC 框架

RPC 框架----- 遠(yuǎn)程過(guò)程調(diào)用協(xié)議RPC（Remote Procedure Call Protocol)-----允許像調(diào)用本地服務(wù)一樣調(diào)用遠(yuǎn)程服務(wù),。

RPC是指遠(yuǎn)程過(guò)程調(diào)用,，也就是說(shuō)兩臺(tái)服務(wù)器A，B,，一個(gè)應(yīng)用部署在A服務(wù)器上,，想要調(diào)用B服務(wù)器上應(yīng)用提供的函數(shù)/方法，由于不在一個(gè)內(nèi)存空間,，不能直接調(diào)用,，需要通過(guò)網(wǎng)絡(luò)來(lái)表達(dá)調(diào)用的語(yǔ)義和傳達(dá)調(diào)用的數(shù)據(jù)。比如說(shuō),，一個(gè)方法可能是這樣定義的： 
Employee getEmployeeByName(String fullName)那么：

第一,，首先,，要解決通訊的問題，主要是通過(guò)在客戶端和服務(wù)器之間建立TCP連接（socket）,，遠(yuǎn)程過(guò)程調(diào)用的所有交換的數(shù)據(jù)都在這個(gè)連接里傳輸,。連接可以是按需連接，調(diào)用結(jié)束后就斷掉,，也可以是長(zhǎng)連接,，多個(gè)遠(yuǎn)程過(guò)程調(diào)用共享同一個(gè)連接。

第二,，要解決尋址的問題,，也就是說(shuō)，A服務(wù)器上的應(yīng)用怎么告訴底層的RPC框架,，如何連接到B服務(wù)器（如主機(jī)或IP地址）以及特定的端口,，方法的名稱名稱是什么，這樣才能完成調(diào)用,。比如基于Web服務(wù)協(xié)議棧的RPC,，就要提供一個(gè)endpoint URI，或者是從UDDI服務(wù)上查找,。如果是RMI調(diào)用的話,，還需要一個(gè)RMI Registry來(lái)注冊(cè)服務(wù)的地址。

第三,，當(dāng)A服務(wù)器上的應(yīng)用發(fā)起遠(yuǎn)程過(guò)程調(diào)用時(shí),，方法的參數(shù)需要通過(guò)底層的網(wǎng)絡(luò)協(xié)議如TCP傳遞到B服務(wù)器，由于網(wǎng)絡(luò)協(xié)議是基于二進(jìn)制的,，內(nèi)存中的參數(shù)的值要序列化成二進(jìn)制的形式,，也就是序列化（Serialize）或編組（marshal），通過(guò)尋址和傳輸將序列化的二進(jìn)制發(fā)送給B服務(wù)器,。

第四,，B服務(wù)器收到請(qǐng)求后,，需要對(duì)參數(shù)進(jìn)行反序列化（序列化的逆操作）,，恢復(fù)為內(nèi)存中的表達(dá)方式，然后找到對(duì)應(yīng)的方法（尋址的一部分）進(jìn)行本地調(diào)用,，然后得到返回值,。

第五，返回值還要發(fā)送回服務(wù)器A上的應(yīng)用,，也要經(jīng)過(guò)序列化的方式發(fā)送,，服務(wù)器A接到后，再反序列化,，恢復(fù)為內(nèi)存中的表達(dá)方式,，交給A服務(wù)器上的應(yīng)用

總的來(lái)說(shuō)可以歸納為以下幾步：

 1,，遠(yuǎn)程服務(wù)之間建立通訊協(xié)議

2，尋址：服務(wù)器（如主機(jī)或IP地址）以及特定的端口,，方法的名稱名稱是什么

3,，通過(guò)序列化和反序列化進(jìn)行數(shù)據(jù)傳遞

4，將傳遞過(guò)來(lái)的數(shù)據(jù)通過(guò)java反射原理定位接口方法和參數(shù)

5,，暴露服務(wù)：用map將尋址的信息暴露給遠(yuǎn)方服務(wù)（提供一個(gè)endpoint URI或者一個(gè)前端展示頁(yè)面）

 6,，多線程并發(fā)請(qǐng)求業(yè)務(wù)

什么是RPC

提到RPC（Remote Procedure Call），就躲不開提到分布式,，這個(gè)促使RPC誕生的領(lǐng)域,。

假設(shè)你有一個(gè)Calculator，以及它的實(shí)現(xiàn)類CalculatorImpl,，那么單體應(yīng)用時(shí),，要調(diào)用Calculator的add方法來(lái)執(zhí)行一個(gè)加運(yùn)算，你可以方法中直接使用,，因?yàn)樵谕粋€(gè)地址空間,，或者說(shuō)在同一塊內(nèi)存，這個(gè)稱為本地函數(shù)調(diào)用,。

現(xiàn)在,，將系統(tǒng)改造為分布式應(yīng)用，接口調(diào)用和實(shí)現(xiàn)分別在兩個(gè)子系統(tǒng)內(nèi),，

服務(wù)A里頭并沒有CalculatorImpl這個(gè)類,，那它要怎樣調(diào)用服務(wù)B的CalculatorImpl的add方法呢？可以模仿B/S架構(gòu)的調(diào)用方式,，在B服務(wù)暴露一個(gè)Restful接口,，然后A服務(wù)通過(guò)調(diào)用這個(gè)Restful接口來(lái)間接調(diào)用CalculatorImpl的add方法。

這樣,，已經(jīng)很接近RPC了,，不過(guò)，像這種每次調(diào)用時(shí),，是不是都需要寫一串發(fā)起http請(qǐng)求的代碼呢,？比如httpClient.sendRequest...之類的，能不能簡(jiǎn)單一下,，像本地方法調(diào)用一樣,，去發(fā)起遠(yuǎn)程調(diào)用，讓使用者感知不到遠(yuǎn)程調(diào)用的過(guò)程,。

屏蔽的工作,，可以使用代理模式解決，生成一個(gè)代理對(duì)象,，而這個(gè)代理對(duì)象的內(nèi)部,，就是通過(guò)httpClient來(lái)實(shí)現(xiàn)RPC遠(yuǎn)程過(guò)程調(diào)用的,。

這就是很多RPC框架要解決的問題和解決的思路，比如阿里的Dubbo,。

總結(jié)一下,，RPC要解決的兩個(gè)問題：

1. 解決分布式系統(tǒng)中，服務(wù)之間的調(diào)用問題,。

2. 遠(yuǎn)程調(diào)用時(shí),，要能夠像本地調(diào)用一樣方便，讓調(diào)用者感知不到遠(yuǎn)程調(diào)用的邏輯,。

RPC是一種技術(shù)的概念名詞

RPC=Remote Produce Call 是一種技術(shù)的概念名詞,，HTTP是一種協(xié)議,RPC可以通過(guò) HTTP 來(lái)實(shí)現(xiàn),也可以通過(guò)Socket自己實(shí)現(xiàn)一套協(xié)議來(lái)實(shí)現(xiàn).所以題目可以換一種理解,為何 RPC 還有除 HTTP 之外的實(shí)現(xiàn)法,有何必要，畢竟除了HTTP實(shí)現(xiàn)外,私有協(xié)議不具備通用性.

RPC框架好處

http接口是在接口不多,、系統(tǒng)與系統(tǒng)交互較少的情況下,，解決信息孤島初期常使用的一種通信手段；

優(yōu)點(diǎn)就是簡(jiǎn)單,、直接,、開發(fā)方便。

如果是一個(gè)大型的網(wǎng)站,，內(nèi)部子系統(tǒng)較多,、接口非常多的情況下，RPC框架的好處就顯示出來(lái)了：

首先就是長(zhǎng)鏈接,，不必每次通信都要像http一樣去3次握手什么的,，減少了網(wǎng)絡(luò)開銷；

其次就是RPC框架一般都有注冊(cè)中心,，有豐富的監(jiān)控管理,；發(fā)布、下線接口,、動(dòng)態(tài)擴(kuò)展等,，對(duì)調(diào)用方來(lái)說(shuō)是無(wú)感知、統(tǒng)一化的操作,。

最后是安全性,。

rpc是一種概念，http也是rpc實(shí)現(xiàn)的一種方式,。

論復(fù)雜度,，dubbo/hessian用起來(lái)是超級(jí)簡(jiǎn)單的。

至于為什么用dubbo/hessian,，有幾點(diǎn)：

一是調(diào)用簡(jiǎn)單，真正提供了類似于調(diào)用本地方法一樣調(diào)用接口的功能 ,。

二是參數(shù)返回值簡(jiǎn)單明了 參數(shù)和返回值都是直接定義在jar包里的,，不需要二次解析,。

三是 輕量，沒有多余的信息,。

四是便于管理,，基于dubbo的注冊(cè)中心。

RPC能解耦服務(wù)

RPC:遠(yuǎn)程過(guò)程調(diào)用,。RPC的核心并不在于使用什么協(xié)議,。RPC的目的是讓你在本地調(diào)用遠(yuǎn)程的方法，而對(duì)你來(lái)說(shuō)這個(gè)調(diào)用是透明的,，你并不知道這個(gè)調(diào)用的方法是部署哪里,。

通過(guò)RPC能解耦服務(wù)，這才是使用RPC的真正目的,。RPC的原理主要用到了動(dòng)態(tài)代理模式,，至于http協(xié)議，只是傳輸協(xié)議而已,。簡(jiǎn)單的實(shí)現(xiàn)可以參考spring remoting,，復(fù)雜的實(shí)現(xiàn)可以參考dubbo。

rpc=socket + 動(dòng)態(tài)代理

服務(wù)器通訊原理就是一臺(tái)socket服務(wù)器A,另一臺(tái)socket客戶端B,現(xiàn)在如果要通訊的話直接以流方式寫入或讀出,。這樣能實(shí)現(xiàn)通訊,，但有個(gè)問題。如何知道更多信息,？

比如需要發(fā)送流大小,，編碼，Ip等,。這樣就有了協(xié)議,，協(xié)議就是規(guī)范，就是發(fā)送的流中攜帶了很多的內(nèi)容,。那回到剛剛的問題,。發(fā)送的內(nèi)容就是文本類型，客戶端就得序列化,，那么常用的就有json,，xml之類，如果想把內(nèi)容變得更小,，那就有二進(jìn)制了,。把文本變成二進(jìn)制傳遞。

說(shuō)到 rpc 與http接口,，不要太復(fù)雜了,。rpc 協(xié)議更簡(jiǎn)單內(nèi)容更小，那么來(lái)說(shuō)效率是要高一點(diǎn)

rpc 是什么？就是socket 加動(dòng)態(tài)代理,。

總結(jié)

學(xué)技術(shù)應(yīng)該是知其然知其所以然,，我們得明白什么場(chǎng)景，或者什么業(yè)務(wù)需要它,，它能解決其他技術(shù)不能解決或者不方便解決的問題,。

RPC是一個(gè)軟件結(jié)構(gòu)概念，是構(gòu)建分布式應(yīng)用的理論基礎(chǔ),。就好比為啥你家可以用到發(fā)電廠發(fā)出來(lái)的電,？是因?yàn)殡娛强梢詡鬏數(shù)摹Ｖ劣谟勉~線還是用鐵絲還是其他種類的導(dǎo)線,，也就是用http還是用其他協(xié)議的問題了,。這個(gè)要看什么場(chǎng)景，對(duì)性能要求怎么樣,。

在java中的最基本的就是RMI技術(shù),，它是java原生的應(yīng)用層分布式技術(shù)。我們可以肯定的是在傳輸性能方面,，RMI的性能是優(yōu)于HTTP的,。

那為啥很少用到這個(gè)技術(shù)？那是因?yàn)橛眠@個(gè)有很多局限性,，首先它要保證傳輸?shù)膬啥硕家胘ava實(shí)現(xiàn),，且兩邊需要有相同的對(duì)象類型和代理接口，不需要容器,，但是加大了編程的難度,，在應(yīng)用內(nèi)部的各個(gè)子系統(tǒng)之間還是會(huì)看到他的身影，比如EJB就是基于rmi技術(shù)的,。

這就與目前的bs架構(gòu)的軟件大相徑庭,。用http必須要服務(wù)端位于http容器里面，這樣減少了網(wǎng)絡(luò)傳輸方面的開發(fā),，只需要關(guān)注業(yè)務(wù)開發(fā)即可,。所以在架構(gòu)一個(gè)軟件的時(shí)候，不能一定根據(jù)需求選定技術(shù),。