注册发现与动态配置：实例和规则变化怎样安全进入请求链
贯通实例注册、心跳租约、客户端缓存、服务选择、优雅上下线、配置导入与刷新，解释动态控制面的陈旧窗口。
Spring Cloud Commons 定义 DiscoveryClient 抽象；Spring Cloud Alibaba 新版本的 Nacos Config 使用 spring.config.import，其迁移边界见 Nacos Quick Start。
注册表保存的是可达候选，不是业务健康证明
实例启动后注册 serviceId、地址、端口和受控元数据，并通过心跳或租约维持存在。注册中心只能根据协议判断实例是否仍活跃，不能证明线程池、数据库或关键依赖可用。把所有健康探针都塞进注册心跳又会让短暂下游抖动频繁摘挂实例，制造调用方缓存和连接池震荡。
消费者通常从 DiscoveryClient 获得实例列表，再由本地 LoadBalancer 选择。列表经过服务端推送、客户端订阅、本地缓存和负载均衡子上下文，多层都可能陈旧。实例已停机但仍在缓存时，调用必须通过连接超时和被动摘除收敛；注册中心暂时不可达时，客户端应在有限时间内使用最后可信列表，而不是立即把所有依赖判空。
优雅上下线是一段时间协议
上线先完成配置加载、连接预热和本地缓存准备，再进入 ready 并注册接流；下线先把实例标记为 draining 或从发现列表移除，等待传播窗口和在途请求结束，最后关闭监听端口。直接先停进程再注销，会让所有持有旧列表的客户端撞到连接错误。
传播窗口应通过观测得出：注册变更到客户端实例列表更新多久，Gateway 和 Feign 的负载缓存多久，长连接何时关闭。滚动发布步长必须让旧实例在这段窗口内继续服务。元数据标签也有相同陈旧问题，灰度标签变化不能假设瞬时全局一致。
配置刷新要发布完整快照
一项业务规则往往由多个键共同构成，例如开关、阈值、白名单和版本。逐键刷新会让请求读到新阈值配旧白名单。应用应把原始配置校验并构造成不可变快照，通过单个原子引用切换；校验失败保留上一版本并告警，不能让半绑定对象进入请求链。
连接池大小、线程数、端口和序列化类型通常不适合无损热更新。配置目录要标记静态、可刷新、需排空和敏感四类属性。刷新事件也可能丢失或重复，因此实例要周期性校验目标版本，指标记录 loadedVersion、refresh result 和版本分布，确保最终收敛。
把同步调用画成预算递减的状态机
设计时为每条边记录 owner、协议、连接模型、超时阶段、重试责任、幂等键、流量上限、降级语义和回滚方式。同步扇出越大，成功率乘积越低，尾延迟取最大值；能异步解耦的非关键副作用不要停留在主请求链。
失败控制必须按依赖隔离
注册中心不可用、无实例、连接池满、连接失败、读取超时、业务拒绝和服务端错误要分型。只有动作未开始或有幂等保障的暂态失败允许重试；结果未知先查询或使用稳定幂等键。限流、隔离和熔断的拒绝应成为可观测结果，不能统一包装成空数据。
同一实例的多个地址也有选择语义
实例可能同时拥有容器地址、宿主地址、管理端口和不同网络区域的可达地址。注册值必须是调用方网络实际可达的通告地址，不能把监听地址或随机网卡直接上报。元数据中的 zone、version、protocol 和 secure 只作为受控选择条件，必须有 schema、默认值和长度限制。
客户端缓存要区分“从未获得任何列表”和“曾有可信列表但控制面暂时失联”。前者通常快速失败，后者可在最大陈旧时间内继续并通过被动失败剔除。陈旧上限到期后进入明确降级，避免控制面长期失联时无限信任已经全部下线的地址。
用两个 Java 状态模型固定决策边界
这两个 Java 17 模型不启动真实注册中心、Gateway 或 RPC Server，而是把本篇的状态、预算和不变量转成确定输出。真实集成测试继续验证客户端协议、自动配置、连接复用、推送延迟与故障时序。
javac --release 17 -Xlint:all -Werror examples/backend-development/microservice/discovery-config/DiscoveryLeaseDemo.java examples/backend-development/microservice/discovery-config/ConfigRefreshDemo.java
java -cp examples/backend-development/microservice/discovery-config DiscoveryLeaseDemo
java -cp examples/backend-development/microservice/discovery-config ConfigRefreshDemoinstances=[a,b] expired=[a] selected=b staleWindowMillis=3000
oldVersion=7 newVersion=8 readersBeforeRefresh=3 atomicSnapshot=true invalidMix=false状态模型输出变化时，要解释对应的服务边界、Deadline、版本或治理不变量为什么改变。集成测试必须主动制造连接已写出后超时、实例列表陈旧、配置刷新一半、半开探测和灰度标签断链。
契约、安全与配置共同决定可运营性
动态配置和发现元数据都可能陈旧。变更必须带版本、owner、范围、过期时间和回滚值，先灰度到少量实例并比较版本分布。会影响线程池、连接池、路由、限流和鉴权的配置要通过不变量校验，失败时保留上一完整快照。
容量与可观测证据要覆盖控制面和数据面
容量计算从入口峰值乘同步扇出和重试上限，得到下游最坏尝试率；再用处理时长估算并发，用消息与 body p99 估算内存和网络。扩容只有在分区、连接池和下游预算允许时才有效。演练应包含注册中心断连、陈旧实例、配置错误、慢依赖、灰度版本异常与整组滚动，而不只是停一个进程。
上线证据包括新旧契约互调、实例排空、Deadline 传播、幂等重试、治理状态机、灰度指标和回滚后的残留任务。完成标准不是“组件控制台显示健康”，而是业务不变量保持、未知结果可查询、故障被限制在预算内并最终收敛。
从开发环境到生产流量要跨过四层验证
第一层是进程内状态模型，验证边界、预算、版本和治理状态迁移；第二层是客户端与真实协议集成，验证自动配置、序列化、连接池、注册缓存和 filter 顺序；第三层是多实例故障测试，在请求写出后断网、实例摘除传播中停机、配置刷新时制造非法版本、半开探测时注入慢调用；第四层是带真实 key 分布和下游容量的灰度压测。只启动一个服务调用另一个服务，无法证明微服务体系可恢复。
测试要保存可反证的断言：旧实例被摘除后持有旧缓存的客户端仍在连接预算内收敛；服务端提交而客户端超时不会重复业务写入；配置版本切换不会出现字段混搭；v2 灰度请求的下游不会随机回到不兼容 v1；熔断恢复不会瞬间把全部流量压回下游。每条断言都对应一个故障窗口和一个持久证据。
依赖拓扑必须有复杂度上限
同步调用链深度、单请求扇出、关键路径依赖数和循环依赖应进入架构门禁。A 同步调用 B、B 又同步调用 A 的运行时循环，会在部分故障时形成线程与重试环；一个请求并行扇出二十个下游，即使单个依赖成功率很高，整体尾延迟和失败概率也会显著上升。服务目录应定期从 trace 与静态契约重建真实依赖图，发现未声明边。
变更和回滚要覆盖控制面残留
滚动发布期间同时存在旧代码、新代码、旧配置、新配置、旧实例缓存和新路由规则。兼容顺序通常是先让消费者接受新旧契约，再发布生产者；先让目标服务接受灰度标签，再由入口产生标签；先部署理解新配置的代码，再发布新键。反向顺序会把一次正常发布变成大范围解析或路由失败。
架构评审要把“自动”翻译成具体责任
“自动发现”要回答实例何时注册、租约多久过期、调用方缓存多久、注册中心失联后使用什么视图；“自动重试”要回答谁重试、什么错误、最多几次、是否换实例、原始 Deadline 和幂等证据在哪里；“自动熔断”要回答统计窗口、异常分类、最小样本、半开探测和降级结果；“自动刷新”要回答配置的原子快照、非法值处理、版本分布和回滚。无法回答这些问题的自动化只是把状态藏进库里。