注册中心维护服务名、实例地址和可用状态，供调用方发现服务。服务发现不等于负载均衡或流量治理；这些能力可能由客户端、网关或服务网格承担。
本文只比较开源且支持多语言 SDK 或语言无关 API 的方案，不列绑定单一应用框架的组件。
方案对比
| 方案 | 多语言接入 | 服务发现方式 | 主要取舍 |
|---|---|---|---|
| Nacos | Java / Go 官方 SDK；其他语言有社区 SDK 和 HTTP API | SDK 注册、订阅和健康状态 | 一体化能力强，需要运维集中式控制面 |
| Consul | DNS / HTTP API，语言无关 | 服务目录、健康检查、DNS / API；另有 KV 配置 | 集群、网络和 ACL 需要规划 |
| ZooKeeper | Java / C 官方绑定；Go / Python 社区客户端 | 临时节点和 Watch 可实现服务发现 | 原语型方案，服务模型和消费端逻辑需自行实现 |
| Polaris（北极星） | Java、Go、C++、PHP SDK | SDK、框架插件、Kubernetes 同步 | 接入和治理面更复杂 |
| Kubernetes Service + CoreDNS | DNS、环境变量或 Kubernetes API，语言无关 | Service / EndpointSlice 提供记录，CoreDNS 通过 DNS 暴露 | 集群定向；CoreDNS 是解析层，不是服务目录 |
| etcd | gRPC / HTTP JSON API，语言无关 | KV 前缀、Lease 到期清理和 Watch，可自行实现注册表 | 服务模型、客户端和运维治理要自己实现 |
怎么选
| 场景 | 优先评估 |
|---|---|
| 单个 Kubernetes 集群内互相调用 | Kubernetes Service + DNS |
| 多语言服务需要一体化注册与配置 | Nacos |
| VM、混合云或多数据中心，偏好 DNS | Consul |
| 已有 ZooKeeper 生态，需要用临时节点做服务发现 | ZooKeeper |
| 多语言服务需要统一服务治理 | Polaris |
| 自己构建控制面，需要一致性 KV 和 Lease / Watch | etcd |
上线前确认健康检查和实例过期规则、控制面故障时的客户端缓存行为，并明确负载均衡、超时和熔断由哪一层负责。
配置模型、发布和热更新方案见配置中心项目对比。