Spring Cloud 起点：服务发现与配置中心各解决什么

服务有多个实例时，调用者需要知道现在能找谁；同一程序部署到不同环境时，还需要知道使用什么地址和超时。服务发现回答当前有哪些候选实例，配置管理回答这次运行用哪些参数。它们可能依赖同一套基础设施，但解决的问题和失败表现不同，要分别检查。

查到服务地址，还没完成请求。DiscoveryClient 提供服务实例，负载均衡器从中选目标，网络客户端再连接调用。注册列表里有实例，不代表调用者能连到它，也不代表它的数据库正常。实例下线、缓存更新和请求失败之间可能有时间差，所以服务发现之后仍要设计超时和失败恢复。

应用最后用哪个配置值，要把多个来源放在一起看。默认值、配置文件、环境变量、命令行和远程配置可能写了同一个设置，框架会按优先级决定采用哪个，再把它填入程序使用的对象。配置中心写着 500，实际请求却等了两秒，可能是另一个来源覆盖了它、程序对时间单位的理解不同，或旧客户端对象还没更新。排查时同时记录值来自哪里、是哪一版配置，以及哪一个运行实例真正用上了它。

应用启动时先加载配置，再把配置值填入相关 Bean，也就是由 Spring 管理的对象。Config Client 可用 spring.config.import=configserver:http://localhost:8888 读取本地学习用的配置服务器；这里的 localhost 不是生产地址。

加上 optional: 后，连接不上配置服务器也可继续启动，但关键地址和凭据能否缺省，要由业务决定。还要一起检查应用名、profile（选用的配置分组）和 label（配置版本标识）；使用 Git 保存配置时，label 可以指向分支、标签或提交，不能只核对应用名。

运行时发现链路通常包含注册、续约或健康检查、客户端缓存与负载均衡器缓存。不同实现的一致性与失效时限不同，旧地址可能短暂残留。多个发现客户端组合时也未必合并所有实例，例如本篇固定源码中的 getInstances 取第一个非空结果。配置了两个注册中心，不代表请求会自动在两个中心的全部实例中均匀分配。

配置中心改了值，程序不一定马上用上。应用还要收到变更、读入新配置，并让正在使用的对象采用它；有的对象支持更新，有的必须重新创建，还有些修改需要重启。比如超时和重试次数要配套使用，先改一个再改另一个，可能短暂出现“新超时配旧重试数”。可以先准备一份完整的新配置，检查这些值放在一起是否合理，通过后一次切换到这份配置，并保留旧版本，出问题时切回。

固定源码在构造时按 Ordered 规则排序发现客户端，然后 getInstances 顺序查询并返回第一个非空列表。这不是把各来源全部实例加入 Set。优先级靠前的客户端若返回旧但非空的地址，后续客户端的较新结果不会在这个方法里自动补充。排障时应打印启用的客户端与顺序，而不是只看有哪些依赖包。

同一个类里，getServices 会合并各客户端给出的服务名并去重，getInstances 却只返回第一个非空的实例列表。方法看起来都在“查服务”，实际组合结果的方式不同，不能只凭类名推断。服务名出现在目录里，也不代表 getInstances 会从所有注册中心找齐它的节点。

方法的“空结果继续尝试”也不等于“任意异常自动降级”。真实实现中某个客户端抛异常时如何传播，需要沿具体调用链确认；教学模型没有 catch 后假装成功。把连接异常吞成空列表可能提高表面可用性，却丢失注册基础设施正在故障的证据，必须按约定选择并保留诊断信息。

发现结果通常还会被负载均衡层使用，那里可能有健康筛选和独立缓存。本方法既不执行真实 HTTP 请求，也不验证每个下游业务依赖。源码研读的结果应是清晰划分“组合候选、选择候选、实际调用”的职责，并为每层找相应观测信号，避免让一个注册成功日志承担它无法证明的结论。

输入按优先级从高到低排列的配置来源，每个来源有名称与键值映射。每个键采用最先出现的值，同时保留来源名称。空字符串是显式值，不等于缺失；null 值拒绝。此规则是通用教学模型，具体 Spring 来源顺序由框架配置决定。

想解释某个值为什么生效，单独返回合并后的 Map 不够，还需要保存胜出的来源。把每项结果定义为 value 与 source 的不可变组合。高优先级来源先遍历，第一次见到键就写入，之后遇到相同键不覆盖；这样来源追踪与取值遵守同一条决策路径，不会出现值来自 A、标签却显示 B 的错配。

循环不变量是：处理完前 i 个来源后，结果包含这些来源出现过的全部键，每项来自其中优先级最高的那个。进入第 i+1 个来源时，已有键已经有更高优先级结果，保留即可；新键则只能从当前来源得到首次候选。由归纳可知处理完所有来源得到符合定义的唯一结果。

空字符串必须保留，因为它可能表示主动清空显示文案；null 在本题表示非法配置，不能偷偷当成回退默认值。来源名称也要求唯一，避免审计结果无法定位具体输入。完成合并后再执行数值类型、必填字段和跨字段约束校验，这是两个不同阶段：字符串解析成功不代表它是合法超时或安全地址。

E 为所有来源键值项总数，U 为唯一键数，S 为来源数。即使所有来源都是空 Map，也要遍历并去重 S 个来源；每个键值项只检查一次。结果保存 U 项，来源去重集合保存 S 项。若字符串散列与比较不是缓存常数，还须加入键和值处理的字符成本。

选择 Spring Cloud 组件时，先按 Spring Boot 版本找到兼容的发布系列，再用该系列的 BOM 管理依赖。BOM 可以理解为一份集中约定组件版本的清单，避免自己拼出一组“每个都很新、合起来却不兼容”的组件。先确认单体业务和基础网络正常，再逐步加入注册中心与远程配置，方便定位新增问题。敏感配置按凭据管理方式保存；诊断页面可以显示配置来源和版本，日志里不要打印秘密值。

实例健康应分清进程存活、是否愿意接收新流量及真实关键依赖状态。注册中心缓存失效期间仍可能发往旧地址，调用端需要有界超时和安全重试。关机时先停止接收新流量并注销或标记不可用，再等待在途请求排空；仅杀掉进程会把故障检测延迟变成用户错误窗口。

修改配置也要像发布代码一样：先检查改动，记录检查结果和恢复旧版本的方法，再让少量运行实例先使用。用真实请求确认超时、访问地址或限流行为符合预期后，再逐步扩大范围。配置平台显示保存成功，只能说明新版本已写入；有的实例可能还没收到通知，或还在使用旧对象。要确认“全部更新了”，应逐一记录实例标识、实际采用的配置版本和业务验证结果。