09 注册配置与协调工具
注册、配置与协调工具掌握应用启动时读什么配置、注册成什么服务、发现谁、监听什么状态，以及失败后回到哪个版本。控制台能打开只证明管理页面存活，不能证明客户端读到了正确环境、配置已经发布、服务实例仍健康，或者多数派还能提交新状态。
从状态模型选择工具
| 工具 | 更适合解决的问题 | 架构判断 |
|---|---|---|
| Nacos | Java 微服务的配置发布与服务注册发现 | namespace/group/dataId 与 service/instance 是两套对象；客户端、控制台和 gRPC 端口必须分清 |
| Consul | 跨语言服务发现、健康检查、DNS 和轻量 KV | agent、datacenter、gossip、Raft、ACL 与许可边界共同决定运维成本 |
| etcd | 强一致 KV、watch、lease 和控制面状态 | revision、事务与 Raft 多数派适合小而关键的元数据，不适合业务大对象或消息流 |
| ZooKeeper | 会话型协调、选主、锁和成员状态 | znode、session、watch、version、ACL 与 ZAB 共同构成协调语义 |
| Apollo | 有审核、发布、灰度、回滚和多环境模型的配置平台 | Portal/AdminService/ConfigService 与 MySQL 形成控制面，release 才是客户端可读事实 |
| Spring Cloud Config | 以 Git/Vault 等后端为事实源的 Spring 配置服务 | repository revision、application/profile/label、客户端导入和 refresh 链路必须一起设计 |
工具之间不是功能越多越好。先判断状态是否需要强一致事务、是否依赖临时会话、是否需要人审发布、客户端是否跨语言、变更是否必须回滚，以及团队能否承担多数派、数据库、Git 或 agent 的长期维护。
从本地实例走到生产拓扑
| 阶段 | 可以证明什么 | 仍然不能证明什么 | 升级动作 |
|---|---|---|---|
| 单进程或单容器 | API、SDK、命名模型和基本权限可用 | 成员故障、数据恢复、网络分区和多数派行为 | 固定版本、目录、端口与隔离对象，保留可重复的正反实验 |
| 开发共享环境 | 多项目隔离、凭证分发、变更回滚和客户端重连可治理 | 生产容量、跨可用区延迟和灾难恢复目标 | 引入 owner、审批、审计、备份、配额和升级窗口 |
| 三节点或平台化部署 | 多数派、选主、成员替换和滚动维护可演练 | 跨地域强一致不会自动获得，依赖数据库或 Git 的工具也没有因此消除外部单点 | 按状态模型设计故障域、恢复点、客户端降级和退出方案 |
Nacos、Consul、etcd 与 ZooKeeper 的高可用依赖成员关系和一致性协议；Apollo 还依赖数据库及三类服务，Spring Cloud Config 还依赖配置仓库和客户端刷新链路。把应用容器扩成三个副本，不等于整个状态链路已经高可用。
一次可信的状态传播
每一步都要保留可观察的状态标识：Nacos 的 namespace/group/dataId，Consul 的 service/check/index，etcd 的 revision，ZooKeeper 的 version 与 zxid，Apollo 的 release，Config Server 的 Git commit/label。缺少这些标识时，“页面显示成功”和“应用已经生效”之间没有可审计的因果链。
故障证据从哪里取
| 问题 | 客户端证据 | 服务端证据 | 判断重点 |
|---|---|---|---|
| 读到旧配置 | 启动日志、本地缓存、读取到的版本标识 | release、revision、Git commit 或配置发布记录 | 是没有发布、没有刷新，还是连接了错误环境 |
| 服务发现为空 | SDK 订阅、DNS 查询、健康检查结果 | instance、catalog、session、lease 与成员状态 | 是注册失败、健康检查失败，还是临时状态已经过期 |
| 写入超时 | 请求 deadline、重试次数、认证错误 | leader、quorum、Raft/ZAB 提交、数据库或仓库错误 | 端口存活不代表多数派或后端仍可写 |
| 权限异常 | 使用的身份、token 来源和目标路径 | policy、role、ACL、namespace 授权与审计日志 | 区分认证失败、无权限和目标对象不存在 |
| 回滚未生效 | 客户端当前值和刷新时间 | 回滚目标、发布版本、Git label 与操作记录 | 回滚的是编辑态、发布态还是仓库提交 |
共同故障面
- 客户端连接了错误 namespace、datacenter、prefix、chroot、env、cluster、profile 或 label，读到的内容合法但属于另一个环境。
- 管理面和数据面端口混用，页面可访问而 SDK、DNS、gRPC、peer 或 watch 链路不通。
- 旧 volume 保留 member、ACL、token、release、myid、revision 或 Git clone，使“重新部署”继续沿用旧世界。
- 配置已经保存但没有发布、客户端没有刷新，或者 watch/长轮询中断后继续使用本地缓存。
- 把密码、PAT、AccessKey、TLS 私钥写进普通配置项、仓库、截图、日志和命令历史。
- 删除 namespace、prefix、znode、release 或仓库分支时没有 owner、影响面、停止条件和恢复快照。
- 多数派丢失、数据库或 Git 后端不可用时，团队只看 HTTP 健康，没有验证读写能力和客户端降级行为。
学习顺序
先在隔离命名空间或前缀中完成一次写入、读取、watch/长轮询、权限拒绝和回滚，再理解单节点为何不能代表高可用。进入三节点或共享环境后，必须继续验证成员故障、多数派、客户端重连、快照恢复、凭证轮换和危险删除的审计链路。跨产品选型时比较一致性、状态模型、恢复点和团队职责，不比较首页功能数量。