摘要：一旦有一方改變，要及時(shí)通知對(duì)方，否則就會(huì)出現(xiàn)問(wèn)題。對(duì)于，主要處理高性能的傳輸，以及網(wǎng)絡(luò)的錯(cuò)誤和異常。這個(gè)框架是在協(xié)議中使用的。就是網(wǎng)絡(luò)文件系統(tǒng)。唯一標(biāo)識(shí)請(qǐng)求和回復(fù)。

【前五篇】系列文章傳送門：

網(wǎng)絡(luò)協(xié)議 14 - 流媒體協(xié)議：要說(shuō)愛(ài)你不容易

網(wǎng)絡(luò)協(xié)議 15 - P2P 協(xié)議：小種子大學(xué)問(wèn)

網(wǎng)絡(luò)協(xié)議 16 - DNS 協(xié)議：網(wǎng)絡(luò)世界的地址簿

網(wǎng)絡(luò)協(xié)議 17 - HTTPDNS：私人定制的 DNS 服務(wù)

網(wǎng)絡(luò)協(xié)議 18 - CDN：家門口的小賣鋪

????這幾年微服務(wù)很火，想必各位博友或多或少的都接觸過(guò)。微服務(wù)概念中，
各服務(wù)間的相互調(diào)用是不可或缺的一環(huán)。你知道微服務(wù)之間是通過(guò)什么方式相互調(diào)用的嗎？

????你可能說(shuō)，這還不簡(jiǎn)單，用 socket 唄。服務(wù)之間分調(diào)用方和被調(diào)用方，我們就建立一個(gè) TCP 或者 UDP 連接進(jìn)行通信就好了。

????說(shuō)著說(shuō)著，你可能就會(huì)發(fā)現(xiàn)，這事兒沒(méi)那么簡(jiǎn)單。

????我們就拿最簡(jiǎn)單的場(chǎng)景：

客戶端調(diào)用一個(gè)加法函數(shù)，將兩個(gè)整數(shù)加起來(lái)，返回它們的和。

????如果放在本地調(diào)用，那是簡(jiǎn)單的不能再簡(jiǎn)單，但是一旦變成了遠(yuǎn)程調(diào)用，門檻一下子就上去了。

????首先，你要會(huì) socket 編程，至少要先了解咱們這個(gè)系列的所有協(xié)議 ，然后再看 N 本磚頭厚的 socket 程序設(shè)計(jì)的書(shū)，學(xué)會(huì)咱們了解過(guò)的幾種 socket 程序設(shè)計(jì)的模型。

????這就使得本來(lái)大學(xué)畢業(yè)就能干的一項(xiàng)工作，變成了一件五年工作經(jīng)驗(yàn)都不一定干好的工作，而且，搞定了 socket 程序設(shè)計(jì)，才是萬(wàn)里長(zhǎng)征的第一步，后面還有很多問(wèn)題呢。

問(wèn)題一：如何規(guī)定遠(yuǎn)程調(diào)用的語(yǔ)法？
????客戶端如何告訴服務(wù)端，我是一個(gè)加法，而另一個(gè)是減法。是用字符串 “add” 傳給你，還是傳給你一個(gè)整數(shù)，比如 1 表示加法，2 表示減法？

????服務(wù)端又該如果告訴客戶端，我這個(gè)是加法，目前只能加整數(shù)，不能加小數(shù)和字符串。而另一個(gè)加法 “add1”，它能實(shí)現(xiàn)小數(shù)和整數(shù)的混合加法，那返回值是什么？正確的時(shí)候返回什么，錯(cuò)誤的時(shí)候又返回什么？

問(wèn)題二：如何傳遞參數(shù)？
????是先傳兩個(gè)整數(shù)，后傳一個(gè)操作數(shù) “add”，還是先傳操作符，再傳兩個(gè)整數(shù)？

