摘要：去除了服務(wù)的健康檢查模式之前服務(wù)的健康檢查模式有三種和分別代表客戶端上報服務(wù)端探測和取消健康檢查。在模式下也不能編輯服務(wù)的元數(shù)據(jù)等非實例級別的數(shù)據(jù)，但是允許創(chuàng)建一個默認配置的服務(wù)。

Nacos 1.0.0 是正式 GA 的版本，在架構(gòu)、功能和API設(shè)計上進行了全方位的重構(gòu)和升級，1.0.0版本標(biāo)志著Nacos的架構(gòu)已經(jīng)穩(wěn)定，API列表最終確定。升級到1.0.0相比升級到其他版本，需要額外的一些工作，本文專門介紹如何從Nacos 0.8.0以上版本升級到1.0.0 版本的所有步驟和細節(jié)。

Nacos 1.0.0 服務(wù)端不兼容 0.8.0 以前的版本，如果您想升級到1.0.0，請先升級服務(wù)端到0.8.0版本。同樣的，Nacos 1.0.0 不兼容 0.8.0 以下版本的客戶端訪問。

注冊實例支持 ephemeral字段 #502,#677;

去除了服務(wù)的健康檢查模式；

注冊實例支持 groupName字段 #269;

去掉了/nacos/v1/ns/api/下的所有接口，轉(zhuǎn)移到其他URL #651;

增加了Server狀態(tài)的設(shè)置 #744;

增加Server運行模式的設(shè)置 #745;

增加全局推送開關(guān) #634;

支持啟動時數(shù)據(jù)預(yù)熱 #629;

元數(shù)據(jù)編輯框優(yōu)化 #479;

支持MySQL 8.0 #613;

API完整列表開放，模型設(shè)計和架構(gòu)設(shè)計文檔發(fā)布；

Nacos 在 1.0.0版本 instance級別增加了一個ephemeral字段，該字段表示注冊的實例是否是臨時實例還是持久化實例。如果是臨時實例，則不會在 Nacos 服務(wù)端持久化存儲，需要通過上報心跳的方式進行包活，如果一段時間內(nèi)沒有上報心跳，則會被 Nacos 服務(wù)端摘除。在被摘除后如果又開始上報心跳，則會重新將這個實例注冊。持久化實例則會持久化被 Nacos 服務(wù)端，此時即使注冊實例的客戶端進程不在，這個實例也不會從服務(wù)端刪除，只會將健康狀態(tài)設(shè)為不健康。

同一個服務(wù)下可以同時有臨時實例和持久化實例，這意味著當(dāng)這服務(wù)的所有實例進程不在時，會有部分實例從服務(wù)上摘除，剩下的實例則會保留在服務(wù)下。

另一個需要注意的是，臨時實例和持久化實例，在特定的服務(wù)端進行模式下可能不允許進行注冊，這和下面要講的第5個變更有關(guān)。

當(dāng)從老版本的 Nacos 升級到 Nacos 1.0.0 時，從磁盤加載的實例數(shù)據(jù)會被置為持久化實例，而只存在于內(nèi)存里的實例數(shù)據(jù)將會丟失。

此時若老客戶端再連上 Nacos Server 進行實例注冊，會以當(dāng)前 Server 的運行模式來設(shè)置是否持久化實例。

若老客戶端只是在持續(xù)發(fā)送客戶端心跳，那么在Server以AP模式運行時，如果實例存在，會自動進行注冊。

之前服務(wù)的健康檢查模式有三種：client、server 和none, 分別代表客戶端上報、服務(wù)端探測和取消健康檢查。在控制臺操作的位置如下所示：

在 Nacos 1.0.0 中將把這個配置去掉，改為使用實例的ephemeral來判斷，ephemeral為true對應(yīng)的是服務(wù)健康檢查模式中的 client 模式,為false對應(yīng)的是 server 模式。

客戶端注冊實例時，可以在方法級別指定要注冊的分組名，這個分組名和服務(wù)名是對服務(wù)的一個二維的標(biāo)識，二者共同定位一個服務(wù)。一個典型的使用分組的實例如下：

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

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

