注册发现与配置治理

实例会因为发布、扩缩容和故障不断变化，调用方不能依赖固定 IP。服务发现维护“服务名到健康实例”的映射，配置治理则让环境参数在镜像之外受控管理。

服务发现模式

模式	工作方式	常见场景
客户端发现	客户端查询注册中心并选择实例	Spring Cloud + Nacos/Consul/Eureka 等
服务端发现	客户端访问稳定入口，由代理选择实例	Kubernetes Service、负载均衡、Service Mesh

Kubernetes 中 Pod 由 Service 和 DNS 发现，通常不必再为了实例 IP 引入第二套注册中心。若业务还使用 Nacos 等组件，应明确它负责服务发现、配置中心还是两者，避免双注册和健康状态不一致。

健康状态

进程启动
  → 注册或进入 Service 后端
  → Readiness 通过才接流量
  → 发布/退出时先摘流量
  → 等待在途请求
  → 关闭进程并注销

只用 TCP 端口存活作为业务健康可能把尚未加载配置、数据库不可用或线程池耗尽的实例放入流量池。健康检查也不能绑定所有非关键依赖，否则局部依赖抖动会导致所有实例同时被摘除。

配置治理

• 配置按应用、环境和作用域组织，生产配置需要审批和审计。
• 敏感值进入 Secret/KMS，不放普通配置中心明文。
• 动态配置必须声明是否热生效、默认值、校验规则和回滚方式。
• 配置变更应关联发布记录、实例和告警时间线。
• 多实例变更要考虑短时间内新旧配置并存。

常见故障

现象	检查方向
有实例但调用不到	注册信息、健康检查、网络、负载均衡过滤条件
发布后旧实例仍接流量	注销/Readiness、连接复用、DNS/客户端缓存
实例频繁上下线	健康阈值太敏感、GC/CPU、注册中心网络、时钟
配置修改未生效	配置作用域、监听机制、实例版本、是否需重启
全部实例同时异常	错误配置全量推送、共享依赖故障、配置中心不可用

注册中心和配置中心本身也是关键基础设施，需要高可用、权限、备份、容量监控和故障演练。