????另外，如果我們是用 UDP 傳輸，把參數(shù)放在一個(gè)報(bào)文里還好，但如果是 TCP，是一個(gè)流，在這個(gè)流里面如何區(qū)分前后兩次調(diào)用？

問(wèn)題三：如何表示數(shù)據(jù)？
????在我們的加法例子中，傳遞的就是一個(gè)固定長(zhǎng)度的 int 值，這種情況還好，如果是變長(zhǎng)的類型，是一個(gè)結(jié)構(gòu)體，甚至是一個(gè)類，應(yīng)該怎么辦呢？即使是 int，在不同的平臺(tái)上長(zhǎng)度也不同，該怎么辦呢？

問(wèn)題四：如何知道一個(gè)服務(wù)端都實(shí)現(xiàn)了哪些遠(yuǎn)程調(diào)用？從哪個(gè)端口可以訪問(wèn)這個(gè)遠(yuǎn)程調(diào)用？
????假設(shè)服務(wù)端實(shí)現(xiàn)了多個(gè)遠(yuǎn)程調(diào)用，每個(gè)實(shí)現(xiàn)可能都不在一個(gè)進(jìn)程中，監(jiān)聽(tīng)的端口也不一樣，而且由于服務(wù)端都是自己實(shí)現(xiàn)的，不可能使用一個(gè)大家都公認(rèn)的端口，而且有可能多個(gè)進(jìn)程部署在一臺(tái)機(jī)器上，大家需要搶占端口，為了防止沖突，往往使用隨機(jī)端口，那客戶端如何找到這些監(jiān)聽(tīng)的端口呢？

問(wèn)題五：發(fā)生了錯(cuò)誤、重傳、丟包、性能等問(wèn)題怎么辦？
????本地調(diào)用沒(méi)有這個(gè)問(wèn)題，但是一旦到網(wǎng)絡(luò)上，這些問(wèn)題都需要處理，因?yàn)榫W(wǎng)絡(luò)是不可靠的，雖然在同一個(gè)連接中，我們還可以通過(guò) TCP 協(xié)議保證丟包、重傳的問(wèn)題，但是如果服務(wù)器崩潰了又重啟，當(dāng)前連接斷開(kāi)了，TCP 就保證不了了，需要應(yīng)用自己進(jìn)行重新調(diào)用，重新傳輸會(huì)不會(huì)同樣的操作做兩遍，遠(yuǎn)程調(diào)用性能會(huì)不會(huì)受影響呢？

????看到這么多問(wèn)題，是不是很頭疼？還記得咱們了解 http 的時(shí)候，認(rèn)識(shí)的協(xié)議三要素嗎？

????本地調(diào)用函數(shù)里很多問(wèn)題，比如詞法分析、語(yǔ)法分析、語(yǔ)義分析等待，這些問(wèn)題編譯器基本上都幫我們解決了，但是在遠(yuǎn)程調(diào)用中，這些問(wèn)題我們都要自己考慮。

????很多公司對(duì)于這個(gè)問(wèn)題，是弄一個(gè)核心通信組，里面都是 socket 編程的大牛，實(shí)現(xiàn)一個(gè)統(tǒng)一的庫(kù)，讓其他業(yè)務(wù)組的人來(lái)調(diào)用，業(yè)務(wù)的人不需要知道中間傳輸?shù)募?xì)節(jié)。

????通信雙方的語(yǔ)法、語(yǔ)義、格式、端口、錯(cuò)誤處理等，都需要調(diào)用方和被調(diào)用方開(kāi)會(huì)商量，雙方達(dá)成一致。一旦有一方改變，要及時(shí)通知對(duì)方，否則就會(huì)出現(xiàn)問(wèn)題。

????但是，不是每個(gè)公司都能通過(guò)這種大牛團(tuán)隊(duì)解決問(wèn)題的，而是使用已經(jīng)實(shí)現(xiàn)好的框架。