為了讓 Nacos 的 API 分類更加合理，管理更加清晰，原來在/nacos/v1/ns/api/下的接口都會轉(zhuǎn)移到相應(yīng)的其他URL下。Nacos 服務(wù)發(fā)現(xiàn)總體定義了 /instance,/service,/cluster,/health,/operator,/catalog,/raft 等 URL 目錄，后面所有的 openAPI 都會根據(jù)其類型放到相應(yīng)的 URL 下。對用戶造成的影響是一些早期的版本客戶端可能無法在訪問 Nacos 服務(wù)端。

0.8.0及一下版本客戶端都有調(diào)用這個 URL 下的接口，0.8.0 只依賴/nacos/v1/ns/api/hello 接口，所以對0.8.0的兼容問題不大。

多語言 SDK 和 DNS-F 需要檢查下調(diào)用的接口，及時升級。

Nacos 增加了對 Server 狀態(tài)的控制，所有的狀態(tài)都定義在com.alibaba.nacos.naming.cluster.ServerStatus類里。

各個狀態(tài)的含義介紹如下：

UP: Server 一切正常，讀寫請求都會被接受；

DOWN: Server 異常，所有請求會返回 HTTP 503 錯誤；

STARTING: Server 還在啟動中，所有請求返回 HTTP 503 錯誤；

STARTING：Server 還在啟動中，所有請求返回HTTP 503 錯誤；

PAUSED：Server 被人工暫停，區(qū)別于 DOWN 可能是系統(tǒng)自己檢測到異常，然后設(shè)置 DOWN 狀態(tài)，PAUSED 狀態(tài)表示當(dāng)前 Server 可能是沒問題的，只是人工進行了干預(yù)；

WRITE_ONLY: 只有非 GET 請求會被接受；

READ_ONLY: 只有 GET 請求會被接受；

用戶可以使用如下接口來修飾集群所有機器的狀態(tài)，如果再加上debug=true參數(shù),則只修改當(dāng)前機器的狀態(tài)。

curl-X PUT
"$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=overridenServerStatus&value=READ_ONLY"

同時這個狀態(tài)是會自適應(yīng)進行修改的，比如啟動時這個狀態(tài)為STARTING,等到數(shù)據(jù)裝載完畢，則會自動將狀態(tài)置為 UP,在運行過程中，如果檢測到系統(tǒng)異常如磁盤滿，則又會將狀態(tài)置為DOWN。不過自適應(yīng)的狀態(tài)值優(yōu)先級要低于使用接口設(shè)置的狀態(tài)值，因此當(dāng)你想恢復(fù)自適應(yīng)的狀態(tài)調(diào)解的時候，記得將接口中overriddenServerStatus設(shè)置為空。

Server的運行模式，是指 Nacos Server 可以運行在多種模式下，當(dāng)前支持三種模式：AP、CP和 MIXED 。這里的運行模式，使用的是CAP理論里的C、A和P概念。基于CAP理論，在分布式系統(tǒng)中，數(shù)據(jù)的一致性、服務(wù)的可用性和網(wǎng)絡(luò)分區(qū)容忍性只能三者選二。一般來說分布式系統(tǒng)需要支持網(wǎng)絡(luò)分區(qū)容忍性，那么就只能在C和A里選擇一個作為系統(tǒng)支持的屬性。C 的準(zhǔn)確定義應(yīng)該是所有節(jié)點在同一時間看到的數(shù)據(jù)是一致的，而A的定義是所有的請求都會收到響應(yīng)。

Nacos 支持 AP 和 CP 模式的切換，這意味著 Nacos 同時支持兩者一致性協(xié)議。這樣，Nacos能夠以一個注冊中心管理這些生態(tài)的服務(wù)。不過在Nacos中，AP模式和CP模式的具體含義，還需要再說明下。

AP模式為了服務(wù)的可能性而減弱了一致性，因此AP模式下只支持注冊臨時實例。AP 模式是在網(wǎng)絡(luò)分區(qū)下也能夠注冊實例。在AP模式下也不能編輯服務(wù)的元數(shù)據(jù)等非實例級別的數(shù)據(jù)，但是允許創(chuàng)建一個默認配置的服務(wù)。同時注冊實例前不需要進行創(chuàng)建服務(wù)的操作，因為這種模式下，服務(wù)其實降級成一個簡單的字符創(chuàng)標(biāo)識，不在存儲任何屬性，會在注冊實例的時候自動創(chuàng)建。

