Consul、Eureka、ZooKeeper 和 etcd 做服务发现该怎么选？

选服务发现工具时，不能只看功能表，要先看团队到底要解决什么问题。Consul 的强项是把服务注册发现、健康检查、DNS 查询、多数据中心和 KV 能力放在一起，适合多语言、跨机房、非 Kubernetes 专用的服务治理场景。Eureka 更贴近 Spring Cloud 老体系，Java 应用接入顺手，但 2.x 已停止活跃演进，新项目不太建议从零押注。ZooKeeper 和 etcd 都能作为注册发现的底层存储，但它们更偏分布式协调或强一致 KV，健康检查、服务模型和 DNS 接入通常要自己补。

Consul 的最小服务注册大概是这样：

json
{
  "service": {
    "id": "order-1",
    "name": "order",
    "address": "10.0.1.12",
    "port": 8080,
    "checks": [{
      "http": "http://10.0.1.12:8080/health",
      "interval": "10s",
      "timeout": "2s"
    }]
  }
}

查询时可以走 HTTP API，也可以走 DNS：

bash
curl 'http://127.0.0.1:8500/v1/health/service/order?passing=true'
dig @127.0.0.1 -p 8600 order.service.consul

这个能力组合也是 Consul 的取舍：它开箱即用的东西多，生产配置也更多。至少要考虑 Raft server 数量、ACL、TLS、Gossip 加密、健康检查频率和故障演练。小团队如果只有少量 Java 服务，Nacos 或 Spring 生态方案可能更省心；如果服务来自 Go、Java、Node、Python，又需要 DNS 兼容老系统，Consul 更合适。

追问

Consul 和 Eureka 最大区别是什么？

Eureka 更强调客户端心跳和最终一致性，故障时倾向继续可用。Consul 通过健康检查和 Raft 维护目录状态，配合 passing=true 可以更严格过滤不健康实例。这个取舍会影响故障体验，Eureka 更依赖客户端重试，Consul 更早把健康状态放进发现层。踩坑点是 Consul 不负责每次请求的负载均衡，客户端或网关仍要自己选择实例。

Consul 和 ZooKeeper 都能做注册中心，为什么还要选 Consul？

ZooKeeper 的强项是临时节点、选主、锁和配置监听，不是开箱即用的服务目录。用它做服务发现通常要自己约定节点结构、健康检查和客户端封装。Consul 已经内置服务模型、健康检查、DNS/API 查询，接入和运维更直接。边界是存量系统如果已经稳定运行在 ZooKeeper 上，不要为了工具更新轻易迁移。

etcd 和 Consul 都用 Raft，是否可以互相替代？

etcd 是优秀的强一致 KV，Kubernetes 用它保存集群状态。它不提供 Consul 那种完整服务发现体验，租约、心跳、服务列表和客户端监听都需要额外封装。Consul 更像服务发现产品，etcd 更像可靠存储底座。实际选择时，纯 Kubernetes 内优先用 Service 和 CoreDNS，VM、裸机、多语言混合部署再考虑 Consul。

什么情况下不应该上 Consul？

如果应用都在 Kubernetes 里，且只需要集群内服务发现，Kubernetes Service 通常够用。为了一个简单注册中心再部署 Consul，会增加 ACL、证书、备份和监控成本。另一个不适合的场景是团队没有跨语言、跨数据中心或 DNS 接入需求，只是少量 Java 服务。工具越完整，误配置空间越大，没有明确收益时简单方案更可靠。