????有一個(gè)大牛（Bruce Jay Nelson）通過(guò)一篇論文，定義了 RPC 的調(diào)用標(biāo)準(zhǔn)。后面所有 RPC 框架都是按照這個(gè)標(biāo)準(zhǔn)模式來(lái)的。

整個(gè)過(guò)程如下：

客戶端的應(yīng)用想發(fā)起一個(gè)遠(yuǎn)程調(diào)用時(shí)，它實(shí)際上是通過(guò)本地調(diào)用方的 Stub。它負(fù)責(zé)將調(diào)用的接口、方法和參數(shù)，通過(guò)約定的協(xié)議規(guī)范進(jìn)行編碼，并通過(guò)本地 RPCRuntime 進(jìn)行傳輸，將調(diào)用網(wǎng)絡(luò)包發(fā)送到服務(wù)器；

服務(wù)端的 RPCRuntime 收到請(qǐng)求后，交給提供方 Stub 進(jìn)行編碼，然后調(diào)用服務(wù)端的方法，獲取結(jié)果，并將結(jié)果編碼后，發(fā)送給客戶端；

客戶端的 RPCRuntime 收到結(jié)果，發(fā)給調(diào)用方 Stub 解碼得到結(jié)果，返回給客戶端。

????上面過(guò)程中分了三個(gè)層次：客戶端、Stub 層、服務(wù)端。

????對(duì)于客戶端和服務(wù)端，都像是本地調(diào)用一樣，專注于業(yè)務(wù)邏輯的處理就可以了。對(duì)于 Stub 層，處理雙方約定好的語(yǔ)法、語(yǔ)義、封裝、解封裝。對(duì)于 RPCRuntime，主要處理高性能的傳輸，以及網(wǎng)絡(luò)的錯(cuò)誤和異常。

????最早的 RPC 的一種實(shí)現(xiàn)方式稱為 Sun RPC 或 ONC RPC。Sun 公司是第一個(gè)提供商業(yè)化 RPC 庫(kù)和 RPC 編譯器的公司。這個(gè) RPC 框架是在 NFS 協(xié)議中使用的。

????NFS（Network File System）就是網(wǎng)絡(luò)文件系統(tǒng)。要使 NFS 成功運(yùn)行，就要啟動(dòng)兩個(gè)服務(wù)端，一個(gè) mountd，用來(lái)掛載文件路徑。另一個(gè)是 nfsd，用來(lái)讀寫(xiě)文件。NFS 可以在本地 mount 一個(gè)遠(yuǎn)程的目錄到本地目錄，從而實(shí)現(xiàn)讓本地用戶在本地目錄里面讀寫(xiě)文件時(shí)，操作是是遠(yuǎn)程另一臺(tái)機(jī)器上的文件。

????遠(yuǎn)程操作和遠(yuǎn)程調(diào)用的思路是一樣的，就像本地操作一樣，所以 NFS 協(xié)議就是基于 RPC 實(shí)現(xiàn)的。當(dāng)然，無(wú)論是什么 RPC，底層都是 socket 編程。

????XDR（External Data Representation，外部數(shù)據(jù)表示法）是有一個(gè)標(biāo)準(zhǔn)的數(shù)據(jù)壓縮格式，可以表示基本的數(shù)據(jù)類型，也可以表示結(jié)構(gòu)體。

????這里有幾種基本的數(shù)據(jù)類型。

????在 RPC 的調(diào)用過(guò)程中，所有的數(shù)據(jù)類型都要封裝成類似的格式，而且 RPC 的調(diào)用和結(jié)果返回也有嚴(yán)格的格式。

XID 唯一標(biāo)識(shí)請(qǐng)求和回復(fù)。請(qǐng)求是 0，回復(fù)是 1；

RPC 有版本號(hào)，兩端要匹配 RPC 協(xié)議的版本號(hào)。如果不匹配，就會(huì)返回 Deny，原因是 RPC_MISMATCH；

程序有編號(hào)。如果服務(wù)端找不到這個(gè)程序，就會(huì)返回 PROG_UNAVAIL；

