Nacos Go微服務生態系列(一) | Dubbo-go 雲原生核心引擎探索

者：李志鵬， Github賬號：Lzp0412,開源社群愛好者，Nacos Committer，Nacos-SDK-go作者，現就職於阿里云云原生應用平臺，主要參與服務發現、CoreDNS、ServiceMesh相關工作，負責推動Nacos Go微服務生態建設。

---

近幾年，隨著Go語言社群逐漸發展和壯大，越來越多的公司開始嘗試採用Go搭建微服務體系，也湧現了一批Go的微服務框架，如go-micro、go-kit、Dubbo-go等，跟微服務治理相關的元件也逐漸開始在Go生態發力，如Sentinel、Hystrix等都推出了Go語言版本，而作為微服務框架的核心引擎--註冊中心，也是必不可缺少的元件，市面已經有多款註冊中心支援Go語言，應該如何選擇呢？我們可以對目前主流的支援Go語言的註冊中心做個對比。

             

根據上表的對比我們可以從以下幾個維度得出結論：

• 生態:各註冊中心對Go語言都有支援，但是Nacos、 Consul、Etcd 社群活躍，zookeeper和Eureka社群活躍度較低；

• 易用性：Nacos、Eureka、Consul都有現成的管控平臺，Etcd、zookeeper本身作為kv儲存，沒有相應的管控平臺，Nacos支援中文介面，比較符合國人使用習慣；

• 場景支援：CP模型主要針對強一致場景，如金融類，AP模型適用於高可用場景，Nacos可以同時滿足兩種場景，Eureka、Consul主要滿足高可用場景，Zookeepr、Etcd主要滿足強一致場景，此外Nacos支援從其它註冊中心同步資料，方便使用者註冊中心遷移；

• 功能完整性：所有註冊中心都支援健康檢查，Nacos、Consul支援的檢查方式較多，滿足不同應用場景，Zookeeper透過keep alive方式，能實時感知例項變化；Nacos、Consul和Eureka都支援負載均衡策略，Nacos透過Metadata selector支援更靈活的策略；此外，Nacos、Eureka都支援雪崩保護，避免因為過多的例項不健康對健康的例項造成雪崩效應。

 

綜合上面各維度的對比，可以瞭解到Nacos作為註冊中心有一定的優勢，那麼它對Go微服務生態的整合做得如何？為此，我們策劃了本系列文章，該系列將為大家介紹Nacos在Go微服務生態整合中做的一些工作和實踐經驗，系列內容將主要包含以下三個篇章：

• Dubbo-go 雲原生核心引擎探索；

• Sentinel-go 外部動態資料來源初探；

• go-micro 整合Nacos實踐；

接下來我們首先探索下Nacso是如何與Dubbo-go整合。

引言

Dubbo-go目前是Dubbo多語言生態中最火熱的一個專案，從2016年釋出至今，已經走過5個年頭。最近，Dubbo-go釋出了v1.5版本，全面相容Dubbo 2.7.x版本，支援了應用維度的服務註冊與發現，和主流的註冊模型保持一致，標誌著Dubbo-go向雲原生邁出了關鍵的一步。作為驅動服務運轉的核心引擎--註冊中心，在切換到應用維度的註冊模型後，也需要做相應的適配，本文將解析如何以Nacos為核心引擎實現應用維度的服務註冊與發現，並且給出相應的實踐案例。此外，本文程式碼基於Dubbo-go v1.5.1，Nacos-SDK-go v1.0.0和Nacos v1.3.2。

服務註冊與發現架構

從架構中，我們可以看到，與介面級別的服務註冊發現不同的是，Dubbo-go的provider啟動後會呼叫Nacos-go-sdk的RegisterInstance介面向Nacos註冊服務例項，註冊的服務名即為應用名稱，而不是介面名稱。Conusmer啟動後則會呼叫Subscribe介面訂閱該應用的服務例項變化，並對的例項發起服務呼叫。

             

圖2

服務模型 jiaozuo/

圖3是我們Dubbo-go的應用維度服務發現模型，主要有服務和例項兩個層級關係，服務例項的屬性主要包含例項Id、主機地址、服務埠、啟用狀態和後設資料。圖4為Nacos的服務分級儲存模型，包含服務、叢集和例項三個層次。兩者對比，多了一個叢集維度的層級，而且例項屬性資訊能夠完全匹配。所以在Dubbo-go將應用服務例項註冊到Nacos時，我們只需要將叢集設定為預設叢集，再填充服務和例項的相關屬性，即可完成服務模型上的匹配。此外Nacos可以將服務註冊到不同的Namespace下，實現多租戶的隔離。

             

