Nacos 1.0.0 功能預覽

時間 2019-12-07

標籤 nacos 1.0.0 功能預覽简体版

原文原文鏈接

Nacos 1.0.0 是正式 GA 的版本，在架構、功能和API設計上進行了全方位的重構和升級，1.0.0版本標誌着Nacos的架構已經穩定，API列表最終肯定。升級到1.0.0相比升級到其餘版本，須要額外的一些工做，本文專門介紹如何從Nacos 0.8.0以上版本升級到1.0.0 版本的全部步驟和細節。git

重要提示

Nacos 1.0.0 服務端不兼容 0.8.0 之前的版本，若是您想升級到1.0.0，請先升級服務端到0.8.0版本。一樣的，Nacos 1.0.0 不兼容 0.8.0 如下版本的客戶端訪問。github

變動列表

naming 模塊

config 模塊

支持MySQL 8.0 #613;

其餘

API完整列表開放，模型設計和架構設計文檔發佈；

變動詳情

註冊實例支持ephemeral字段

Nacos 在 1.0.0版本 instance級別增長了一個ephemeral字段，該字段表示註冊的實例是不是臨時實例仍是持久化實例。若是是臨時實例，則不會在 Nacos 服務端持久化存儲，須要經過上報心跳的方式進行包活，若是一段時間內沒有上報心跳，則會被 Nacos 服務端摘除。在被摘除後若是又開始上報心跳，則會從新將這個實例註冊。持久化實例則會持久化被 Nacos 服務端，此時即便註冊實例的客戶端進程不在，這個實例也不會從服務端刪除，只會將健康狀態設爲不健康。api

同一個服務下能夠同時有臨時實例和持久化實例，這意味着當這服務的全部實例進程不在時，會有部分實例從服務上摘除，剩下的實例則會保留在服務下。服務器

另外一個須要注意的是，臨時實例和持久化實例，在特定的服務端進行模式下可能不容許進行註冊，這和下面要講的第5個變動有關。網絡

注意事項

當從老版本的 Nacos 升級到 Nacos 1.0.0 時，從磁盤加載的實例數據會被置爲持久化實例，而只存在於內存裏的實例數據將會丟失。
此時若老客戶端再連上 Nacos Server 進行實例註冊，會以當前 Server 的運行模式來設置是否持久化實例。
若老客戶端只是在持續發送客戶端心跳，那麼在Server以AP模式運行時，若是實例存在，會自動進行註冊。

去除了服務的健康檢查模式

以前服務的健康檢查模式有三種：client、server 和none, 分別表明客戶端上報、服務端探測和取消健康檢查。在控制檯操做的位置以下所示：架構

在 Nacos 1.0.0 中將把這個配置去掉，改成使用實例的ephemeral來判斷，ephemeral爲true對應的是服務健康檢查模式中的 client 模式,爲false對應的是 server 模式。curl

註冊實例支持groupName字段

客戶端註冊實例時，能夠在方法級別指定要註冊的分組名，這個分組名和服務名是對服務的一個二維的標識，兩者共同定位一個服務。一個典型的使用分組的實例以下：分佈式

namingServer.registerInstance("nacos.test.1","group1",instance);

不指定分組的接口依然是支持的，此時會在服務端爲這個服務分配一個默認的分組：DEFAULT_GROUP。ide

去掉了/nacos/v1/ns/api/下的全部接口，轉移到其餘URL

爲了讓 Nacos 的 API 分類更加合理，管理更加清晰，原來在/nacos/v1/ns/api/下的接口都會轉移到相應的其餘URL下。Nacos 服務發現整體定義了 /instance,/service,/cluster,/health,/operator,/catalog,/raft 等 URL 目錄，後面全部的 openAPI 都會根據其類型放到相應的 URL 下。對用戶形成的影響是一些早期的版本客戶端可能沒法在訪問 Nacos 服務端。post

注意事項

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,容許客戶端數據逐步匯聚補償上來，可是阻止任何查詢的流量，等集羣數據準備好之後，再將這個運行狀態清空，集羣本身調整運行狀態，而後就會提供完整服務。