程序有版本號(hào)。如果程序的版本號(hào)不匹配，就會(huì)返回 PROG_MISMATCH；

一個(gè)程序可以有多個(gè)方法，方法也有編號(hào)，如果找不到方法，就會(huì)返回 PROG_UNAVAIL；

調(diào)用需要認(rèn)證鑒權(quán)，如果不通過(guò)，返回 Deny；

最后是參數(shù)列表，如果參數(shù)無(wú)法解析，返回 GABAGE_ARGS；

????為了可以成功調(diào)用 RPC，在客戶端和服務(wù)端實(shí)現(xiàn) RPC 的時(shí)候，首先要定義一個(gè)雙方都認(rèn)可的程序、版本、方法、參數(shù)等。

????對(duì)于上面的加法而言，雙方約定為一個(gè)協(xié)議定義文件，同理，如果是 NFS、mount 和讀寫(xiě)，也會(huì)有類似的定義。

????有了協(xié)議定義文件，ONC RPC 會(huì)提供一個(gè)工具，根據(jù)這個(gè)文件生成客戶端和服務(wù)器端的 Stub 程序。

????最下層的是 XDR 文件，用于編碼和解碼參數(shù)。這個(gè)文件是客戶端和服務(wù)端共享的，因?yàn)橹挥须p方一致才能成功通信。

????在客戶端，會(huì)調(diào)用 clnt_create 創(chuàng)建一個(gè)連接，然后調(diào)用 add_1，這是一個(gè) Stub 函數(shù)，感覺(jué)是在調(diào)用本地函數(shù)一樣。其實(shí)是這個(gè)函數(shù)發(fā)起了一個(gè) RPC 調(diào)用，通過(guò)調(diào)用 clnt_call 來(lái)調(diào)用 ONC RPC 的類庫(kù)，來(lái)真正發(fā)送請(qǐng)求。調(diào)用的過(guò)程較為復(fù)雜，后續(xù)再進(jìn)行專門的說(shuō)明。

????當(dāng)然，服務(wù)端也有一個(gè) Stub 程序，監(jiān)聽(tīng)客戶端的請(qǐng)求，當(dāng)調(diào)用到達(dá)的時(shí)候，判斷如果是 add，則調(diào)用真正的服務(wù)端邏輯，也就是將兩個(gè)數(shù)加起來(lái)。

????服務(wù)端將結(jié)果返回服務(wù)端的 Stub，Stub 程序發(fā)送結(jié)果給客戶端 Stub，客戶端 Stub 收到結(jié)果后就返回給客戶端的應(yīng)用程序，從而完成這個(gè)調(diào)用過(guò)。

????有了這個(gè) RPC 框架，前面五個(gè)問(wèn)題中的 “如何規(guī)定遠(yuǎn)程調(diào)用的語(yǔ)法？”、“如何傳遞參數(shù)？” 以及 “如何表示數(shù)據(jù)？” 基本解決了，這三個(gè)問(wèn)題我們統(tǒng)稱為協(xié)議約定問(wèn)題。

????前三個(gè)問(wèn)題解決了，但是錯(cuò)誤、重傳、丟包以及性能問(wèn)題還沒(méi)有解決，這些問(wèn)題我們統(tǒng)稱為傳輸問(wèn)題。這個(gè) Stub 層就無(wú)能為力了，而是由 ONC RPC 的類庫(kù)來(lái)實(shí)現(xiàn)。

????在這個(gè)類庫(kù)中，為了解決傳輸問(wèn)題，對(duì)于每一個(gè)客戶端，都會(huì)創(chuàng)建一個(gè)傳輸管理層，而每一次 RPC 調(diào)用，都會(huì)是一個(gè)任務(wù)，在傳輸管理層，你可以看到熟悉的隊(duì)列機(jī)制、擁塞窗口機(jī)制等。

