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

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

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

注冊(cè)實(shí)例支持 ephemeral字段 #502,#677;

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

注冊(cè)實(shí)例支持 groupName字段 #269;

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

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

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

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

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

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

支持MySQL 8.0 #613;

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

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

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

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

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

此時(shí)若老客戶端再連上 Nacos Server 進(jìn)行實(shí)例注冊(cè)，會(huì)以當(dāng)前 Server 的運(yùn)行模式來(lái)設(shè)置是否持久化實(shí)例。

若老客戶端只是在持續(xù)發(fā)送客戶端心跳，那么在Server以AP模式運(yùn)行時(shí)，如果實(shí)例存在，會(huì)自動(dòng)進(jìn)行注冊(cè)。

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

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

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

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

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

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

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

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

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

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

UP: Server 一切正常，讀寫請(qǐng)求都會(huì)被接受；

DOWN: Server 異常，所有請(qǐng)求會(huì)返回 HTTP 503 錯(cuò)誤；

STARTING: Server 還在啟動(dòng)中，所有請(qǐng)求返回 HTTP 503 錯(cuò)誤；

STARTING：Server 還在啟動(dòng)中，所有請(qǐng)求返回HTTP 503 錯(cuò)誤；

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

WRITE_ONLY: 只有非 GET 請(qǐng)求會(huì)被接受；

READ_ONLY: 只有 GET 請(qǐng)求會(huì)被接受；

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

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

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

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

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

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

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

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

使用如下請(qǐng)求進(jìn)行Server運(yùn)行模式的設(shè)定：

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

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

切換運(yùn)行模式，對(duì)原有數(shù)據(jù)不會(huì)影響，但是會(huì)影響新數(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)閉推送后，客戶端依然會(huì)通過(guò)輪詢的方式來(lái)更新到數(shù)據(jù)，只是更新的速度沒(méi)有推送那么快。

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

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

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

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

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

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

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