當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Dubbo-go 源码笔记（一）Server 端开启服务过程

發布時間：2025/3/20 编程问答 13 豆豆

生活随笔收集整理的這篇文章主要介紹了 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

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

當日志開始部分出現 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

func init() {config.SetProviderService(new(UserProvider))// ------for hessian2------hessian.RegisterPOJO(&User{}) } type User struct {Id stringName stringAge int32Time 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() 優雅地結束一個服務的啟動過程。

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

client 地址：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,warnconfig.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,warnconfig.Load()user := &User{}err := userProvider.GetUser(context.TODO(), []interface{}{"A001"}, user)if err != nil {log.Print(err)return}log.Print(user) }

Server 端

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

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中的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 端开启服务过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。