Nacos 1.0.0 功能预览

本文来自于我的个人主页：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 版本的所有步骤和细节。

重要提示

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 服务端，此时即使注册实例的客户端进程不在，这个实例也不会从服务端删除，只会将健康状态设为不健康。

ephemeral字段

同一个服务下可以同时有临时实例和持久化实例，这意味着当这服务的所有实例进程不在时，会有部分实例从服务上摘除，剩下的实例则会保留在服务下。

另一个需要注意的是，临时实例和持久化实例，在特定的服务端进行模式下可能不允许进行注册，这和下面要讲的第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类里。

Server状态设置

各个状态的含义介绍如下：

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

1.0.0将会对服务页面的元数据编辑框进行优化，在调整编辑框大小的同时，增加语法高亮，方便用户进行编辑和识别格式问题，一个大概的编辑框预览图如下：

元数据编辑框优化2

支持MySQL 8.0

Nacos 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