CP模式下則支持注冊持久化實例，此時則是以 Raft 協(xié)議為集群運行模式，因此網(wǎng)絡(luò)分區(qū)下不能夠注冊實例，在網(wǎng)絡(luò)正常情況下，可以編輯服務(wù)器別的配置。改模式下注冊實例之前必須先注冊服務(wù)，如果服務(wù)不存在，則會返回錯誤。

MIXED 模式可能是一種比較讓人迷惑的模式，這種模式的設(shè)立主要是為了能夠同時支持臨時實例和持久化實例的注冊。這種模式下，注冊實例之前必須創(chuàng)建服務(wù)，在服務(wù)已經(jīng)存在的前提下，臨時實例可以在網(wǎng)絡(luò)分區(qū)的情況下進行注冊。

使用如下請求進行Server運行模式的設(shè)定：

curl -X PUT
"$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP"

何時選擇使用何種模式？一般來說，如果需要在服務(wù)級別編輯或者存儲配置信息，那么 CP 是必須要使用的模式，如果不需要存儲服務(wù)級別的信息，且服務(wù)實例是通過nacos-client注冊，并能夠保持心跳上報，那么就可以選擇AP模式。當(dāng)前主流的服務(wù)如 Spring cloud 和 Dubbo 服務(wù)，都適用于AP模式，而K8S服務(wù)和DNS服務(wù)，則適用于CP模式。AP模式的服務(wù)實例可以在CP模式下注冊，例如Zookeeper,但是反過來不能。

切換運行模式，對原有數(shù)據(jù)不會影響，但是會影響新數(shù)據(jù)的創(chuàng)建和老數(shù)據(jù)的更新和刪除。

支持了全局推送開關(guān)，可以打開或者關(guān)閉服務(wù)變更的推送，調(diào)用接口如下：

curl -X PUT
"$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=pushEnabled&value=false"

關(guān)閉推送后，客戶端依然會通過輪詢的方式來更新到數(shù)據(jù)，只是更新的速度沒有推送那么快。

在老版本的Nacosz中，只要Server啟動成功就會開始對外提供服務(wù)，此時服務(wù)的數(shù)據(jù)并不一定完全加載完成，這樣可能會導(dǎo)致客戶端接收到的數(shù)據(jù)并不完整。1.0.0增加了數(shù)據(jù)預(yù)熱的邏輯，對于持久化數(shù)據(jù)，則會等待所有數(shù)據(jù)從磁盤加載完成，對于臨時實例這樣的非持久化數(shù)據(jù)，則會等待從其他Server拉取到完整數(shù)據(jù)。所有數(shù)據(jù)都準(zhǔn)備好后，才會將Server狀態(tài)置為UP。

對于臨時實例的預(yù)熱，實現(xiàn)機制是Server在啟動時會從其他Server節(jié)點拉取數(shù)據(jù)，拉取成功則啟動成功，但是當(dāng)從老版本Server升級到1.0.0時，由于這個拉取全量數(shù)據(jù)的接口在老版本Server不存在，那么第一個升級的機器將無法拉到任何數(shù)據(jù)，從而后面升級的機器也無法從第一個升級的機器拉取到數(shù)據(jù)。此時建議使用調(diào)用API將Server的運行狀態(tài)設(shè)置為WRITE_ONLY,允許客戶端數(shù)據(jù)逐步匯聚補償上來，但是阻止任何查詢的流量，等集群數(shù)據(jù)準(zhǔn)備好以后，再將這個運行狀態(tài)清空，集群自己調(diào)整運行狀態(tài)，然后就會提供完整服務(wù)。

此前的元數(shù)據(jù)編輯框需要用戶按照指定格式來編輯，容易出錯，如下如所示：

1.0.0將會對服務(wù)頁面的元數(shù)據(jù)編輯框進行優(yōu)化，在調(diào)整編輯框大小的同時，增加語法高亮，方便用戶進行編輯和識別格式問題，一個大概的編輯框預(yù)覽圖如下：

Nacos 1.0.0將支持MySQL 8.0 驅(qū)動。

服務(wù)發(fā)現(xiàn)和配置管理的完整API列表會發(fā)布到官網(wǎng)，同時對于Nacos的數(shù)據(jù)模型，集群模型，架構(gòu)設(shè)計及模塊設(shè)計等文檔也會發(fā)布。

除了上面提到的變更，Nacos 1.0.0還進行了代碼的優(yōu)化和一些bug的修復(fù)，完整的變更列表可以參考：https://github.com/alibaba/nacos/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0.0