### 一、RPC是什麼

在很久之前的單機時代，一臺電腦中跑著多個程式，程式之間沒有交流各幹各的，就這樣過了很多年。突然有一天有了新需求，A程式需要實現一個畫圖的功能，恰好鄰居B程式已經有了這個功能，偷懶的程式設計師C想出了一個辦法：A程式調B程式的畫圖功能。於是出現了IPC（Inter-process communication，程式間通訊）。就這樣程式設計師C愉快的去吃早餐去了！

又過了幾年，到了網際網路時代，每個電腦都實現了互聯互通。這時候僱主又有了新需求，當時還沒掛的A程式需要實現使用tensorflow識別出笑臉 >_< 。說巧不巧，遠在幾千裡的一臺快速執行的電腦上已經實現了這個功能，睡眼惺忪的程式媛D接手了這個A程式後借鑑之前IPC的實現，把IPC擴充套件到了網際網路上，這就是RPC(Remote Procedure Call，遠端過程呼叫)。RPC其實就是一臺電腦上的程式呼叫另外一臺電腦上的程式的工具。成熟的RPC方案大多數會具備服務註冊、服務發現、熔斷降級和限流等機制。目前市面上的RPC已經有很多成熟的了，比如Facebook家的Thrift、Google家的gRPC、阿里家的Dubbo和螞蟻家的SOFA。

### 二、介面定義語言

介面定義語言，簡稱IDL,是實現端對端之間可靠通訊的一套編碼方案。這裡有涉及到傳輸資料的序列化和反序列化，我們常用的http的請求一般用json當做序列化工具，定製rpc協議的時候因為要求響應迅速等特點，所以大多數會定義一套序列化協議。比如：

Protobuf：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c94280c643256e?w=695&h=389&f=png&s=114673)

講到Protobuf就得講到該庫作者的另一個作品Cap'n proto了，號稱效能是直接秒殺Google Protobuf，直接上官方對比：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c9428300a7e76a?w=593&h=528&f=png&s=70176)

雖然知道很多比Protobuf更快的編碼方案，但是快到這種地步也是厲害了，為啥這麼快，Cap’n Proto的文件裡面就立刻說明了，因為Cap'n Proto沒有任何序列號和反序列化步驟，Cap'n Proto編碼的資料格式跟在記憶體裡面的佈局是一致的，所以可以直接將編碼好的structure直接位元組存放到硬碟上面。貼個栗子：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c942851d9e0204?w=694&h=533&f=png&s=108887)

我們這裡要定製的編碼方案就是基於protobuf和Cap'n Proto結合的類似的語法。因為本人比較喜歡刀劍神域裡的男主角，所以就給這個庫起了個名字—— Kiritobuf。

首先我們定義kirito的語法：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c94288b5e24327?w=695&h=314&f=png&s=54375)

-   #開頭的是註釋
    
-   保留關鍵字, service、method、struct,
    
-   {}裡是一個塊結構
    
-   ()裡有兩個引數，第一個是請求的引數結構，第二個是返回值的結構
    
-   @是定義引數位置的描述符，0表示在首位
    
-   =號左邊是引數名，右邊是引數型別
    
    引數型別：
    
    -   Boolean: Bool
    -   Integers: Int8, Int16, Int32, Int64
    -   Unsigned integers:
    
    UInt8, UInt16, UInt32, UInt64
    
    -   Floating-point: Float32, Float64
    -   Blobs: Text, Data
    -   Lists: List(T)
    
   定義好了語法和引數型別，我們先過一下生成有抽象關係程式碼的流程：
  
![](https://user-gold-cdn.xitu.io/2019/8/15/16c94296d20ee59a?w=1046&h=255&f=png&s=25989)
   
 取到.kirito字尾的檔案，讀取全部字元，透過詞法分析器生成token，得到的token傳入語法分析器生成AST (抽象語法樹)。
  
 首先我們新建一個kirito.js檔案:
   
![](https://user-gold-cdn.xitu.io/2019/8/15/16c942ab1a7aaf0b?w=695&h=568&f=png&s=195147)
   
定義好了一些必要的字面量，接下來首先是詞法分析階段。

**1、詞法解析**

我們設計詞法分析得到的Token是這樣子的：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c942b34a1b3b46?w=693&h=849&f=png&s=269697)
    
詞法分析步驟：

-   把獲取到的kirito程式碼串按照\n分割組合成陣列A，陣列的每個元素就是一行程式碼
  
-   遍歷陣列A，將每行程式碼逐個字元去讀取
-   在讀取的過程中定義匹配規則，比如註釋、保留字、變數、符號、陣列等
-   將每個匹配的字元或字串按照對應型別新增到tokens陣列中
 
程式碼如下：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c942c0e7c69f76?w=692&h=1998&f=png&s=474889)

**2、語法分析**

得到上面的詞法分析的token後，我們就可以對該token做語法分析，我們需要最終生成的AST的格式如下：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c942cec306df2b?w=692&h=2013&f=png&s=371836)
  
看上圖我們能友好的得到結構、引數、資料型別、函式之間的依賴和關係，步驟：

1、遍歷詞法分析得到的token陣列，透過呼叫分析函式提取token之間的依賴節點

2、分析函式內部定義token提取規則，比如：
-   服務保留字 服務名 { 函式保留字 函式名 ( 入參，返回引數 ) }
-   引數結構保留字 結構名 { 引數位置 引數名 引數資料型別 }
3、遞迴呼叫分析函式提取對應節點依賴關係，將節點新增到AST中

