什么是 RPC

RPC（Remote Procedure Call），即遠(yuǎn)程過程調(diào)用，它允許像調(diào)用本地服務(wù)一樣調(diào)用遠(yuǎn)程服務(wù)。是一種服務(wù)器-客戶端（Client/Server）模式。

• 遠(yuǎn)程：指的是需要經(jīng)過網(wǎng)絡(luò)的，而不是應(yīng)用內(nèi)部、機(jī)器內(nèi)部進(jìn)行的。
• 過程：也就是方法。

那“遠(yuǎn)程過程調(diào)用”，就是：可以跨過一段網(wǎng)絡(luò)，調(diào)用另外一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)上的方法。以上就是對(duì)遠(yuǎn)程過程調(diào)用的簡(jiǎn)單理解。

RPC 調(diào)用分以下兩種：

1. 同步調(diào)用：客戶方等待調(diào)用執(zhí)行完成并返回結(jié)果。
2. 異步調(diào)用：客戶方調(diào)用后不用等待執(zhí)行結(jié)果返回，但依然可以通過回調(diào)通知等方式獲取返回結(jié)果。 若客戶方不關(guān)心調(diào)用返回結(jié)果，則變成單向異步調(diào)用，單向調(diào)用不用返回結(jié)果。

異步和同步的區(qū)分在于是否等待服務(wù)端執(zhí)行完成并返回結(jié)果。

RPC 基本原理

RPC核心功能

知道什么是RPC以后就會(huì)發(fā)現(xiàn)，RPC需要解決一些問題：

1. 既然是遠(yuǎn)程調(diào)用，那么客戶端如何知道服務(wù)端的地址？
2. 如果客戶端和服務(wù)端使用的是不同語(yǔ)言寫的程序，那么參數(shù)該如何表達(dá)和解析？
3. 如何進(jìn)行網(wǎng)絡(luò)傳輸？

這三個(gè)問題的解決方案也是RPC的核心功能：服務(wù)尋址、數(shù)據(jù)編解碼和網(wǎng)絡(luò)傳輸。

服務(wù)尋址

如果是本地調(diào)用，被調(diào)用的方法在同一個(gè)進(jìn)程內(nèi)，操作系統(tǒng)或者是虛擬機(jī)可以去地址空間去找；但是在遠(yuǎn)程調(diào)用中，這是行不通的，因?yàn)閮蓚€(gè)進(jìn)程的地址空間是完全不一樣的，肯定也無(wú)法知道遠(yuǎn)端的進(jìn)程在那。

如果要想實(shí)現(xiàn)遠(yuǎn)程調(diào)用，我們需要對(duì)服務(wù)消費(fèi)者和服務(wù)提供者兩者進(jìn)行約束：在遠(yuǎn)程過程調(diào)用中所有的函數(shù)都必須有一個(gè) ID，這個(gè) ID 在整套系統(tǒng)中是唯一存在確定的。服務(wù)消費(fèi)者在做遠(yuǎn)程過程調(diào)用時(shí)，發(fā)送的消息體中必須要攜帶這個(gè) ID。服務(wù)消費(fèi)者和服務(wù)提供者分別維護(hù)一個(gè)函數(shù)和 ID 的對(duì)應(yīng)表。當(dāng)服務(wù)消費(fèi)者需要進(jìn)行遠(yuǎn)程調(diào)用時(shí)，它就查一下這個(gè)表，找出對(duì)應(yīng)的 ID，然后把它傳給服務(wù)端，服務(wù)端也通過查表，來(lái)確定客戶端需要調(diào)用的函數(shù)，然后執(zhí)行相應(yīng)函數(shù)的代碼就行。

服務(wù)尋址的實(shí)現(xiàn)方式有很多種，常見的是：服務(wù)注冊(cè)中心。要調(diào)用服務(wù)，首先你需要一個(gè)服務(wù)注冊(cè)中心去查詢對(duì)方服務(wù)都有哪些實(shí)例，然后根據(jù)負(fù)載均衡策略擇優(yōu)選一。

1. 從服務(wù)提供者的角度看：當(dāng)提供者服務(wù)啟動(dòng)時(shí)，需要自動(dòng)向注冊(cè)中心注冊(cè)服務(wù)；當(dāng)提供者服務(wù)停止時(shí)，需要向注冊(cè)中心注銷服務(wù)；提供者需要定時(shí)向注冊(cè)中心發(fā)送心跳。如果一段時(shí)間未收到來(lái)自提供者的心跳后，注冊(cè)中心會(huì)判定提供者已經(jīng)停止服務(wù)，并從注冊(cè)中心下架對(duì)應(yīng)的服務(wù)。
2. 從調(diào)用者的角度看:調(diào)用者啟動(dòng)時(shí)訂閱注冊(cè)中心的消息并從注冊(cè)中心獲取提供者的地址；當(dāng)有提供者上線或者下線時(shí)，注冊(cè)中心會(huì)告知到調(diào)用者;調(diào)用者下線時(shí)，取消訂閱。