圖3

             

圖4

服務例項心跳維持

Dubbo-go的Provider在向Nacos註冊應用服務例項資訊後，需要主動上報心跳，讓Nacos服務端感知例項的存活與否，以判斷是否將該節點從例項列表中移除。維護心跳的工作是在Nacos-SDK-go完成的，從圖5程式碼中可以看到，當Dubbo-go呼叫RegisterInstance註冊一個服務例項時，SDK除了呼叫Nacos的Register API之外，還會呼叫AddBeatInfo，將服務例項資訊新增到本地快取，透過後臺協程定期向Nacos傳送服務例項資訊，保持心跳。當服務下線時，可以透過呼叫DeRegisterInstance執行反註冊，並移除本地的心跳保持任務，Nacos例項列表中也會將該例項移除。

             

圖5

訂閱服務例項變化

Dubbo-go的Consumer在啟動的時候會呼叫Nacos-SDK-go的Subscribe介面，該介面入參如圖6，訂閱的時候只需要傳遞ServiceName即應用名和回撥函式SubscribeCallback，Nacos在服務例項發生變化的時候即可透過回撥函式通知Dubbo-go。Nacos-SDK-go是如何感知Nacos的服務例項變化的呢？主要有兩種方式：

• Nacos服務端主動推送，Nacos-SDK-go在啟動的時候會監聽一個UDP埠，該埠在呼叫Nacos Register API的時候作為引數傳遞，Nacos會記錄Ip和埠，當服務例項發生變化時，Nacos會對所有監聽該服務的Ip和埠傳送UDP請求，推送變化後的服務例項資訊。

• Nacos-SDK-go定期查詢，SDK會對訂閱的服務例項定時呼叫查詢介面，如果查詢有變化則透過回撥介面通知Dubbo-go。作為兜底策略保證Nacos服務端推送失敗後，仍能感知到變化。

             

圖6

此外Nacos-SDK-go還支援推空保護，當Nacos推送的例項列表為空時，不更新本地快取，也不通知Dubbo-go變更，避免Consumer無可用例項呼叫，造成故障。同時，SDK還支援服務例項資訊本地持久化儲存，可以保證在Nacos服務故障過程中，Consumer重啟也能獲取到可用例項，具備容災效果。

 

範例實踐

環境準備

• dubbo-go samples程式碼下載：，基於Nacos註冊中心的應用級服務發現的hello world程式碼目錄在registry/servicediscovery/nacos。

              

圖7

• Nacos服務端搭建，參考官方文件：，或者使用官方提供的公共Nacos服務：(賬號密碼:nacos，僅供測試)，或者購買阿里雲服務：https://help.aliyun.com/document_detail/139460.html?spm=a2c4g.11186623.6.559.d7e264b7bLpZIs

Server端搭建

進入registry/servicediscovery/nacos/go-server/profiles檔案，可以看到有dev、release和test三個資料夾，分別對應開發、測試和生產配置。我們使用dev配置來搭建開發環境，dev檔案下有log.yml和server.yml檔案，下面對server.yml配置進行修改。

remote配置，這裡使用公共的Nacos服務，address支援配置多個地址，用逗號分割。params引數配置nacos-sdk的日誌目錄。

remote:  nacos:address: "console.nacos.io:80"timeout: "5s"params:logDir: "/data/nacos-sdk/log"configCenter配置config_center:protocol: "nacos"address: "console.nacos.io:80"

配置server端環境變數

export CONF_PROVIDER_FILE_PATH=server端的server.yml檔案路徑export APP_LOG_CONF_FILE=server端的log.yml檔案路徑

進入registry/servicediscovery/nacos/go-server/app，執行server.go的main方法，可以從Nacos的控制檯（/#/serviceManagement?dataId=&group=&appName=&namespace=）看到，應用user-info-server已經註冊成功。

             

 

             

Client端搭建

client的配置檔案在registry/servicediscovery/nacos/go-server/profiles目錄下，需要修改的地方跟server端一樣，這裡不贅述。

配置client端環境變數

export CONF_CONSUMER_FILE_PATH=client端的server.yml檔案路徑export APP_LOG_CONF_FILE=client端的log.yml檔案路徑

進入registry/servicediscovery/nacos/go-client/app，執行client.go的main方法，看到如下日誌輸出，表示呼叫server端成功。