????由于在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候，經(jīng)常需要等待，而同步的方式往往效率比較低，因而也就有 socket 的異步模型。

????為了能夠異步處理，對(duì)于遠(yuǎn)程調(diào)用的處理，往往是通過(guò)狀態(tài)機(jī)來(lái)實(shí)現(xiàn)的。只有當(dāng)滿足某個(gè)狀態(tài)的時(shí)候，才進(jìn)行下一步，如果不滿足狀態(tài)，不是在那里等待，而是將資源留出來(lái)，用來(lái)處理其他的 RPC 調(diào)用。

????如上圖，從圖也可以看出，這個(gè)狀態(tài)轉(zhuǎn)換圖還是很復(fù)雜的。

????首先，進(jìn)入起始狀態(tài)，查看 RPC 的傳輸層隊(duì)列中有沒(méi)有空閑的位置，可以處理新的 RPC 任務(wù)，如果沒(méi)有，說(shuō)明太忙了，直接結(jié)束或重試。如果申請(qǐng)成功，就可以分配內(nèi)存，獲取服務(wù)端的端口號(hào)，然后連接服務(wù)器。

????連接的過(guò)程要有一段時(shí)間，因而要等待連接結(jié)果，如果連接失敗，直接結(jié)束或重試。如果連接成功，則開(kāi)始發(fā)送 RPC 請(qǐng)，然后等待獲取 RPC 結(jié)果。同樣的，這個(gè)過(guò)程也需要時(shí)間，如果發(fā)送出錯(cuò)，就重新發(fā)送，如果連接斷開(kāi)，要重新連接，如果超時(shí)，要重新傳輸。如果獲取到結(jié)果，就可以解碼，正常結(jié)束。

????這里處理了連接失敗、重試、發(fā)送失敗、超時(shí)、重試等場(chǎng)景，因而實(shí)現(xiàn)一個(gè) RPC 框架，其實(shí)很有難度。

????傳輸問(wèn)題解決了，我們還遺留了一個(gè) “如何找到 RPC 服務(wù)端的那個(gè)隨機(jī)端口”，這個(gè)問(wèn)題我們稱為服務(wù)發(fā)現(xiàn)問(wèn)題，在 ONC RPC 中，服務(wù)發(fā)現(xiàn)是通過(guò) portmapper 實(shí)現(xiàn)的。

????portmapper 會(huì)啟動(dòng)在一個(gè)眾所周知的端口上，RPC 程序由于是用戶自己寫(xiě)的，會(huì)監(jiān)聽(tīng)在一個(gè)隨機(jī)端口上，但是 RPC 程序啟動(dòng)的時(shí)候，會(huì)向 portmapper 注冊(cè)。

????客戶端要訪問(wèn) RPC 服務(wù)端這個(gè)程序的時(shí)候，首先查詢 portmapper，獲取 RPC 服務(wù)端程序的隨機(jī)端口，然后向這個(gè)隨機(jī)端口建立連接，開(kāi)始 RPC 調(diào)用。

從下圖中可以看出，mount 命令的 RPC 調(diào)用就是這樣實(shí)現(xiàn)的。

遠(yuǎn)程調(diào)用看起來(lái)用 socket 編程就可以了，其實(shí)是很復(fù)雜的，要解決協(xié)議約定問(wèn)題、傳輸問(wèn)題和服務(wù)發(fā)現(xiàn)問(wèn)題；

ONC RPC 框架以及 NFS 的實(shí)現(xiàn)，給出了解決上述三大問(wèn)題的示范性實(shí)現(xiàn)，也就是公用協(xié)議描述文件，并通過(guò)這個(gè)文件生成 Stub 程序。RPC 的傳輸一般需要一個(gè)狀態(tài)機(jī)，需要另外一個(gè)進(jìn)程專門做服務(wù)發(fā)現(xiàn)。

參考：

劉超-趣談網(wǎng)絡(luò)協(xié)議系列課；

如何給老婆解釋什么是RPC;