數(shù)據(jù)編解碼

對(duì)計(jì)算機(jī)網(wǎng)絡(luò)稍微有一點(diǎn)熟悉的同學(xué)都知道，數(shù)據(jù)在網(wǎng)絡(luò)中傳輸都是二進(jìn)制的：01010101010101010，類似這種，只有二進(jìn)制數(shù)據(jù)才能在網(wǎng)絡(luò)間傳。選擇好的序列化協(xié)議特別重要，一個(gè)好的序列化協(xié)議能減少序列化數(shù)據(jù)帶來(lái)的性能損耗。常見的RPC序列化協(xié)議如下：

• XML（Extensible Markup Language）是一種常用的序列化和反序列化協(xié)議，具有跨機(jī)器，跨語(yǔ)言等優(yōu)點(diǎn)。狹義web service就是基于SOAP消息傳遞協(xié)議（一個(gè)基于XML的可擴(kuò)展消息信封格式）來(lái)進(jìn)行數(shù)據(jù)交換的。

• JSON（Javascript Object Notation）起源于弱類型語(yǔ)言Javascript， 是采用"Attribute－value"的方式來(lái)描述對(duì)象協(xié)議。與XML相比，其協(xié)議比較簡(jiǎn)單，解析速度比較快。

• Protocol Buffers 是google提供的一個(gè)開源序列化框架，是一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)格式，可以用于結(jié)構(gòu)化數(shù)據(jù)串行化，或者說序列化。它很適合做數(shù)據(jù)存儲(chǔ)或 RPC 數(shù)據(jù)交換格式?？捎糜谕ㄓ崊f(xié)議、數(shù)據(jù)存儲(chǔ)等領(lǐng)域的語(yǔ)言無(wú)關(guān)、平臺(tái)無(wú)關(guān)、可擴(kuò)展的序列化結(jié)構(gòu)數(shù)據(jù)格式。同 XML 相比， Protobuf 的主要優(yōu)點(diǎn)在于性能高。它以高效的二進(jìn)制方式存儲(chǔ)，比 XML 小 3 到 10 倍，快 20 到 100 倍。

以上每種協(xié)議都有其優(yōu)點(diǎn)和適用場(chǎng)景，需要根據(jù)具體的需求和環(huán)境來(lái)選擇合適的協(xié)議。

網(wǎng)絡(luò)傳輸

提起網(wǎng)絡(luò)傳輸大家腦海里肯定馬上就能想到 TCP/IP四層模型、OSI 七層模型，那通常 RPC 會(huì)選擇那一層作為傳輸協(xié)議呢？

在回答這個(gè)問題前，先來(lái)看下 RPC 需要網(wǎng)絡(luò)傳輸實(shí)現(xiàn)什么樣的功能?？蛻舳说臄?shù)據(jù)經(jīng)過序列化后，就需要通過網(wǎng)絡(luò)傳輸?shù)椒?wù)端。網(wǎng)絡(luò)傳輸層需要把前面說的函數(shù) ID 和序列化后的參數(shù)字節(jié)流傳給服務(wù)端，服務(wù)端處理完然后再把序列化后的調(diào)用結(jié)果傳回客戶端。

原則上只要能實(shí)現(xiàn)上面這個(gè)功能的都可以作為傳輸層來(lái)使用，具體協(xié)議沒有限制。我們先來(lái)看下 TCP 協(xié)議，TCP 連接可以是按需連接，需要調(diào)用的時(shí)候就先建立連接，調(diào)用結(jié)束后就立馬斷掉，也可以是長(zhǎng)連接，客戶端和服務(wù)器建立起連接之后保持長(zhǎng)期持有，不管此時(shí)有無(wú)數(shù)據(jù)包的發(fā)送，可以配合心跳檢測(cè)機(jī)制定期檢測(cè)建立的連接是否存活有效。

由此可見 TCP 的性能確實(shí)很好，因此市面上大部分 RPC 框架都使用 TCP 協(xié)議，但也有少部分框架使用其他協(xié)議，比如 gRPC 用的是 HTTP2 來(lái)實(shí)現(xiàn)。

一次RPC的調(diào)用過程

忽略服務(wù)端向注冊(cè)中心注冊(cè)服務(wù)的流程，下面是客戶端和服務(wù)端之間進(jìn)行一次RPC調(diào)用的完整過程。