程式碼如下：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c942de56c154b0?w=692&h=2977&f=png&s=691595)

**3、轉換器**

得到了語法分析的AST後我們需要進一步對AST轉換為更易操作的js物件。格式如下：
 
![](https://user-gold-cdn.xitu.io/2019/8/15/16c942e4e952f7d5?w=691&h=350&f=png&s=49449)

透過上面這個格式，我們可以更容易的知道有幾個service、service裡有多少個函式以及函式的引數。
 
程式碼如下：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c942ecd259ba1a?w=694&h=1588&f=png&s=455993)

### 三、傳輸協議

RPC協議有多種，可以是json、xml、http2，相對於http1.x這種文字協議，http2.0這種二進位制協議更適合作為RPC的應用層通訊協議。很多成熟的RPC框架一般都會定製自己的協議已滿足各種變化莫測的需求。

比如Thrift的TBinaryProtocol、TCompactProto-col等，使用者可以自主選擇適合自己的傳輸協議。
（除了按位元組編址還有按字編址和按位編址），我們這裡只討論位元組編址。每個機器因為不同的系統或者不同的CPU對記憶體地址的編碼有不一樣的規則，一般分為兩種位元組序：大端序和小端序。
-   大端序: 資料的高位元組儲存在低地址
-   小端序: 資料的低位元組儲存在高地址

舉個例子：
 
比如一個整數：258，用16進製表示為0x0102，我們把它分為兩個位元組0x01和ox02，對應的二進位制為0000 0001和0000 0010。在大端序的電腦上存放形式如下：
  
![](https://user-gold-cdn.xitu.io/2019/8/15/16c942f7bd5797e1?w=493&h=230&f=png&s=20884)
 
小端序則相反。為了保證在不同機器之間傳輸的資料是一樣的，開發一個通訊協議時會首先約定好使用一種作為通訊方案。java虛擬機器採用的是大端序。在機器上我們稱為主機位元組序，網路傳輸時我們稱為網路位元組序。網路位元組序是TCP/IP中規定好的一種資料表示格式，它與具體的CPU型別、作業系統等無關，從而可以保證資料在不同主機之間傳輸時能夠被正確解釋。網路位元組序採用大端排序方式。

我們這裡就不造新應用層協議的輪子了，我們直接使用MQTT協議作為我們的預設應用層協議。MQTT（Message Queuing Telemetry Tran-sport，訊息佇列遙測傳輸協議），是一種基於釋出/訂閱（publish/subscribe）模式的“輕量級”通訊協議，採用大端序的網路位元組序傳輸，該協議構建於TCP/IP協議上。

### 四、實現通訊

先貼下實現完的程式碼呼叫流程，首先是server端：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c9430235058fdf?w=698&h=367&f=png&s=138197)

client端：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c9430b8aedb9fa?w=693&h=357&f=png&s=148471)

無論是server端定義函式或者client端呼叫函式都是比較簡潔的步驟。接下來我們慢慢剖析具體的邏輯實現。

貼下具體的呼叫流程架構圖：
  
![](https://user-gold-cdn.xitu.io/2019/8/15/16c943108de44c45?w=1080&h=517&f=png&s=95002)

呼叫流程總結：

-   client端解析kirito檔案，繫結kirito的service到client物件
-   server端解析kirito檔案，將kiritod的service與呼叫函式繫結新增到server物件
-   client端呼叫kirito service 裡定義的函式，註冊回撥事件，發起MQTT請求
-   server端接收MQTT請求，解析請求body，呼叫對應的函式執行完後向client端發起MQTT請求
-   client端接收到MQTT請求後，解析body和error，並從回撥事件佇列裡取出對應的回撥函式並賦值執行
-   
說完了呼叫流程，現在開始講解具體的實現。

**server：**
  
![](https://user-gold-cdn.xitu.io/2019/8/15/16c9431d9c9a99cb?w=689&h=2784&f=png&s=724053)

定義protocol介面，加上這一層是為了以後的多協議，mqtt只是預設使用的協議：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c94321891180cb?w=693&h=192&f=png&s=45317)

接下來是server端的暴露出去的介面：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c94325f3d3a288?w=693&h=192&f=png&s=45317)

**client：**

![](https://user-gold-cdn.xitu.io/2019/8/15/16c9433586c577b4?w=691&h=2005&f=png&s=512377)

定義protocol介面：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c94337f9237240?w=692&h=194&f=png&s=45739)
最後是client端暴露的介面：

![](https://user-gold-cdn.xitu.io/2019/8/15/16c94339ccd75767?w=694&h=1433&f=png&s=377867)
 就這樣，一個簡單的IDL+RPC框架就這樣搭建完成了。這裡只是描述RPC的原理和常用的呼叫方式，要想用在企業級的開發上，還得加上服務發現、註冊，服務熔斷，服務降級等，讀者如果有興趣可以在Github上fork下來或者提PR來改進這個框架，有什麼問題也可以提Issue, 當然PR是最好的 : ) 。

倉庫地址：
  
RPC: https://github.com/polixjs/polix-rpc
 
 IDL:https://github.com/rickyes/kiritobuf
 
歡迎大家來[數瀾社群](https://bbs.dtwave.com/)一起學習～

從零開始實現一個IDL+RPC框架

相關文章