您好,登錄后才能下訂單哦!
這篇文章主要介紹“Dubbo-go的核心注冊引擎Nacos怎么使用”,在日常操作中,相信很多人在Dubbo-go的核心注冊引擎Nacos怎么使用問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Dubbo-go的核心注冊引擎Nacos怎么使用”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
近幾年,隨著Go語言社區逐漸發展和壯大,越來越多的公司開始嘗試采用Go搭建微服務體系,也涌現了一批Go的微服務框架,如go-micro、go-kit、Dubbo-go等,跟微服務治理相關的組件也逐漸開始在Go生態發力,如Sentinel、Hystrix等都推出了Go語言版本,而作為微服務框架的核心引擎--注冊中心,也是必不可缺少的組件,市面已經有多款注冊中心支持Go語言,應該如何選擇呢?我們可以對目前主流的支持Go語言的注冊中心做個對比。
圖1
根據上表的對比我們可以從以下幾個維度得出結論:
生態:各注冊中心對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是如何與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
圖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代碼下載:https://github.com/apache/dubbo-samples/tree/master/golang,基于Nacos注冊中心的應用級服務發現的hello world代碼目錄在 registry/servicediscovery/nacos。
圖7
進入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的控制臺(http://console.nacos.io/nacos/#/serviceManagement?dataId=&group=&appName=&namespace=)
看到,應用user-info-server已經注冊成功。
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端成功。
到此,關于“Dubbo-go的核心注冊引擎Nacos怎么使用”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。