选择云原生应用服务发现与配置管理方案，先要区分两个问题：服务发现回答“服务实例在哪里”，配置管理回答“应用运行时使用什么参数”。两者可以由同一套系统承担，也可以分开建设。下面按职责边界和运维复杂度比较五种常见方案。
先看五种方案的差异
| 方案 | 服务发现 | 配置管理 | 复杂度与适用条件 |
|---|---|---|---|
| Kubernetes 原生能力 | Service 提供稳定访问入口，集群 DNS 解析服务名 | ConfigMap 管理非敏感配置，Secret 保存敏感数据 | 集群内应用首选，组件少；复杂的动态配置发布和跨集群治理需要补充能力 |
| Nacos | 注册、发现服务实例 | 集中管理配置，支持监听配置变化 | 适合希望用一套平台管理服务与配置的团队；需要部署、备份并维护 Nacos 集群 |
| Consul | 服务目录与健康检查 | 可通过 KV 存储参数，但应用侧仍需处理读取和更新 | 适合需要跨环境服务目录或已采用 Consul 生态的团队；配置体验通常不如专用配置平台完整 |
| Eureka + Spring Cloud Config | Eureka 注册与发现 | Spring Cloud Config 从外部配置源提供配置 | 适合已有 Spring Cloud 应用；职责拆分明确，但要维护两类服务及其可用性 |
| etcd 自建控制面 | 可保存服务元数据，由自建组件实现发现 | 键值存储供控制器或应用读取 | 适合有控制面开发和运维能力的团队；灵活度高，开发、权限和故障处理成本也最高 |
按现有架构选择，而不是追求功能最多
应用主要运行在单个集群
优先评估 Kubernetes 原生方案。应用通过 Service 名称访问依赖服务，不必把 Pod 地址写入配置；Pod 替换后，稳定入口仍由 Service 提供。普通参数放入 ConfigMap，凭据放入 Secret，并限制读取权限。注意，作为环境变量注入的值通常不会在进程运行期间自动变化；配置文件挂载更新后，应用也必须具备重新读取或重启机制。
需要独立的注册配置平台
若服务不仅在容器编排集群内运行，或团队需要统一管理多环境配置，可比较 Nacos 与 Consul。Nacos 更直接覆盖注册发现和配置发布；Consul 的强项是服务目录与健康检查，KV 适合较简单的参数存放。选型时要核对客户端支持、权限模型、配置变更审计、备份恢复和跨网络访问方式，而不只看功能清单。
已有 Java 微服务体系
Eureka 与 Spring Cloud Config 可沿用既有 Spring Cloud 集成。它们职责分开，便于分别调整注册发现和配置源，但调用链也多一层依赖。若系统规模较小且已运行在编排平台中，额外引入两套服务可能增加维护负担；新项目应先确认对应组件与当前框架版本的兼容性。
需要高度定制的控制面
etcd 是分布式键值存储，不是开箱即用的应用配置发布平台。采用它意味着团队还要设计数据结构、监听与重试、权限隔离、版本回滚和变更审计。除非这些控制逻辑确实需要自定义，通常不应只为保存几项配置而自建一层系统。
落地时按四步推进
- 列出边界：记录应用运行位置、服务依赖、配置敏感级别，以及是否需要跨集群或跨环境访问。
- 确定唯一来源：为每类配置指定管理系统，避免同一个参数同时出现在镜像、环境变量和远端配置中心。
- 验证变更路径：在测试环境修改一项非敏感参数，确认应用如何获知更新、是否需要重启，以及失败时如何恢复旧版本。
- 补齐运行保障：配置身份认证、最小权限、备份和监控；对注册中心不可用、配置读取超时等情况设置明确的启动与降级行为。
常见问题
服务发现和配置管理必须用同一个产品吗？
不必。小型集群可用平台原生服务发现，再以独立方式管理配置；需求集中且团队熟悉相关产品时，也可采用一体化方案。
Secret 是否等于加密后的配置？
不等于。Kubernetes Secret 的数据编码本身不能替代加密和访问控制，应结合权限限制及集群存储保护措施管理。
什么时候适合自建 etcd 方案？
当团队确实需要定制控制面，并具备持续开发、升级和故障处置能力时再考虑。一般业务优先使用维护成本更低的现成能力。
归根结底，云原生应用服务发现与配置管理应从运行环境和职责边界出发：集群内优先评估原生能力，需要集中注册配置时再选专用平台；自建方案则要把长期运维成本纳入决策。