Nacos：注册成功、健康与配置生效是三个不同事实
provider注册返回成功，只说明目录收到注册意图；实例健康是另一套检查；consumer真正把请求送到并得到响应又是第三件事。配置发布同理：控制面提交成功不等于任何实例已切换运行快照。本页按注册路径→配置发现→混版风险展开。
版本固定 2.4.3。会话资格与临时节点清理的协议对比见ZooKeeper协调与会话恢复；注册目录如何被调用方消费、重试与截止时间见Dubbo调用链与服务治理和超时重试、熔断限流降级。
本页原码基线是 2.4.3；下文新实验使用 2.5.5 server/client，不是把不同 tag 拼成同一次调用链。2026-10-29 的 2.5.5 发行说明列出完整集群重启时实例丢失修复、gRPC 更新和路径/主动 HTTP 健康检查校验；历史 2.4.3 只用于理解源码，不代表生产选型。SCA 2025.1.0.0 的 3.1.1 client 是另一条集成基线，见 SCA 2025.1.0.0 版本说明。
可复制的发布、订阅与实例注册
下面使用原生 2.x Java SDK；依赖 com.alibaba.nacos:nacos-client:2.5.5，服务端也固定 2.5.5。完整可运行入口与关闭、异常处理见实验。serverAddr 是服务端 HTTP 基础端口，2.x Java 客户端还需要能访问该端口加 1000 的 gRPC 端口；本机实验明确绑定回环，生产环境需按实际网络、认证和 TLS 部署。下例省略监听器对象的具体解析实现，不能把控制面的文本校验误当业务校验：
Properties p = new Properties();
p.put(PropertyKeyConst.SERVER_ADDR, "127.0.0.1:18848");
ConfigService config = NacosFactory.createConfigService(p);
NamingService naming = NacosFactory.createNamingService(p);
config.publishConfig("order-limits", "STUDY", "limit=10");
String text = config.getConfig("order-limits", "STUDY", 5000); // 毫秒
config.addListener("order-limits", "STUDY", listener);
Instance instance = new Instance();
instance.setIp("127.0.0.1"); instance.setPort(19080);
instance.setEphemeral(true); instance.setEnabled(true); instance.setHealthy(true);
naming.registerInstance("order-service", "STUDY", instance);
naming.subscribe("order-service", "STUDY", event -> observe(event));
// 停机先从入口摘流并注销，传播期间仍处理旧目录请求；确认后排空并关闭。
naming.deregisterInstance("order-service", "STUDY", instance);
naming.shutDown(); config.shutDown();dataId/group/namespace 与 service/group/namespace 各自构成配置与服务的身份；同名不等于同一资源。上例未设置 namespace，使用 public；group 显式为 STUDY，避免默认 DEFAULT_GROUP 混淆。端口 19080 是实例声明地址，Nacos 不替应用开启业务监听。getConfig 的 5000 是该次读取超时毫秒，不是刷新间隔；监听回调到达后要解析、校验并整体替换。退出路径应使用 finally 关闭客户端；实验以唯一 ID 清理自己的配置及实例，生产不可照抄示例中的无认证设置。
本地配置来源与授权边界
2.5.5 NacosConfigService.getConfigInner 的读取顺序是：先读人工维护的 failover 文件；不存在时向服务端请求；若服务端请求抛 NO_RIGHT 则继续抛错，其他 NacosException 才尝试自动保存的 snapshot。failover 可在服务恢复后仍覆盖服务端值，直到文件移除；snapshot 并不代表当前最新决定。两者与业务代码里经过验证的最后有效对象是不同层次，路径和权限、磁盘加密与清理都应纳入部署方案。snapshot 能否使用还取决于本机是否曾保存相应数据；不要假定首次启动离线也有值。
2.5.5 随包配置默认 nacos.core.auth.enabled=false，这是方便启动的默认值，不是安全部署；启用内置认证要配置服务间身份与 token secret、用户和角色权限，并限制网络入口，密钥经受控渠道注入和轮换。权限缓存配置与 token 生命周期造成撤权传播窗口，具体行为按认证文档及部署版本核查。namespace 是逻辑资源分组，不自动提供租户隔离；TLS、服务端鉴权、资源级授权和生产密钥轮换在单机实验中未验证。禁止将公共监听的无认证服务视为生产配置。
注册信息、健康状态与可调用是三个层次
Nacos注册信息、健康状态和应用真正可接收请求是三个层次。实例已注册不代表依赖已就绪；目录中存在也不代表网络可达。consumer使用本地服务视图发起RPC，因此注册中心短暂不可用与业务调用不可用并不完全同步。目录缓存允许旧视图存活，也带来下线传播窗口：provider已停止，consumer仍按旧目录发起调用，失败后由调用可靠性机制兜底。
命名空间、group和service组成服务身份，cluster与metadata参与路由；配置使用namespace、group、dataId区分。它们不能仅凭字符串相同就与业务租户权限等价。认证、访问控制和环境隔离必须在控制面明确实施，不能把命名空间当安全边界。
两条注册路径：临时实例改内存状态，持久实例走一致性协议
基线2.4.3临时实例实现的registerInstance先校验实例与service类型，获取client，更新其发布实例与revision，再发布注册/元数据事件。它不是“每次注册都直接写一条Raft日志”的统一模型。临时实例与连接/心跳生命周期有关；断连到清理有检测和传播时延。
持久实例实现使用持久客户端与一致性处理路径：service/instance/clientId序列化成ADD WriteRequest后交给protocol.write。必须沿该类及其调用的持久操作处理器阅读，不能把临时实例的内存更新行为直接当持久状态的写协议。单独找到registerInstance方法并不足以解释整条一致性链。
原码：临时实例注册更新状态再发布事件
原码连续摘录（仅统一公共缩进，截取方法局部）：EphemeralClientOperationServiceImpl.java，2.4.3，L56–L74。
public void registerInstance(Service service, Instance instance, String clientId) throws NacosException {
NamingUtils.checkInstanceIsLegal(instance);
Service singleton = ServiceManager.getInstance().getSingleton(service);
if (!singleton.isEphemeral()) {
throw new NacosRuntimeException(NacosException.INVALID_PARAM,
String.format("Current service %s is persistent service, can't register ephemeral instance.",
singleton.getGroupedServiceName()));
}
Client client = clientManager.getClient(clientId);
checkClientIsLegal(client, clientId);
InstancePublishInfo instanceInfo = getPublishInfo(instance);
client.addServiceInstance(singleton, instanceInfo);
client.setLastUpdatedTime();
client.recalculateRevision();
NotifyCenter.publishEvent(new ClientOperationEvent.ClientRegisterServiceEvent(singleton, clientId));
NotifyCenter
.publishEvent(new MetadataEvent.InstanceMetadataEvent(singleton, instanceInfo.getMetadataId(), false));
}先校验服务与实例，若服务并非ephemeral则抛异常；随后获取并检查client，写入实例、更新时刻与revision，再发布注册与元数据事件。事件发布不等于所有消费者已收到并切换连接；持久实例也不是走同一状态存储分支，因此不能把Nacos全部数据都笼统称为AP。
原码对照：持久实例进入一致性协议写入
原码连续摘录（仅统一公共缩进，截取方法局部）：PersistentClientOperationServiceImpl.java，2.4.3，L105–L126。
public void registerInstance(Service service, Instance instance, String clientId) {
Service singleton = ServiceManager.getInstance().getSingleton(service);
if (singleton.isEphemeral()) {
throw new NacosRuntimeException(NacosException.INVALID_PARAM,
String.format("Current service %s is ephemeral service, can't register persistent instance.",
singleton.getGroupedServiceName()));
}
final InstanceStoreRequest request = new InstanceStoreRequest();
request.setService(service);
request.setInstance(instance);
request.setClientId(clientId);
final WriteRequest writeRequest = WriteRequest.newBuilder().setGroup(group())
.setData(ByteString.copyFrom(serializer.serialize(request))).setOperation(DataOperation.ADD.name())
.build();
try {
protocol.write(writeRequest);
Loggers.RAFT.info("Client registered. service={}, clientId={}, instance={}", service, clientId, instance);
} catch (Exception e) {
throw new NacosRuntimeException(NacosException.SERVER_ERROR, e);
}
}与临时实例路径相反，ephemeral服务会被拒绝。持久注册把service/instance/clientId序列化成ADD WriteRequest，再protocol.write；本实现注入的协议路径需继续追到一致性实现，不能把上一段内存状态更新和事件发布复制成它的保证。协议写入失败转换为SERVER_ERROR，客户端仍要分析超时未知结果。
教学时序如下，它是行为分解而非完整源码：
客户端注册意图 → 服务端检查实例类型
→ 更新对应客户端/服务状态 → 服务端同步与订阅事件
→ consumer接收服务视图 → 更新本地目录 → 新请求选择provider其中任何一段都有延迟；provider关机后最后一次成功推送与consumer当前视图可能不同。正确恢复需同时观察注册状态、健康检查、客户端连接、订阅revision和实际调用错误。
2.x Java 客户端临时实例走 gRPC 连接、注册 redo 和重连路径；旧 HTTP 客户端的心跳方式不能直接套用为“所有 2.x 注册都每 5 秒发一个业务心跳”。持久实例的健康检查方式依服务配置和版本而定；临时连接断开、主动注销、实例健康变化与 enabled 下线是不同事件。客户端本地缓存可使调用暂时继续，但目录里仍有地址不保证服务活着。计划停机应先标记不就绪、从网关等入口摘流并更新/注销目录；传播期间继续处理旧目录发来的请求，确认入口与消费者不再选中后再停止接新请求、排空在途并退出。连接池、网关缓存和已发出的调用仍需独立排空。控制台更新或注销成功并不证明所有消费者已经停止选中该实例。
对于 2.4.3 NamingGrpcClientProxy，临时注册先缓存 redo 数据，再发送注册请求；连接监听器在恢复后驱动重做。重复注册恢复的是目录意图，不证明期间请求成功，也不应假设所有订阅者同时完成刷新。定位时对照注册响应、服务端实例列表、客户端订阅事件/当前目录、业务成功率与连接状态；恢复后核对服务端列表和实际调用，再确认旧实例不再被选中。
配置变更是客户端比对出来的快照切换
配置不会由服务端直接写进业务对象：2.4.3 的客户端为每个 dataId 管理 CacheData，并通过 gRPC 注册监听与摘要比对。服务端变化通知会唤醒客户端，客户端再拉取内容并调用监听器；重连和周期性检查提供重新比对路径。应用是否验证并切换对象仍由应用负责，不能简化为只有客户端轮询，也不能把通知等同于业务生效。
原码：客户端按快照一致性筛选要比对的配置
原码连续摘录（仅统一公共缩进，截取方法局部）：ClientWorker.java，2.4.3，L817–L842。
synchronized (cache) {
checkLocalConfig(cache);
// check local listeners consistent.
if (cache.isConsistentWithServer()) {
cache.checkListenerMd5();
if (!needAllSync) {
continue;
}
}
// If local configuration information is used, then skip the processing directly.
if (cache.isUseLocalConfigInfo()) {
continue;
}
if (!cache.isDiscard()) {
List<CacheData> cacheDatas = listenCachesMap.computeIfAbsent(String.valueOf(cache.getTaskId()),
k -> new LinkedList<>());
cacheDatas.add(cache);
} else {
List<CacheData> cacheDatas = removeListenCachesMap.computeIfAbsent(
String.valueOf(cache.getTaskId()), k -> new LinkedList<>());
cacheDatas.add(cache);
}这段循环先调用 checkLocalConfig 检查手工维护的 failover 文件；与服务端一致的监听缓存先检查监听器 MD5，未要求全量同步时跳过；使用 failover 的条目跳过服务端监听比对；isDiscard 的进入移除监听分支。这里的 isUseLocalConfigInfo 指 failover 文件，不是自动保存的 snapshot。固定版本 checkLocalConfig 说明文件创建、修改和删除如何切换；因此不能仅凭这段代码证明断线时自动 snapshot 的读取。
由此得到配置生效的正确工程形状：发布成功只代表控制面接受了新文本；每个实例的生效时刻是它各自完成比对、拉取、解析、校验并原子替换运行对象的时刻。应用侧应校验配置、构建完整新快照、一次性替换引用，并保留最后一个有效版本；解析或校验失败时继续用旧快照运行并显式告警，不要把半解析对象留在运行态。监听回调线程不做耗时网络调用，慢动作交给有界队列。
本地数据既救人也埋雷：应用中最后有效对象、客户端自动保存的 snapshot 和人工维护的 failover 文件是三种不同状态。控制面故障时它们可能使实例继续使用旧配置；但若密钥已被安全侧撤销、特性开关被强制关闭，旧值也可能延续已失效的决定。区分“可用性优先的目录数据”与“必须强撤销的授权事实”，后者不能只靠配置快照存活。
多dataId发布与混版风险
一次业务变更常横跨多个dataId：规则与阈值、路由与限流。客户端逐dataId发现变化，不保证同时看到两个新版本。若rules已切到v2而limits仍是v1，运行对象就是混版——每个都“合法”，组合未被任何版本测试过。回滚更危险：旧文本可能已与新schema不兼容，必须校验可读范围而不是盲目发布旧版本号。密钥轮换通常先允许新旧双读，再切写，最后移除旧值。
让每个实例内部避免混版：把相关内容放进同一配置文档，或用版本manifest声明这批dataId应到达的版本与内容摘要，客户端凑齐且校验通过才整体切换，缺件等待、摘要不符拒绝。两种方式均不保证所有实例在同一时刻切换：灰度期需要兼容新旧版本，按实例上报的版本与错误率判断是否继续或回滚。换schema时同时准备可回滚的旧格式版本。
故障与容量推演
1万个实例每30秒发生一次有效状态变化，平均约333次/秒；若每个服务有100个订阅者，推送和处理量可能再放大，不能只看注册QPS。全量恢复风暴还包含序列化、本地缓存、路由计算与重连，需抖动、限速及快照/增量策略。
注册中心故障但provider健康时，可在明确失效策略下使用缓存；若provider已撤销权限或被隔离，继续使用缓存又可能不安全。比较服务发现目录的可用性诉求与授权撤销的强一致诉求，分别选策略，不共用一套缓存过期时间。
以订单服务为例：200 个应用实例，每分钟最多发布一次规则，要求每个实例内部 rules 与 limits 同版，发布后 2 分钟内统计未生效实例，任何授权撤销不能只依赖旧配置。方案 A 将两项放入一份文档：单实例读取和校验简单，但文档变大、独立变更耦合；方案 B 多 dataId 加 manifest：可复用独立内容，但维护摘要、等待和回收版本的成本更高。两者都不保证跨实例同时切换；发布者负责兼容与回滚，应用负责原子替换与上报版本，运维负责对账、限速、故障恢复。若 2 分钟窗口超时，暂停下一批并按实例查询连接、监听和校验错误；修复后重发/回滚并核对版本分布。这个窗口是示例目标，不是 Nacos SLA，也未做负载实测。
验证：有限模型与真实集群分别证明什么
先运行完整实验脚本，仅需Python标准库：
python3 labs/middleware-senior/reliability_lab.py config --json模型输入三份文本：合法v1、非法v2（limit类型错误）、合法v3。预期revise序列APPLIED(1) → REJECTED(1) → APPLIED(3)：非法输入在解析校验阶段被拒，运行态保留v1，不出现“改到一半”的中间对象；故意演示的逐字段部分变更会留下rules='new'而limit仍为10的坏运行时，说明try-catch救不回已修改的对象。分批到达的两个dataId先给出mixed={rules:2, limits:1}混版；换成manifest待齐校验后，三步WAITING → HASH_CONFLICT(内容摘要不符) → APPLIED(2)，最终快照{version:2, rules:'new', limit:20}一次切换。输出model=finite-application-snapshot-not-nacos-server。
此前公开CLI及断言已运行，结果符合以上预期。它验证的是应用侧解析/校验/切换契约，不是Nacos服务端实现；完整源码核对见实验入口。
真实单机实验：发布、目录注销与重启恢复
Nacos 实验的公开入口是 python3 labs/nacos/run.py，需要先按 README 准备固定服务端包和依赖。实验使用 2.5.5 独立服务和同版本客户端，在 macOS arm64、Liberica JDK 21.0.11 运行：发布 limit=10 后读取；发布 limit=bad，监听器拒绝并保留应用有效值；发布 limit=20 后切换；临时实例注册、注销、再注册；停止服务期间应用对象仍为 20；重启后先通过服务端 HTTP 接口确认实例重新出现，再由另一个 provider 客户端注册第二个地址，验证 consumer 的目录变为两个，最后发布并收到 30。实验退出码 0，清理实例和配置；实际输入、端口及结果见证据。
初次失败包括缺 SLF4J API、发布后即时读取断言不成立；独立复核后发现 consumer 本地视图计数可能保持旧缓存，新增第二实例的第一次尝试仍未达到两个，未把失败写为通过。最终用独立 provider 客户端注册第二地址以检查新目录。发布返回不替代读取证据，也不据该次等待推导普遍可见性上限。服务故障通过停止单机进程实现，非模拟网络分区；断线期间验证的是应用对象，不证明客户端 snapshot 的离线读取或业务请求可用。
在隔离2.4.3集群准备两个provider、一个consumer。记录注册返回时刻、服务端视图、consumer目录版本、第一次调用成功；下线一个provider，持续请求并记录仍被选中的时间。再仅隔离consumer到注册中心的连接，provider保持可达，观察缓存期间业务行为与恢复后的目录更新；断开server全部连接，观察临时实例清理时延与重连后恢复。
配置实验发布合法v1、格式错误v2、兼容v3，要求运行态保留v1直到v3验证通过；双dataId按相反顺序到达，验证是否产生混合状态，再用manifest方式复测。双 dataId 的真实 Nacos 多实例实验与上段跨主机分区均未运行，预期来自模型，不冒充实测。
架构师变化条件
由单区扩成跨地域时，比较控制数据复制成本、当地缓存新鲜度、失联策略与权限撤销期限。将配置中心当作实时业务数据库会把全量推送、持久性和事务需求混在一起；应保持控制面小而稳定，并为配置错误单独设计保护（灰度发布、快速回滚、可观测的生效版本分布）。
若从ZooKeeper迁移到Nacos，要按数据类型与客户端缓存验证：ZK临时节点随会话关闭而服务端清理，Nacos临时实例随连接/心跳由检测任务清理，时延模型不同；不能把znode事件一比一映射成实例事件就宣称等价。验收证据包括注册/健康/目录版本时间线、断连期间行为、配置生效分布与撤销传播。
闭卷验收
本页 9 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。