1. 客戶端（Client）通過本地調(diào)用的方式調(diào)用服務(wù)（以接口方式調(diào)用）；
2. 客戶端存根（Client Stub）接收到調(diào)用請(qǐng)求后負(fù)責(zé)將方法、入?yún)⒌刃畔⑦M(jìn)行組裝序列化成能夠進(jìn)行網(wǎng)絡(luò)傳輸?shù)南Ⅲw（將消息體對(duì)象序列化為二進(jìn)制流）；
3. 客戶端存根（Client Stub）找到遠(yuǎn)程的服務(wù)地址，并且將消息通過網(wǎng)絡(luò)發(fā)送給服務(wù)端（通過sockets發(fā)送消息）；
4. 服務(wù)端存根（Server Stub）收到消息后進(jìn)行反序列化操作，即解碼（將二進(jìn)制流反序列化為消息對(duì)象）；
5. 服務(wù)端存根（Server Stub）通過解碼結(jié)果調(diào)用本地的服務(wù)進(jìn)行相關(guān)處理；
6. 服務(wù)端（Server）將處理結(jié)果返回給服務(wù)端存根；
7. 服務(wù)端存根（Server Stub）序列化處理結(jié)果（將結(jié)果消息對(duì)象序列化為二進(jìn)制流）；
8. 服務(wù)端存根（Server Stub）將序列化結(jié)果通過網(wǎng)絡(luò)發(fā)送至客戶端（通過sockets發(fā)送消息）；
9. 客戶端存根（Server Stub）接收到消息，進(jìn)行反序列化解碼（將結(jié)果二進(jìn)制流反序列化為消息對(duì)象）；
10. 客戶端得到最終的結(jié)果。

這里面有一個(gè)詞語(yǔ)：存根（Stub）。這里存根的作用我認(rèn)為和Linux內(nèi)核里面的庫(kù)打樁機(jī)制有點(diǎn)類似。在Linux中，一個(gè)"樁"（stub）就是一個(gè)程序或函數(shù)的臨時(shí)替代品，"樁"可以模擬出類似于真實(shí)的程序或函數(shù)的行為。所以，在RPC中，客戶端存根和服務(wù)器存根的作用是隱藏RPC底層機(jī)制的復(fù)雜性，讓開發(fā)者可以像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)程函數(shù)。

實(shí)踐

基于HTTP協(xié)議的RPC

服務(wù)端代碼：

type Args struct {A, B int
}type Compute intfunc (c *Compute) Add(args *Args, reply *int) error {*reply = args.A + args.Breturn nil
}func main() {compute := new(Compute)rpc.HandleHTTP() // 注冊(cè) HTTP 路由// 注冊(cè) RPC 服務(wù)if err := rpc.Register(compute); err != nil {log.Fatal("Register error:", err)}listen, err := net.Listen("tcp", ":8080")if err != nil {log.Fatal("Listen error:", err)}if err = http.Serve(listen, nil); err != nil {log.Fatal("Serve error:", err)}
}

rpc庫(kù)對(duì)注冊(cè)的方法有一定的限制，方法必須滿足簽名func (t *T) MethodName(argType T1, replyType *T2) error{}：

1. 方法名必需是可導(dǎo)出的。
2. 方法接收兩個(gè)參數(shù)，這兩個(gè)參數(shù)都是可導(dǎo)出的，且第二個(gè)參數(shù)必需為指針類型。
3. 方法必需返回一個(gè)error類型的參數(shù)。

客戶端代碼：

type Args struct {A, B int
}func main() {client, err := rpc.DialHTTP("tcp", "localhost:8080")if err != nil {log.Fatal("dialing:", err)}args := &Args{3, 5}// 同步調(diào)用var reply1 intif err = client.Call("Compute.Add", args, &reply1); err != nil {log.Fatal("Compute error:", err)}fmt.Printf("同步調(diào)用的sum: %d\n", reply1)// 異步調(diào)用var reply2 intdivCall := client.Go("Compute.Add", args, &reply2, nil)_ = <-divCall.Done // 接收調(diào)用結(jié)果fmt.Printf("異步調(diào)用的sum: %d\n", reply2)
}

運(yùn)行結(jié)果如下：

PS D:\GolandProjects\RPC\client> go run .\client.go
同步調(diào)用的sum: 8
異步調(diào)用的sum: 8

基于TCP協(xié)議的RPC

服務(wù)端代碼：

type Args struct {A, B int
}type Compute intfunc (c *Compute) Add(args *Args, reply *int) error {*reply = args.A + args.Breturn nil
}func main() {compute := new(Compute)if err := rpc.Register(compute); err != nil {log.Fatal("Register error:", err)}listen, err := net.Listen("tcp", ":8080")if err != nil {log.Fatal("Listen error:", err)}rpc.Accept(listen)
}

客戶端代碼：

type Args struct {A, B int
}func main() {client, err := rpc.Dial("tcp", "localhost:8080")if err != nil {log.Fatal("dialing:", err)}args := &Args{6, 8}// 同步調(diào)用var reply1 intif err = client.Call("Compute.Add", args, &reply1); err != nil {log.Fatal("Compute error:", err)}fmt.Printf("同步調(diào)用的sum: %d\n", reply1)// 異步調(diào)用var reply2 intdivCall := client.Go("Compute.Add", args, &reply2, nil)_ = <-divCall.Done // 接收調(diào)用結(jié)果fmt.Printf("異步調(diào)用的sum: %d\n", reply2)
}

運(yùn)行結(jié)果：

PS D:\GolandProjects\RPC\client> go run .\client.go
同步調(diào)用的sum: 14
異步調(diào)用的sum: 14