Dubbo-go Server端開啓服務過程詳情 - dubbo,dubbox,java,go,microservice dubbo_go 博客

導讀

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

序言

近日閲讀了部分dubbo-go源碼
https://github.com/dubbogo/dubbo-go

當拿到一款框架之後，一種不錯的源碼閲讀方式大致如下：從運行最基礎的helloworld demo 源碼開始，再查看配置文件，開啓各種依賴服務（比如zk、consul），開啓服務端，再到通過client調用服務端，打印完整請求日誌和回包。調用成功之後，再根據框架的設計模型，從配置文件解析開始，自頂向下遞閲讀整個框架的調用棧。
對於C/S模式的rpc請求來説，整個調用棧被拆成了client和server兩部分，所以可以分別從server端的配置文件解析閲讀到server端的監聽啓動，從client端的配置文件解析閲讀到一次invoker Call 調用。這樣一次完整請求就明晰了起來。

1. 運行官網提供的helloworld-demo

官方demo

1.1 dubbo-go 2.7版本 QuickStart

1. 開啓一個go-server服務

將倉庫clone 到本地

$ git clone https://github.com/dubbogo/dubbo-samples.git

$ 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服務

$ 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. 常見問題

1. 當日志開始部分出現profiderInit和ConsumerInit均失敗的日誌。檢查環境變量中配置路徑是否正確，配置文件是否正確。
1. 當日志中出現register失敗的情況，一般為向註冊中心註冊失敗，檢查註冊中心是否開啓，檢查配置文件中關於register的端口是否正確。
1. sample的默認開啓端口為20000，確保啓動前無佔用

1.2 配置環境變量

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

1.3 服務端源碼

1. 目錄結構

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

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官方文檔提供的設計圖

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()優雅地結束一個服務的啓動過程。

1.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註冊、調用過程：

1.5 自定義配置文件（非環境變量）方法

1.5.1 服務端自定義配置文件

var providerConfigStr = xxxxx// 配置文件內容，可以參考log 和 client
- 在這裏你可以定義配置文件的獲取方式，比如配置中心，本地文件讀取
在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 {
    }
}

1.5.2 客户端自定義配置文件

var consumerConfigStr = xxxxx// 配置文件內容，可以參考log 和 client
- 在這裏你可以定義配置文件的獲取方式，比如配置中心，本地文件讀取
在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)
}

2. server端：

服務暴露過程涉及到多次原始rpcService的封裝、暴露，網上其他文章的圖感覺太過籠統，我簡要的繪製了一個用户定義服務的數據流圖

2.1 加載配置

2.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.1.2 配置文件

服務端需要的重要配置有三個字段：services、protocols、registries
profiles/dev/server.yaml:

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需要設置用户名和密碼，也可以在配置中寫好。

2.1.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()函數代碼如下：

前半部分是配置的讀入和檢查，進入for循環後，是單個service的暴露起始點。
前面提到，在配置文件中已經寫好了要暴露的service的種種信息，比如服務名、interface名、method名等等。在圖中for循環內，會將所有service的服務依次實現。
for循環的第一行，根據key調用GetProviderService函數，拿到註冊的rpcService實例，這裏對應上述提到的init函數中用户手動註冊的自己實現的rpc-service實例：

這個對象也就成為了for循環中的rpcService變量，將這個對象註冊通過Implement函數寫到sys（ServiceConfig類型）上，設置好sys的key和協議組，最終調用了sys的Export方法。
此處對應流程圖的部分：

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

2.2 原始service封裝入proxy_invoker

config/service_config.go :: Export()
接下來進入ServiceConfig.Export()函數：
這個函數進行了一些細碎的操作，比如為不同的協議分配隨機端口，如果指定了多箇中心註冊協議，則會將服務通過多箇中心註冊協議的registryProtocol暴露出去，我們只關心對於一個註冊協議是如何操作的。還有一些操作比如生成調用url和註冊url，用於為暴露做準備。

2.2.1 首先通過配置生成對應registryUrl和serviceUrl

registryUrl是用來向中心註冊組件發起註冊請求的，對於zookeeper的話，會傳入其ip和端口號，以及附加的用户名密碼等信息
這個regUrl目前只存有註冊（zk）相關信息，後續會補寫入ServiceIvk，即服務調用相關信息，裏面包含了方法名，參數等...

