Dubbo-go 源码笔记（一）Server 端开启服务过程
作者 | 李志信
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
1. dubbo-go 2.7 版本 QuickStart
1）開啟一個 go-server 服務
- 將倉庫 clone 到本地
$?git?clone?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 提供的目錄如下：
-
app/ 文件夾下存放源碼，可以自己編寫環境變量配置腳本 buliddev.sh
-
assembly/ 文件夾下存放不同平臺的構建腳本
-
profiles/ 文件夾下存放不同環境的配置文件
-
target/ 文件夾下存放可執行文件
2）關鍵源碼
源碼放置在 app/ 文件夾下，主要包含 server.go 和 user.go 兩個文件，顧名思義，server.go 用于使用框架開啟服務以及注冊傳輸協議；user.go 則定義了 rpc-service 結構體，以及傳輸協議的結構。
- user.go
可以看到，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
之后執行 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
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
client 地址：https://github.com/dubbogo/dubbo-samples/blob/master/golang/helloworld/dubbo/go-client/profiles/release/client.yml
- 在 config.Load() 之前設置配置，例如：
2）客戶端自定義配置文件
-
var consumerConfigStr?= xxxxx// 配置文件內容，可以參考?log 和 clien。在這里你可以定義配置文件的獲取方式，比如配置中心，本地文件讀取。
-
在 config.Load() 之前設置配置，例如：
Server 端
服務暴露過程涉及到多次原始 rpcService 的封裝、暴露，網上其他文章的圖感覺太過籠統，在此，簡要地繪制了一個用戶定義服務的數據流圖：
1. 加載配置
1）框架初始化
在加載配置之前，框架提供了很多已定義好的協議、工廠等組件，都會在對應模塊 init 函數內注冊到 extension 模塊上，以供接下來配置文件中進行選用。
其中重要的有：
- 默認函數代理工廠：common/proxy/proxy_factory/default.go
它的作用是將原始 rpc-service 進行封裝，形成 proxy_invoker，更易于實現遠程 call 調用，詳情可見其 invoke 函數。
- 注冊中心注冊協議：
registry/protocol/protocol.go
它負責將 invoker 暴露給對應注冊中心，比如 zk 注冊中心。
- zookeeper 注冊協議：registry/zookeeper/zookeeper.go
它合并了 base_resiger，負責在服務暴露過程中，將服務注冊在 zookeeper 注冊器上，從而為調用者提供調用方法。
- dubbo 傳輸協議：protocol/dubbo/dubbo.go
它負責監聽對應端口，將具體的服務暴露，并啟動對應的事件 handler，將遠程調用的 event 事件傳遞到 invoker 內部，調用本地 invoker 并獲得執行結果返回。
- filter 包裝調用鏈協議：protocol/protocolwrapper/protocol_filter_wrapper.go
它負責在服務暴露過程中，將代理 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中的interfaceinterface : "com.ikurento.user.UserProvider"loadbalance: "random"warmup: "100"cluster: "failover"methods:- name: "GetUser"retries: 1loadbalance: "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 routerinitRouter()// init the global event dispatcherextension.SetAndInitGlobalDispatcher(GetBaseConfig().EventDispatcherType)// start the metadata report if config setif err := startMetadataReport(GetApplicationConfig().MetadataType, GetBaseConfig().MetadataReportConfig); err != nil {logger.Errorf("Provider starts metadata report error, and the error is {%#v}", err)return}// reference configloadConsumerConfig()// service configloadProviderConfig()// init the shutdown callbackGracefulShutdownInit() }在本文中，我們重點關心 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. 原始 service 封裝入 proxy_invoker
config/service_config.go?::?Export()
接下來進入 ServiceConfig.Export() 函數.
這個函數進行了一些細碎的操作，比如為不同的協議分配隨機端口，如果指定了多個中心注冊協議，則會將服務通過多個中心注冊協議的 registryProtocol 暴露出去，我們只關心對于一個注冊協議是如何操作的。還有一些操作比如生成調用 url 和注冊 url，用于為暴露做準備。
1）首先通過配置生成對應 registryUrl 和 serviceUrl
registryUrl 是用來向中心注冊組件發起注冊請求的，對于 zookeeper 的話，會傳入其 ip 和端口號，以及附加的用戶名密碼等信息。
這個 regUrl 目前只存有注冊（zk）相關信息，后續會補寫入 ServiceIvk，即服務調用相關信息，里面包含了方法名，參數等…
2）對于一個注冊協議，將傳入的 rpc-service 實例注冊在 common.ServiceMap
這個 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 的函數如下：
到這里，上面 GetInvoker(*regUrl) 返回的 invoker 即為 proxy_invoker，它封裝好了用戶定義的 rpc_service，并將具體的調用邏輯封裝入了 Invoke 函數內。
為什么使用 Proxy_invoker 來調用？
通過這個 proxy_invoke 調用用戶的功能函數，調用方式將更加抽象化，可以在代碼中看到，通過 ins 和 outs 來定義入參和出參，將整個調用邏輯抽象化為 invocation 結構體，而將具體的函數名的選擇、參數向下傳遞和 reflect 反射過程封裝在 invoke 函數內，這樣的設計更有利于之后遠程調用。個人認為這是 dubbo Invoke 調用鏈的設計思想。
至此，實現了圖中對應的部分：
3. registry 協議在 zkRegistry 上暴露上面的 proxy_invoker
上面，我們執行到了 exporter = c.cacheProtocol.Export(invoker)。
這里的 cacheProtocol 為一層緩存設計，對應到原始的 demo 上，這里是默認實現好的 registryProtocol。
registry/protocol/protocol.go::?Export()
這個函數內構造了多個 EventListener，非常有 java 的設計感。
我們只關心服務暴露的過程，先忽略這些監聽器。
1）獲取注冊 url 和服務 url
2）獲取注冊中心實例 zkRegistry
一層緩存操作，如果 cache 沒有需要從 common 里面重新拿 zkRegistry。
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() 函數：http://t.tb.cn/6Xje4bijnsIDNaSmyPc4Ot。
至此，將服務端調用 url 注冊到了 zookeeper 上，而客戶端如果想獲取到這個 url，只需要傳入特定的 dubboPath，向 zk 請求即可。目前 client 是可以獲取到訪問方式了，但服務端的特定服務還沒有啟動，還沒有開啟特定協議端口的監聽，這也是 registry/protocol/protocol.go:: Export() 函數接下來要做的事情。
4）proxy_invoker 封裝入 wrapped_invoker，得到 filter 調用鏈
// invoker封裝入warppedInvokerwrappedInvoker := newWrappedInvoker(invoker, providerUrl)// 經過為invoker增加filter調用鏈，再使用dubbo協議Export，開啟service并且返回了Exporter 。// export_1cachedExporter = 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 暴露到特定端口，用于相應請求事件。
5）通過 dubbo 協議暴露 wrapped_invoker
protocol/protocolwrapped/protocol_filter_wrapper.go:Export()
// 通過dubbo協議Export dubbo_protocol調用的 export_2return 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，完成圖中部分：
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 調用得以正確返回。
小結
- 關于 Invoker 的層層封裝
能把一次調用抽象成一次 invoke；能把一個協議抽象成針對 invoke 的封裝；能把針對一次 invoke 所做出的特定改變封裝到 invoke 函數內部，可以降低模塊之間的耦合性。層層封裝邏輯更加清晰。
- 關于 URL 的抽象
關于 dubbo 的統一化請求對象 URL 的極度抽象是之前沒有見過的… 個人認為這樣封裝能保證請求參數列表的簡化和一致。但在開發的過程中，濫用極度抽象的接口可能造成… debug 的困難？以及不知道哪些字段是當前已經封裝好的，哪些字段是無用的。
- 關于協議的理解
之前理解的協議還是太過具體化了，而關于 dubbo-go 對于 dubboProtocol 的協議，我認為是基于 getty 的進一步封裝，它定義了客戶端和服務端，對于 getty 的 session 應該有哪些特定的操作，從而保證主調和被調的協議一致性，而這種保證也是一種協議的體現，是由 dubbo 協議來規范的。
如果你有任何疑問，歡迎釘釘掃碼加入交流群：釘釘群號 23331795！
作者簡介
李志信?(GitHubID LaurenceLiZhixin)，中山大學軟件工程專業在校學生，擅長使用 Java/Go 語言，專注于云原生和微服務等技術方向。
“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號。”
總結
以上是生活随笔為你收集整理的Dubbo-go 源码笔记（一）Server 端开启服务过程的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 想成为全栈工程师，要做到哪几点？
- 下一篇： 解读云原生基础设施