什么是 RPC

RPC（Remote Procedure Call），即遠程過程調用，它允許像調用本地服務一樣調用遠程服務。是一種服務器-客戶端（Client/Server）模式。

• 遠程：指的是需要經過網絡的，而不是應用內部、機器內部進行的。
• 過程：也就是方法。

那“遠程過程調用”，就是：可以跨過一段網絡，調用另外一個網絡節(jié)點上的方法。以上就是對遠程過程調用的簡單理解。

RPC 調用分以下兩種：

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

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

RPC 基本原理

RPC核心功能

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

1. 既然是遠程調用，那么客戶端如何知道服務端的地址？
2. 如果客戶端和服務端使用的是不同語言寫的程序，那么參數(shù)該如何表達和解析？
3. 如何進行網絡傳輸？

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

服務尋址

如果是本地調用，被調用的方法在同一個進程內，操作系統(tǒng)或者是虛擬機可以去地址空間去找；但是在遠程調用中，這是行不通的，因為兩個進程的地址空間是完全不一樣的，肯定也無法知道遠端的進程在那。

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

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

1. 從服務提供者的角度看：當提供者服務啟動時，需要自動向注冊中心注冊服務；當提供者服務停止時，需要向注冊中心注銷服務；提供者需要定時向注冊中心發(fā)送心跳。如果一段時間未收到來自提供者的心跳后，注冊中心會判定提供者已經停止服務，并從注冊中心下架對應的服務。
2. 從調用者的角度看:調用者啟動時訂閱注冊中心的消息并從注冊中心獲取提供者的地址；當有提供者上線或者下線時，注冊中心會告知到調用者;調用者下線時，取消訂閱。

數(shù)據編解碼

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

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

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

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

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

網絡傳輸

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

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

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

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

一次RPC的調用過程

忽略服務端向注冊中心注冊服務的流程，下面是客戶端和服務端之間進行一次RPC調用的完整過程。

1. 客戶端（Client）通過本地調用的方式調用服務（以接口方式調用）；
2. 客戶端存根（Client Stub）接收到調用請求后負責將方法、入參等信息進行組裝序列化成能夠進行網絡傳輸?shù)南Ⅲw（將消息體對象序列化為二進制流）；
3. 客戶端存根（Client Stub）找到遠程的服務地址，并且將消息通過網絡發(fā)送給服務端（通過sockets發(fā)送消息）；
4. 服務端存根（Server Stub）收到消息后進行反序列化操作，即解碼（將二進制流反序列化為消息對象）；
5. 服務端存根（Server Stub）通過解碼結果調用本地的服務進行相關處理；
6. 服務端（Server）將處理結果返回給服務端存根；
7. 服務端存根（Server Stub）序列化處理結果（將結果消息對象序列化為二進制流）；
8. 服務端存根（Server Stub）將序列化結果通過網絡發(fā)送至客戶端（通過sockets發(fā)送消息）；
9. 客戶端存根（Server Stub）接收到消息，進行反序列化解碼（將結果二進制流反序列化為消息對象）；
10. 客戶端得到最終的結果。

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

實踐

基于HTTP協(xié)議的RPC

服務端代碼：

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() // 注冊 HTTP 路由// 注冊 RPC 服務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庫對注冊的方法有一定的限制，方法必須滿足簽名func (t *T) MethodName(argType T1, replyType *T2) error{}：

1. 方法名必需是可導出的。
2. 方法接收兩個參數(shù)，這兩個參數(shù)都是可導出的，且第二個參數(shù)必需為指針類型。
3. 方法必需返回一個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}// 同步調用var reply1 intif err = client.Call("Compute.Add", args, &reply1); err != nil {log.Fatal("Compute error:", err)}fmt.Printf("同步調用的sum: %d\n", reply1)// 異步調用var reply2 intdivCall := client.Go("Compute.Add", args, &reply2, nil)_ = <-divCall.Done // 接收調用結果fmt.Printf("異步調用的sum: %d\n", reply2)
}

運行結果如下：

PS D:\GolandProjects\RPC\client> go run .\client.go
同步調用的sum: 8
異步調用的sum: 8

基于TCP協(xié)議的RPC

服務端代碼：

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}// 同步調用var reply1 intif err = client.Call("Compute.Add", args, &reply1); err != nil {log.Fatal("Compute error:", err)}fmt.Printf("同步調用的sum: %d\n", reply1)// 異步調用var reply2 intdivCall := client.Go("Compute.Add", args, &reply2, nil)_ = <-divCall.Done // 接收調用結果fmt.Printf("異步調用的sum: %d\n", reply2)
}

運行結果：

PS D:\GolandProjects\RPC\client> go run .\client.go
同步調用的sum: 14
異步調用的sum: 14