![1.png](https://ucc.alicdn.com/pic/developer-ecology/5e64c224ed8e4b0ca5a75b0bb4654f8e.png)

# 作者 | 李志信

**dubbo-go 原始碼**：[https://github.com/apache/dubbo-go](https://github.com/apache/dubbo-go)

> **導讀**：隨著微服務架構的流行，許多高效能 rpc 框架應運而生，由阿里開源的 dubbo 框架 go 語言版本的 dubbo-go 也成為了眾多開發者不錯的選擇。本文將介紹 dubbo-go 框架的基本使用方法，以及從 export 呼叫鏈的角度進行 server 端原始碼導讀，希望能引導讀者進一步認識這款框架。下週將發表本文的姊妹篇：《從 client 端原始碼導讀 dubbo-go 框架》。

當拿到一款框架之後，一種不錯的原始碼閱讀方式大致如下：從執行最基礎的 helloworld demo 原始碼開始 —> 再檢視配置檔案 —> 開啟各種依賴服務（比如zk、consul） —> 開啟服務端 —> 再到透過 client 呼叫服務端 —> 列印完整請求日誌和回包。呼叫成功之後，再根據框架的設計模型，從配置檔案解析開始，自頂向下遞閱讀整個框架的呼叫棧。

對於 C/S 模式的 rpc 請求來說，整個呼叫棧被拆成了 client 和 server 兩部分，所以可以分別從 server 端的配置檔案解析閱讀到 server 端的監聽啟動，從 client 端的配置檔案解析閱讀到一次 invoker Call 呼叫。這樣一次完整請求就明晰了起來。

# 執行官網提供的 helloworld-demo

**官方 demo 相關連結**：[https://github.com/dubbogo/dubbo-samples/tree/master/golang/helloworld/dubbo](https://github.com/dubbogo/dubbo-samples/tree/master/golang/helloworld/dubbo)

## 1. dubbo-go 2.7 版本 QuickStart

### 1）開啟一個 go-server 服務

- 將倉庫 clone 到本地

> $ git clone [https://github.com/dubbogo/dubbo-samples.git](https://github.com/dubbogo/dubbo-samples.git)

- 進入 dubbo 目錄

> $ cd dubbo-samples/golang/helloworld/dubbo

進入目錄後可看到四個資料夾，分別支援 go 和 java 的 client 以及 server，我們嘗試執行一個 go 的 server。進入 app 子資料夾內，可以看到裡面儲存了 go 檔案。

> $ cd go-server/app

- sample 檔案結構

可以在 go-server 裡面看到三個資料夾：app、assembly、profiles。

其中 app 資料夾下儲存 go 原始碼，assembly 資料夾下儲存可選的針對特定環境的 build 指令碼，profiles 下儲存配置檔案。對於 dubbo-go 框架，配置檔案非常重要，沒有檔案將導致服務無法啟動。

- 設定指向配置檔案的環境變數

由於 dubbo-go 框架依賴配置檔案啟動，讓框架定位到配置檔案的方式就是透過環境變數來找。對於 server 端需要兩個必須配置的環境變數：CONF_PROVIDER_FILE_PATH、APP_LOG_CONF_FILE，分別應該指向服務端配置檔案、日誌配置檔案。

在 sample 裡面，我們可以使用 dev 環境，即 profiles/dev/log.yml  和 profiles/dev/server.yml 兩個檔案。在 app/ 下，透過命令列中指定好這兩個檔案：

> $ export CONF_PROVIDER_FILE_PATH="../profiles/dev/server.yml"

> $ export APP_LOG_CONF_FILE="../profiles/dev/log.yml"

- 設定 go 代理並執行服務

> $ go run .

如果提示 timeout，則需要設定 goproxy 代理。

> $ export GOPROXY="http://goproxy.io"

再執行 go run 即可開啟服務。

### 2）執行 zookeeper

安裝 zookeeper，並執行 zkServer, 預設為 2181 埠。

### 3）執行 go-client 呼叫 server 服務

- 進入 go-client 的原始碼目錄

> $ cd go-client/app

- 同理，在 /app 下配置環境變數

> $ export CONF_CONSUMER_FILE_PATH="../profiles/dev/client.yml"

> $ export APP_LOG_CONF_FILE="../profiles/dev/log.yml"

配置 go 代理：

> $ export GOPROXY="http://goproxy.io"

- 執行程式

> $ go run .

即可在日誌中找到列印出的請求結果：

> response result: &{A001 Alex Stocks 18 2020-10-28 14:52:49.131 +0800 CST}

同樣，在執行的 server 中，也可以在日誌中找到列印出的請求：

> req:[]interface {}{"A001"}

> rsp:main.User{Id:"A001", Name:"Alex Stocks", Age:18, Time:time.Time{...}

恭喜！一次基於 dubbo-go 的 rpc 呼叫成功。

### 4）常見問題

- 當日志開始部分出現 profiderInit 和 ConsumerInit 均失敗的日誌，檢查環境變數中配置路徑是否正確，配置檔案是否正確。

- 當日志中出現 register 失敗的情況，一般為向註冊中心註冊失敗，檢查註冊中心是否開啟，檢查配置檔案中關於 register 的埠是否正確。

- sample 的預設開啟埠為 20000，確保啟動前無佔用。

## 2. 配置環境變數

```
export APP_LOG_CONF_FILE="../profiles/dev/log.yml"
export CONF_CONSUMER_FILE_PATH="../profiles/dev/client.yml"
```

## 3. 服務端原始碼

### 1）目錄結構

dubbo-go 框架的 example 提供的目錄如下：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/cfd2483128d64205b720cf1cfaf909c0.png)

- app/ 資料夾下存放原始碼，可以自己編寫環境變數配置指令碼 buliddev.sh

- assembly/ 資料夾下存放不同平臺的構建指令碼

- profiles/ 資料夾下存放不同環境的配置檔案

- target/ 資料夾下存放可執行檔案

## 2）關鍵原始碼

原始碼放置在 app/ 資料夾下，主要包含 server.go 和 user.go 兩個檔案，顧名思義，server.go 用於使用框架開啟服務以及註冊傳輸協議；user.go 則定義了 rpc-service 結構體，以及傳輸協議的結構。

- **user.go**

```
func init() {
	config.SetProviderService(new(UserProvider))
	// ------for hessian2------
	hessian.RegisterPOJO(&User{})
}
type User struct {
	Id   string
	Name string
	Age  int32
	Time time.Time
}
type UserProvider struct {
}
func (u *UserProvider) GetUser(ctx context.Context, req []interface{}) (*User, error) {
```

可以看到，user.go 中存在 init 函式，是服務端程式碼中最先被執行的部分。User 為使用者自定義的傳輸結構體，UserProvider 為使用者自定義的 rpc_service；包含一個 rpc 函式，GetUser。當然，使用者可以自定義其他的 rpc 功能函式。

在 init 函式中，呼叫 config 的 SetProviderService 函式，將當前 rpc_service 註冊在框架 config 上。

**可以檢視 dubbo 官方文件提供的設計圖：**

![3.png](https://ucc.alicdn.com/pic/developer-ecology/6b8f963c51b143deb25b3ba3e41d9b63.png)

service 層下面就是 config 層，使用者服務會逐層向下註冊，最終實現服務端的暴露。

rpc-service 註冊完畢之後，呼叫 hessian 介面註冊傳輸結構體 User。

至此，init 函式執行完畢。

- **server.go**

```
// they are necessary:
//  	export CONF_PROVIDER_FILE_PATH="xxx"
//  	export APP_LOG_CONF_FILE="xxx"
func main() {
	hessian.RegisterPOJO(&User{})
	config.Load()
	initSignal()
}
func initSignal() {
	signals := make(chan os.Signal, 1)
	...
```

之後執行 main 函式。

main 函式中只進行了兩個操作，首先使用 hessian 註冊元件將 User 結構體註冊（與之前略有重複），從而可以在接下來使用 getty 打解包。

之後呼叫 config.Load 函式，該函式位於框架 config/config_loader.go 內，這個函式是整個框架服務的啟動點，**下面會詳細講這個函式內重要的配置處理過程**。執行完 Load() 函式之後，配置檔案會讀入框架，之後根據配置檔案的內容，將註冊的 service 實現到配置結構裡，再呼叫 Export 暴露給特定的 registry，進而開啟特定的 service 進行對應埠的 tcp 監聽，成功啟動並且暴露服務。

最終開啟訊號監聽 initSignal() 優雅地結束一個服務的啟動過程。

## 4. 客戶端原始碼

客戶端包含 client.go 和 user.go 兩個檔案，其中 user.go 與服務端完全一致，不再贅述。

- **client.go**

```
// they are necessary:
//  	export CONF_CONSUMER_FILE_PATH="xxx"
//  	export APP_LOG_CONF_FILE="xxx"
func main() {
	hessian.RegisterPOJO(&User{})
	config.Load()
	time.Sleep(3e9)
	println("\n\n\nstart to test dubbo")
	user := &User{}
	err := userProvider.GetUser(context.TODO(), []interface{}{"A001"}, user)
	if err != nil {
  panic(err)
	}
	println("response result: %v\n", user)
	initSignal()
}
```

main 函式和服務端也類似，首先將傳輸結構註冊到 hessian 上，再呼叫 config.Load() 函式。在下文會介紹，客戶端和服務端會根據配置型別執行 config.Load() 中特定的函式 loadConsumerConfig() 和 loadProviderConfig()，從而達到“開啟服務”、“呼叫服務”的目的。

載入完配置之後，還是透過實現服務、增加函式 proxy、申請 registry 和 reloadInvoker 指向服務端 ip 等操作，重寫了客戶端例項 userProvider 的對應函式，這時再透過呼叫 GetUser 函式，可以直接透過 invoker，呼叫到已經開啟的服務端，實現 rpc 過程。

下面會從 server 端和 client 端兩個角度，詳細講解服務啟動、registry 註冊和呼叫過程。

## 5. 自定義配置檔案（非環境變數）方法

### 1）服務端自定義配置檔案

- var providerConfigStr = `xxxxx`// 配置檔案內容，可以參考 log 和 client。在這裡你可以定義配置檔案的獲取方式，比如配置中心，本地檔案讀取。

> **log 地址**：[https://github.com/dubbogo/dubbo-samples/blob/master/golang/helloworld/dubbo/go-client/profiles/release/log.yml](https://github.com/dubbogo/dubbo-samples/blob/master/golang/helloworld/dubbo/go-client/profiles/release/log.yml)

> **client 地址**：[https://github.com/dubbogo/dubbo-samples/blob/master/golang/helloworld/dubbo/go-client/profiles/release/client.yml](https://github.com/dubbogo/dubbo-samples/blob/master/golang/helloworld/dubbo/go-client/profiles/release/client.yml)

- 在 `config.Load()` 之前設定配置，例如：

```
func main() {
	hessian.RegisterPOJO(&User{})
	providerConfig := config.ProviderConfig{}
	yaml.Unmarshal([]byte(providerConfigStr), &providerConfig)
	config.SetProviderConfig(providerConfig)
	defaultServerConfig := dubbo.GetDefaultServerConfig()
	dubbo.SetServerConfig(defaultServerConfig)
	logger.SetLoggerLevel("warn") // info,warn
	config.Load()
	select {
	}
}
```

### 2）客戶端自定義配置檔案

- var consumerConfigStr = `xxxxx`// 配置檔案內容，可以參考 log 和 clien。在這裡你可以定義配置檔案的獲取方式，比如配置中心，本地檔案讀取。

- 在 `config.Load()` 之前設定配置，例如：

```
func main() {
     p := config.ConsumerConfig{}
     yaml.Unmarshal([]byte(consumerConfigStr), &p)
     config.SetConsumerConfig(p)
     defaultClientConfig := dubbo.GetDefaultClientConfig()
     dubbo.SetClientConf(defaultClientConfig)
     logger.SetLoggerLevel("warn") // info,warn
     config.Load()

user := &User{}
     err := userProvider.GetUser(context.TODO(), []interface{}{"A001"}, user)
     if err != nil {
         log.Print(err)
         return
     }
  log.Print(user)
}
```

# Server 端

服務暴露過程涉及到多次原始 rpcService 的封裝、暴露，網上其他文章的圖感覺太過籠統，在此，簡要地繪製了一個使用者定義服務的資料流圖：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/aed72dd144894f6cbe355ed660f952dd.png)

## 1. 載入配置

### 1）框架初始化

在載入配置之前，框架提供了很多已定義好的協議、工廠等元件，都會在對應模組 init 函式內註冊到 extension 模組上，以供接下來配置檔案中進行選用。

其中重要的有：

- **預設函式代理工廠**：common/proxy/proxy_factory/default.go

```
func init() {
	extension.SetProxyFactory("default", NewDefaultProxyFactory)
}
```

它的作用是將原始 rpc-service 進行封裝，形成 proxy_invoker，更易於實現遠端 call 呼叫，詳情可見其 invoke 函式。

- **註冊中心註冊協議**：
registry/protocol/protocol.go

```
func init() {
	extension.SetProtocol("registry", GetProtocol)
}
```

它負責將 invoker 暴露給對應註冊中心，比如 zk 註冊中心。

- **zookeeper 註冊協議**：registry/zookeeper/zookeeper.go

```
func init() {
	extension.SetRegistry("zookeeper", newZkRegistry)
}
```

它合併了 base_resiger，負責在服務暴露過程中，將服務註冊在 zookeeper 註冊器上，從而為呼叫者提供呼叫方法。

- **dubbo 傳輸協議**：protocol/dubbo/dubbo.go

```
func init() {
	extension.SetProtocol(DUBBO, GetProtocol)
}
```

它負責監聽對應埠，將具體的服務暴露，並啟動對應的事件 handler，將遠端呼叫的 event 事件傳遞到 invoker 內部，呼叫本地 invoker 並獲得執行結果返回。

- **filter 包裝呼叫鏈協議**：protocol/protocolwrapper/protocol_filter_wrapper.go

```
func init() {
	extension.SetProtocol(FILTER, GetProtocol)
}
```

它負責在服務暴露過程中，將代理 invoker 打包，透過配置好的 filter 形成呼叫鏈，並交付給 dubbo 協議進行暴露。

上述提前註冊好的框架已實現的元件，在整個服務暴露呼叫鏈中都會用到，會根據配置取其所需。

### 2）配置檔案

服務端需要的重要配置有三個欄位：services、protocols、registries。

profiles/dev/server.yml:

```
registries :
  "demoZk":
    protocol: "zookeeper"
    timeout	: "3s"
    address: "127.0.0.1:2181"
services:
  "UserProvider":
    # 可以指定多個registry，使用逗號隔開;不指定預設向所有註冊中心註冊
    registry: "demoZk"
    protocol : "dubbo"
    # 相當於dubbo.xml中的interface
    interface : "com.ikurento.user.UserProvider"
    loadbalance: "random"
    warmup: "100"
    cluster: "failover"
    methods:
    - name: "GetUser"
      retries: 1
      loadbalance: "random"
protocols:
  "dubbo":
    name: "dubbo"
    port: 20000
```

其中 service 指定了要暴露的 rpc-service 名（"UserProvider）、暴露的協議名（"dubbo"）、註冊的協議名("demoZk")、暴露的服務所處的 interface、負載均衡策略、叢集失敗策略及呼叫的方法等等。

其中，中間服務的協議名需要和 registries 下的 mapkey 對應，暴露的協議名需要和 protocols 下的 mapkey 對應。

可以看到上述例子中，使用了 dubbo 作為暴露協議，使用了 zookeeper 作為中間註冊協議，並且給定了埠。如果 zk 需要設定使用者名稱和密碼，也可以在配置中寫好。

### 3）配置檔案的讀入和檢查

> config/config_loader.go:: Load()

在上述 example 的 main 函式中，有 config.Load() 函式的直接呼叫，該函式執行細節如下：

```
// Load Dubbo Init
func Load() {
	// init router
	initRouter()
	// init the global event dispatcher
	extension.SetAndInitGlobalDispatcher(GetBaseConfig().EventDispatcherType)
	// start the metadata report if config set
	if err := startMetadataReport(GetApplicationConfig().MetadataType, GetBaseConfig().MetadataReportConfig); err != nil {
  logger.Errorf("Provider starts metadata report error, and the error is {%#v}", err)
  return
	}
	// reference config
	loadConsumerConfig()
	// service config
	loadProviderConfig()
	// init the shutdown callback
	GracefulShutdownInit()
}
```

在本文中，我們重點關心 loadConsumerConfig() 和 loadProviderConfig() 兩個函式。

對於 provider 端，可以看到 loadProviderConfig() 函式程式碼如下：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/bcdb22e583564b10a9aadfe1b40ea817.png)

前半部分是配置的讀入和檢查，進入 for 迴圈後，是單個 service 的暴露起始點。

前面提到，在配置檔案中已經寫好了要暴露的 service 的種種資訊，比如服務名、interface 名、method 名等等。在圖中 for 迴圈內，會將所有 service 的服務依次實現。

for 迴圈的第一行，根據 key 呼叫 GetProviderService 函式，拿到註冊的 rpcService 例項，這裡對應上述提到的 init 函式中，使用者手動註冊的自己實現的 rpc-service 例項：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/79e6e4f6a4764dbda5ede035dd644d12.png)

這個物件也就成為了 for 迴圈中的 rpcService 變數，將這個物件註冊透過 Implement 函式寫到 sys（ServiceConfig 型別）上，設定好 sys 的 key 和協議組，最終呼叫了 sys 的 Export 方法。

此處對應流程圖的部分：

![7.png](https://ucc.alicdn.com/pic/developer-ecology/a3eb998fdd1a46889e822e7be33a48ab.png)

至此，框架配置結構體已經拿到了所有 service 有關的配置，以及使用者定義好的 rpc-service 例項，它觸發了 Export 方法，旨在將自己的例項暴露出去。這是 Export 呼叫鏈的起始點。

## 2. 原始 service 封裝入 proxy_invoker

> config/service_config.go :: Export()

接下來進入 ServiceConfig.Export() 函式.

這個函式進行了一些細碎的操作，比如為不同的協議分配隨機埠，如果指定了多箇中心註冊協議，則會將服務透過多箇中心註冊協議的 registryProtocol 暴露出去，我們只關心對於一個註冊協議是如何操作的。還有一些操作比如生成呼叫 url 和註冊 url，用於為暴露做準備。

### 1）首先透過配置生成對應 registryUrl 和 serviceUrl

![8.png](https://ucc.alicdn.com/pic/developer-ecology/f73fdad9f25b4114ac50b39688df1357.png)

registryUrl 是用來向中心註冊元件發起註冊請求的，對於 zookeeper 的話，會傳入其 ip 和埠號，以及附加的使用者名稱密碼等資訊。

這個 regUrl 目前只存有註冊（zk）相關資訊，後續會補寫入 ServiceIvk，即服務呼叫相關資訊，裡面包含了方法名，引數等...

### 2）對於一個註冊協議，將傳入的 rpc-service 例項註冊在 common.ServiceMap

![9.png](https://ucc.alicdn.com/pic/developer-ecology/0bf12f622e354dfcac8d8f0624481e16.png)

這個 Register 函式將服務例項註冊了兩次，一次是以 Interface 為 key 寫入介面服務組內，一次是以 interface 和 proto 為 key 寫入特定的一個唯一的服務。

後續會從 common.Map 裡面取出來這個例項。

### 3）獲取預設代理工廠，將例項封裝入代理 invoker

```
// 拿到一個proxyInvoker，這個invoker的url是傳入的regUrl，這個地方將上面註冊的service例項封裝成了invoker
// 這個GetProxyFactory返回的預設是common/proxy/proxy_factory/default.go
// 這個預設工廠呼叫GetInvoker獲得預設的proxyInvoker，儲存了當前註冊url
invoker := extension.GetProxyFactory(providerConfig.ProxyFactory).GetInvoker(*regUrl)
// 暴露出來 生成exporter,開啟tcp監聽
// 這裡就該跳到registry/protocol/protocol.go registryProtocol 呼叫的Export，將當前proxyInvoker匯出
exporter = c.cacheProtocol.Export(invoker)
```

這一步的 GetProxyFactory("default") 方法獲取預設代理工廠，透過傳入上述構造的 regUrl，將 url 封裝入代理 invoker。

可以進入 common/proxy/proxy_factory/default.go::ProxyInvoker.Invoke() 函式里，看到對於 common.Map 取用為 svc 的部分，以及關於 svc 對應 Method 的實際呼叫 Call 的函式如下：

![10.png](https://ucc.alicdn.com/pic/developer-ecology/e34736b206a44ea7a190c039db58d9dd.png)

到這裡，上面 GetInvoker(*regUrl) 返回的 invoker 即為 proxy_invoker，它封裝好了使用者定義的 rpc_service，並將具體的呼叫邏輯封裝入了 Invoke 函式內。

> 為什麼使用 Proxy_invoker 來呼叫？

> 透過這個 proxy_invoke 呼叫使用者的功能函式，呼叫方式將更加抽象化，可以在程式碼中看到，透過 ins 和 outs 來定義入參和出參，將整個呼叫邏輯抽象化為 invocation 結構體，而將具體的函式名的選擇、引數向下傳遞和 reflect 反射過程封裝在 invoke 函式內，這樣的設計更有利於之後遠端呼叫。個人認為這是 dubbo Invoke 呼叫鏈的設計思想。

> 至此，實現了圖中對應的部分：

![11.png](https://ucc.alicdn.com/pic/developer-ecology/65bf747342504ff0b4711e2259de4256.png)

## 3. registry 協議在 zkRegistry 上暴露上面的 proxy_invoker

上面，我們執行到了 exporter = c.cacheProtocol.Export(invoker)。

這裡的 cacheProtocol 為一層快取設計，對應到原始的 demo 上，這裡是預設實現好的 registryProtocol。

> registry/protocol/protocol.go:: Export()

這個函式內構造了多個 EventListener，非常有 java 的設計感。

我們只關心服務暴露的過程，先忽略這些監聽器。

### 1）獲取註冊 url 和服務 url

![12.png](https://ucc.alicdn.com/pic/developer-ecology/8acc7279a7a44be98e4f7ab1d64433b5.png)

### 2）獲取註冊中心例項 zkRegistry

![13.png](https://ucc.alicdn.com/pic/developer-ecology/5ad3be2f82174b32a3ff2b6a7774438e.png)

一層快取操作，如果 cache 沒有需要從 common 裡面重新拿 zkRegistry。

### 3）zkRegistry 呼叫 Registry 方法，在 zookeeper 上註冊 dubboPath

上述拿到了具體的 zkRegistry 例項，該例項的定義在：registry/zookeeper/registry.go。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/c2e7b12afb2e4aadaff75ecb87b01764.png)

該結構體組合了 registry.BaseRegistry 結構，base 結構定義了註冊器基礎的功能函式，比如 Registry、Subscribe 等，但在這些預設定義的函式內部，還是會呼叫 facade 層（zkRegistry 層）的具體實現函式，這一設計模型能在保證已有功能函式不需要重複定義的同時，引入外層函式的實現，類似於結構體繼承卻又複用了程式碼。這一設計模式值得學習。

我們檢視上述 registry/protocol/protocol.go:: Export() 函式，直接呼叫了:

```
// 1. 透過zk註冊器，呼叫Register()函式，將已有@root@rawurl註冊到zk上
	err := reg.Register(*registeredProviderUrl)
```

將已有 RegistryUrl 註冊到了 zkRegistry 上。

這一步呼叫了 baseRegistry 的 Register 函式，進而呼叫 zkRegister 的 DoRegister 函式，進而呼叫：

![15.png](https://ucc.alicdn.com/pic/developer-ecology/43f8d66a0e834886abfad97328a3f4b1.png)

在這個函式里，將對應 root 創造一個新的節點。

![16.png](https://ucc.alicdn.com/pic/developer-ecology/32d7a6245dbb43bd88c4b8a026b9fe8d.png)

並且寫入具體 node 資訊，node 為 url 經過 encode 的結果，**包含了服務端的呼叫方式。**

這部分的程式碼較為複雜，具體可以看 baseRegistry 的 processURL() 函式：[http://t.tb.cn/6Xje4bijnsIDNaSmyPc4Ot](http://t.tb.cn/6Xje4bijnsIDNaSmyPc4Ot)。

至此，將服務端呼叫 url 註冊到了 zookeeper 上，而客戶端如果想獲取到這個 url，只需要傳入特定的 dubboPath，向 zk 請求即可。目前 client 是可以獲取到訪問方式了，但服務端的特定服務還沒有啟動，還沒有開啟特定協議埠的監聽，這也是 registry/protocol/protocol.go:: Export() 函式接下來要做的事情。

### 4）proxy_invoker 封裝入 wrapped_invoker，得到 filter 呼叫鏈

```
	// invoker封裝入warppedInvoker
	wrappedInvoker := newWrappedInvoker(invoker, providerUrl)
	// 經過為invoker增加filter呼叫鏈，再使用dubbo協議Export，開啟service並且返回了Exporter 。
	// export_1
	cachedExporter = extension.GetProtocol(protocolwrapper.FILTER).Export(wrappedInvoker)
```

新建一個 WrappedInvoker，用於之後鏈式呼叫。

拿到提前實現並註冊好的 ProtocolFilterWrapper，呼叫 Export 方法，進一步暴露。

> protocol/protocolwrapped/protocol_filter_wrapper.go:Export()

![17.png](https://ucc.alicdn.com/pic/developer-ecology/da9ebcc4920d451da1c1cfd851e59320.png)

> protocol/protocolwrapped/protocol_filter_wrapper.go:buildInvokerChain

![18.png](https://ucc.alicdn.com/pic/developer-ecology/6d13bedea8c743f297da8bead7c7a88c.png)

可見，根據配置的內容，透過鏈式呼叫的構造，將 proxy_invoker 層層包裹在呼叫鏈的最底部，最終返回一個呼叫鏈 invoker。

對應圖中部分：

![19.png](https://ucc.alicdn.com/pic/developer-ecology/076066ba9f3342fd9821fca539f5b7da.png)

至此，我們已經拿到 filter 呼叫鏈，期待將這個 chain 暴露到特定埠，用於相應請求事件。

### 5）透過 dubbo 協議暴露 wrapped_invoker

> protocol/protocolwrapped/protocol_filter_wrapper.go:Export()

```
// 透過dubbo協議Export  dubbo_protocol呼叫的 export_2
	return pfw.protocol.Export(invoker)
```

回到上述 Export 函式的最後一行，呼叫了 dubboProtocol 的 Export 方法，將上述 chain 真正暴露。

該 Export 方法的具體實現在：protocol/dubbo/dubbo_protocol.go: Export()。

![20.png](https://ucc.alicdn.com/pic/developer-ecology/b6d8ca027fac4fb69b4f19b10e820d57.png)

這一函式做了兩個事情：構造觸發器、啟動服務。

- 將傳入的 Invoker 呼叫 chain 進一步封裝，封裝成一個 exporter，再將這個 export 放入 map 儲存。**注意！這裡把 exporter 放入了 SetExporterMap中，在下面服務啟動的時候，會以註冊事件監聽器的形式將這個 exporter 取出！**

- 呼叫 dubboProtocol 的 openServer 方法，開啟一個針對特定埠的監聽。

![21.png](https://ucc.alicdn.com/pic/developer-ecology/49cb2091a9e14ffd86c1df70956d5bf4.png)

如上圖所示，一個 Session 被傳入，開啟對應埠的事件監聽。

至此構造出了 exporter，完成圖中部分：

![22.png](https://ucc.alicdn.com/pic/developer-ecology/39bc8e30bc9d43818a36f2dcc5aac076.png)

## 4. 註冊觸發動作

上述只是啟動了服務，但還沒有看到觸發事件的細節，點進上面的 s.newSession 可以看到，dubbo 協議為一個 getty 的 session 預設使用瞭如下配置：

![23.png](https://ucc.alicdn.com/pic/developer-ecology/0147e90f6a044469a93bc3d07da4cb3c.png)

其中很重要的一個配置是 EventListener，傳入的是 dubboServer 的預設 rpcHandler。

> protocol/dubbo/listener.go:OnMessage()

rpcHandler 有一個實現好的 OnMessage 函式，根據 getty 的 API，當 client 呼叫該埠時，會觸發 OnMessage。

```
// OnMessage notified when RPC server session got any message in connection
func (h *RpcServerHandler) OnMessage(session getty.Session, pkg interface{}) {
```

這一函式實現了在 getty session 接收到 rpc 呼叫後的一系列處理：

- 傳入包的解析

![24.png](https://ucc.alicdn.com/pic/developer-ecology/d7bbaca4cbf042aa8468d70953da833a.png)

- 根據請求包構造請求 url

![25.png](https://ucc.alicdn.com/pic/developer-ecology/c365cc9abcab44aaa742968a76bd98d5.png)

- 拿到對應請求 key，找到要被呼叫的 exporter

![26.png](https://ucc.alicdn.com/pic/developer-ecology/698894ee372045adbf4d3760a7678be9.png)

- 拿到對應的 Invoker

![27.png](https://ucc.alicdn.com/pic/developer-ecology/c9a902c7f5da4a90bcfc9738a67d0b80.png)

- 構造 invocation

![28.png](https://ucc.alicdn.com/pic/developer-ecology/a16c09a572e0438cafed81652e865f43.png)

- 呼叫

![29.png](https://ucc.alicdn.com/pic/developer-ecology/bff40bb153c54ba4989d94d21fd6603d.png)

- 返回

![30.png](https://ucc.alicdn.com/pic/developer-ecology/fa0acfa915784c8f8f4b70cc769ed1c3.png)

整個被調過程一氣呵成。實現了從 getty.Session 的呼叫事件，到經過層層封裝的 invoker 的呼叫。

至此，一次 rpc 呼叫得以正確返回。

# 小結

- **關於 Invoker 的層層封裝**

能把一次呼叫抽象成一次 invoke；能把一個協議抽象成針對 invoke 的封裝；能把針對一次 invoke 所做出的特定改變封裝到 invoke 函式內部，可以降低模組之間的耦合性。層層封裝邏輯更加清晰。

- **關於 URL 的抽象**

關於 dubbo 的統一化請求物件 URL 的極度抽象是之前沒有見過的... 個人認為這樣封裝能保證請求引數列表的簡化和一致。但在開發的過程中，濫用極度抽象的介面可能造成... debug 的困難？以及不知道哪些欄位是當前已經封裝好的，哪些欄位是無用的。

- **關於協議的理解**

之前理解的協議還是太過具體化了，而關於 dubbo-go 對於 dubboProtocol 的協議，我認為是基於 getty 的進一步封裝，它定義了客戶端和服務端，對於 getty 的 session 應該有哪些特定的操作，從而保證主調和被調的協議一致性，而這種保證也是一種協議的體現，是由 dubbo 協議來規範的。

如果你有任何疑問，歡迎釘釘掃碼加入交流群：釘釘群號 23331795！

### 作者簡介

**李志信** (GitHubID LaurenceLiZhixin)，中山大學軟體工程專業在校學生，擅長使用 Java/Go 語言，專注於雲原生和微服務等技術方向。

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495437&idx=1&sn=54cabeeb2cf93849a2eff99488c923e5&chksm=fae6e4c2cd916dd41e436a821d9159b457e86c831b53f43985dd43eb73c905f229ac70c14f1e&token=781456154&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

Dubbo-go 原始碼筆記（一）Server 端開啟服務過程

相關文章