2.2.2 對於一個註冊協議，將傳入的rpc-service實例註冊在common.ServiceMap

這個Register函數將服務實例註冊了兩次，一次是以Interface為key寫入接口服務組內，一次是以interface和proto為key寫入特定的一個唯一的服務。
後續會從common.Map裏面取出來這個實例。

2.2.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的函數如下：

到這裏，上面GetInvoker(*regUrl)返回的invoker即為proxy_invoker，他封裝好了用户定義的rpc_service，並將具體的調用邏輯封裝入了Invoke函數內。

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

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

2.3 registry協議在zkRegistry上暴露上面的proxy_invoker

上面，我們執行到了exporter = c.cacheProtocol.Export(invoker)
這裏的cacheProtocol為一層緩存設計，對應到原始的demo上，這裏是默認實現好的registryProtocol
registry/protocol/protocol.go:: Export()
這個函數內構造了多個EventListener，非常有java的設計感。
我們只關心服務暴露的過程，先忽略這些監聽器。

2.3.1 獲取註冊url和服務url

2.3.2 獲取註冊中心實例zkRegistry

一層緩存操作，如果cache沒有需要從common裏面重新拿zkRegistry

2.3.3 zkRegistry調用Registry方法，在zookeeper上註冊dubboPath

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

該結構體組合了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函數，進而調用：

在這個函數裏，將對應root創造一個新的節點

並且寫入具體node信息，node為url經過encode的結果，包含了服務端的調用方式。
這部分的代碼較為複雜，具體可以看baseRegistry的 processURL()函數。
至此，將服務端調用url註冊到了zookeeper上，而客户端如果想獲取到這個url，只需要傳入特定的dubboPath，向zk請求即可。目前client是可以獲取到訪問方式了，但服務端的特定服務還沒有啓動，還沒有開啓特定協議端口的監聽，這也是registry/protocol/protocol.go:: Export()函數接下來要做的事情：

2.3.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()

protocol/protocolwrapped/protocol_filter_wrapper.go:buildInvokerChain

可見，根據配置的內容，通過鏈式調用的構造，層層將proxy_invoker包裹在調用鏈的最底部，最終返回一個調用鏈invoker。
對應圖中部分：

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

2.3.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()

這一函數做了兩個事情：構造觸發器、啓動服務

將傳入的Invoker調用chain進一步封裝，封裝成一個exporter，再將這個export放入map保存。注意！這裏昂exporter放入了SetExporterMap中，在下面服務啓動的時候，會以註冊事件監聽器的形式將這個exporter取出！
調用dubboProtocol的openServer方法，開啓一個針對特定端口的監聽

如上圖所示，一個Session被傳入，開啓對應端口的事件監聽。
至此構造出了exporter，完成圖中部分：

2.4 註冊觸發動作

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

其中很重要的一個配置是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 調用後的一系列處理：

傳入包的解析

根據請求包構造請求url

拿到對應請求key，找到要被調用的exporter

拿到對應的Invoker

構造invocation

調用

整個被調過程一氣呵成。實現了從getty.Session的調用事件，到經過層層封裝的invoker的調用。
至此，一次rpc調用得以正確返回。

3. 小結

關於Invoker的層層封裝
能把一次調用抽象成一次invoke，能把一個協議抽象成針對invoke的封裝，能把針對一次invoke所做出的特定改變封裝到invoke函數內部，可以降低模塊之間的耦合性。層層封裝邏輯更加清晰
關於URL的抽象
關於dubbo的統一化請求對象URL的極度抽象是我之前沒有見過的... 我認為這樣封裝能保證請求參數列表的簡化和一致。但我認為在開發的過程中，濫用極度抽象的接口可能造成...debug的困難？以及不知道哪些字段是當前已經封裝好的，哪些字段是無用的。
關於協議的理解
之前理解的協議還是太過具體化了，而關於dubbo-go對於dubboProtocol的協議，我認為是基於getty的進一步封裝，他定義了客户端和服務端，對於getty的session應該有哪些特定的操作，從而保證主調和被調的協議一致性，而這種保證也是一種協議的體現，是由dubbo協議來規範的。

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

作者簡介

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

博客 / 詳情