摘要:去除了服務的健康檢查模式之前服務的健康檢查模式有三種和分別代表客戶端上報服務端探測和取消健康檢查。在模式下也不能編輯服務的元數據等非實例級別的數據,但是允許創建一個默認配置的服務。
Nacos 1.0.0 是正式 GA 的版本,在架構、功能和API設計上進行了全方位的重構和升級,1.0.0版本標志著Nacos的架構已經穩定,API列表最終確定。升級到1.0.0相比升級到其他版本,需要額外的一些工作,本文專門介紹如何從Nacos 0.8.0以上版本升級到1.0.0 版本的所有步驟和細節。
重要提示Nacos 1.0.0 服務端不兼容 0.8.0 以前的版本,如果您想升級到1.0.0,請先升級服務端到0.8.0版本。同樣的,Nacos 1.0.0 不兼容 0.8.0 以下版本的客戶端訪問。
變更列表 naming 模塊注冊實例支持 ephemeral字段 #502,#677;
去除了服務的健康檢查模式;
注冊實例支持 groupName字段 #269;
去掉了/nacos/v1/ns/api/下的所有接口,轉移到其他URL #651;
增加了Server狀態的設置 #744;
增加Server運行模式的設置 #745;
增加全局推送開關 #634;
支持啟動時數據預熱 #629;
元數據編輯框優化 #479;
config 模塊支持MySQL 8.0 #613;
其他API完整列表開放,模型設計和架構設計文檔發布;
變更詳情 注冊實例支持ephemeral字段Nacos 在 1.0.0版本 instance級別增加了一個ephemeral字段,該字段表示注冊的實例是否是臨時實例還是持久化實例。如果是臨時實例,則不會在 Nacos 服務端持久化存儲,需要通過上報心跳的方式進行包活,如果一段時間內沒有上報心跳,則會被 Nacos 服務端摘除。在被摘除后如果又開始上報心跳,則會重新將這個實例注冊。持久化實例則會持久化被 Nacos 服務端,此時即使注冊實例的客戶端進程不在,這個實例也不會從服務端刪除,只會將健康狀態設為不健康。
同一個服務下可以同時有臨時實例和持久化實例,這意味著當這服務的所有實例進程不在時,會有部分實例從服務上摘除,剩下的實例則會保留在服務下。
另一個需要注意的是,臨時實例和持久化實例,在特定的服務端進行模式下可能不允許進行注冊,這和下面要講的第5個變更有關。
注意事項當從老版本的 Nacos 升級到 Nacos 1.0.0 時,從磁盤加載的實例數據會被置為持久化實例,而只存在于內存里的實例數據將會丟失。
此時若老客戶端再連上 Nacos Server 進行實例注冊,會以當前 Server 的運行模式來設置是否持久化實例。
若老客戶端只是在持續發送客戶端心跳,那么在Server以AP模式運行時,如果實例存在,會自動進行注冊。
去除了服務的健康檢查模式之前服務的健康檢查模式有三種:client、server 和none, 分別代表客戶端上報、服務端探測和取消健康檢查。在控制臺操作的位置如下所示:
在 Nacos 1.0.0 中將把這個配置去掉,改為使用實例的ephemeral來判斷,ephemeral為true對應的是服務健康檢查模式中的 client 模式,為false對應的是 server 模式。
注冊實例支持groupName字段客戶端注冊實例時,可以在方法級別指定要注冊的分組名,這個分組名和服務名是對服務的一個二維的標識,二者共同定位一個服務。一個典型的使用分組的實例如下:
namingServer.registerInstance("nacos.test.1","group1",instance);
不指定分組的接口依然是支持的,此時會在服務端為這個服務分配一個默認的分組:DEFAULT_GROUP。
去掉了/nacos/v1/ns/api/下的所有接口,轉移到其他URL為了讓 Nacos 的 API 分類更加合理,管理更加清晰,原來在/nacos/v1/ns/api/下的接口都會轉移到相應的其他URL下。Nacos 服務發現總體定義了 /instance,/service,/cluster,/health,/operator,/catalog,/raft 等 URL 目錄,后面所有的 openAPI 都會根據其類型放到相應的 URL 下。對用戶造成的影響是一些早期的版本客戶端可能無法在訪問 Nacos 服務端。
注意事項0.8.0及一下版本客戶端都有調用這個 URL 下的接口,0.8.0 只依賴/nacos/v1/ns/api/hello 接口,所以對0.8.0的兼容問題不大。
多語言 SDK 和 DNS-F 需要檢查下調用的接口,及時升級。
增加了Server狀態的設置Nacos 增加了對 Server 狀態的控制,所有的狀態都定義在com.alibaba.nacos.naming.cluster.ServerStatus類里。
各個狀態的含義介紹如下:
UP: Server 一切正常,讀寫請求都會被接受;
DOWN: Server 異常,所有請求會返回 HTTP 503 錯誤;
STARTING: Server 還在啟動中,所有請求返回 HTTP 503 錯誤;
STARTING:Server 還在啟動中,所有請求返回HTTP 503 錯誤;
PAUSED:Server 被人工暫停,區別于 DOWN 可能是系統自己檢測到異常,然后設置 DOWN 狀態,PAUSED 狀態表示當前 Server 可能是沒問題的,只是人工進行了干預;
WRITE_ONLY: 只有非 GET 請求會被接受;
READ_ONLY: 只有 GET 請求會被接受;
用戶可以使用如下接口來修飾集群所有機器的狀態,如果再加上debug=true參數,則只修改當前機器的狀態。
curl-X PUT "$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=overridenServerStatus&value=READ_ONLY"
同時這個狀態是會自適應進行修改的,比如啟動時這個狀態為STARTING,等到數據裝載完畢,則會自動將狀態置為 UP,在運行過程中,如果檢測到系統異常如磁盤滿,則又會將狀態置為DOWN。不過自適應的狀態值優先級要低于使用接口設置的狀態值,因此當你想恢復自適應的狀態調解的時候,記得將接口中overriddenServerStatus設置為空。
增加Server運行模式的設置Server的運行模式,是指 Nacos Server 可以運行在多種模式下,當前支持三種模式:AP、CP和 MIXED 。這里的運行模式,使用的是CAP理論里的C、A和P概念。基于CAP理論,在分布式系統中,數據的一致性、服務的可用性和網絡分區容忍性只能三者選二。一般來說分布式系統需要支持網絡分區容忍性,那么就只能在C和A里選擇一個作為系統支持的屬性。C 的準確定義應該是所有節點在同一時間看到的數據是一致的,而A的定義是所有的請求都會收到響應。
Nacos 支持 AP 和 CP 模式的切換,這意味著 Nacos 同時支持兩者一致性協議。這樣,Nacos能夠以一個注冊中心管理這些生態的服務。不過在Nacos中,AP模式和CP模式的具體含義,還需要再說明下。
AP模式為了服務的可能性而減弱了一致性,因此AP模式下只支持注冊臨時實例。AP 模式是在網絡分區下也能夠注冊實例。在AP模式下也不能編輯服務的元數據等非實例級別的數據,但是允許創建一個默認配置的服務。同時注冊實例前不需要進行創建服務的操作,因為這種模式下,服務其實降級成一個簡單的字符創標識,不在存儲任何屬性,會在注冊實例的時候自動創建。
CP模式下則支持注冊持久化實例,此時則是以 Raft 協議為集群運行模式,因此網絡分區下不能夠注冊實例,在網絡正常情況下,可以編輯服務器別的配置。改模式下注冊實例之前必須先注冊服務,如果服務不存在,則會返回錯誤。
MIXED 模式可能是一種比較讓人迷惑的模式,這種模式的設立主要是為了能夠同時支持臨時實例和持久化實例的注冊。這種模式下,注冊實例之前必須創建服務,在服務已經存在的前提下,臨時實例可以在網絡分區的情況下進行注冊。
使用如下請求進行Server運行模式的設定:
curl -X PUT "$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP"注意事項
何時選擇使用何種模式?一般來說,如果需要在服務級別編輯或者存儲配置信息,那么 CP 是必須要使用的模式,如果不需要存儲服務級別的信息,且服務實例是通過nacos-client注冊,并能夠保持心跳上報,那么就可以選擇AP模式。當前主流的服務如 Spring cloud 和 Dubbo 服務,都適用于AP模式,而K8S服務和DNS服務,則適用于CP模式。AP模式的服務實例可以在CP模式下注冊,例如Zookeeper,但是反過來不能。
切換運行模式,對原有數據不會影響,但是會影響新數據的創建和老數據的更新和刪除。
增加全局推送開關支持了全局推送開關,可以打開或者關閉服務變更的推送,調用接口如下:
curl -X PUT "$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=pushEnabled&value=false"
關閉推送后,客戶端依然會通過輪詢的方式來更新到數據,只是更新的速度沒有推送那么快。
支持啟動時數據預熱在老版本的Nacosz中,只要Server啟動成功就會開始對外提供服務,此時服務的數據并不一定完全加載完成,這樣可能會導致客戶端接收到的數據并不完整。1.0.0增加了數據預熱的邏輯,對于持久化數據,則會等待所有數據從磁盤加載完成,對于臨時實例這樣的非持久化數據,則會等待從其他Server拉取到完整數據。所有數據都準備好后,才會將Server狀態置為UP。
注意事項對于臨時實例的預熱,實現機制是Server在啟動時會從其他Server節點拉取數據,拉取成功則啟動成功,但是當從老版本Server升級到1.0.0時,由于這個拉取全量數據的接口在老版本Server不存在,那么第一個升級的機器將無法拉到任何數據,從而后面升級的機器也無法從第一個升級的機器拉取到數據。此時建議使用調用API將Server的運行狀態設置為WRITE_ONLY,允許客戶端數據逐步匯聚補償上來,但是阻止任何查詢的流量,等集群數據準備好以后,再將這個運行狀態清空,集群自己調整運行狀態,然后就會提供完整服務。
元數據編輯框優化此前的元數據編輯框需要用戶按照指定格式來編輯,容易出錯,如下如所示:
1.0.0將會對服務頁面的元數據編輯框進行優化,在調整編輯框大小的同時,增加語法高亮,方便用戶進行編輯和識別格式問題,一個大概的編輯框預覽圖如下:
支持MySQL 8.0Nacos 1.0.0將支持MySQL 8.0 驅動。
API完整列表開發,模型設計和架構設計文檔發布服務發現和配置管理的完整API列表會發布到官網,同時對于Nacos的數據模型,集群模型,架構設計及模塊設計等文檔也會發布。
除了上面提到的變更,Nacos 1.0.0還進行了代碼的優化和一些bug的修復,完整的變更列表可以參考:https://github.com/alibaba/nacos/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0.0
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/77568.html
摘要:通過本教程的前兩篇基礎教程使用實現服務注冊與發現基礎教程支持的幾種服務消費方式我們已經學會了,如何利用實現服務的注冊與發現。簡介除了實現了服務的注冊發現之外,還將配置中心功能整合在了一起。同時,值必須與上一階段中創建的配置匹配除了或者后綴。 通過本教程的前兩篇: 《Spring Cloud Alibaba基礎教程:使用Nacos實現服務注冊與發現》 《Spring Cloud Ali...
摘要:第二步在應用的配置文件中,增加環境配置第三步啟動應用,我們可以看到日志中打印了,加載的配置文件使用實現在中是用來對做集合管理的重要概念。深入思考上面我們分別利用配置管理功能中的幾個不同緯度來實現多環境的配置管理。 前情回顧: 《Spring Cloud Alibaba基礎教程:使用Nacos實現服務注冊與發現》 《Spring Cloud Alibaba基礎教程:支持的幾種服務消費方...
摘要:殺只雞而已,你拿牛刀來做甚釋義小團隊小項目選擇簡單的配置管理方式就好了,要什么配置中心,純屬沒事找事。,我就啰嗦到這里吧,下面正式介紹作為配置中心是怎么使用的。 前言 在看正文之前,我想請你回顧一下自己待過的公司都是怎么管理配置的,我想應該會有以下幾種方式: 1、硬編碼沒有什么配置不配置的,直接寫在代碼里面,比如使用常量類優勢:對開發友好,開發清楚地知道代碼需要用到什么配置劣勢:涉及秘...
摘要:年月阿里巴巴高級技術專家許真恩慕義發布了首個開源版本,作為的開源實現截止目前已經更新到了的大版本,并且支持大規模生產版本。支持目前幾乎所有主流的微服務生態體系。 前言 6月份阿里開源的Nacos出了1.0.1版本,從去年7月份第一個release版本到現在一直在默默關注 官方的版本規劃為:Nacos從0.8.0開始支持生產可用,1.0版本可大規模生產可用,2.0版本接入k8s、Spri...
閱讀 2337·2019-08-30 15:44
閱讀 1260·2019-08-30 13:01
閱讀 3307·2019-08-30 11:22
閱讀 3093·2019-08-29 15:23
閱讀 1614·2019-08-29 12:22
閱讀 3366·2019-08-26 13:58
閱讀 3439·2019-08-26 12:17
閱讀 3479·2019-08-26 12:16