如果你主要使用 Spring Cloud Alibaba 技术栈且需要配置管理，选 Nacos 更省心；如果是多数据中心部署或对数据强一致性要求极高，Consul 更稳妥。

核心机制差异

Nacos 与 Consul 在健康检查上的核心逻辑不同，直接影响了运维配置和故障恢复速度。

Nacos：默认采用客户端心跳机制。服务实例定期向 Nacos 服务端发送心跳包（默认 5 秒一次）。若服务端超过指定时间（默认 15 秒）未收到心跳，会将实例标记为不健康；超过更长时间（默认 30 秒）则剔除实例。这种模式对服务端压力小，但依赖客户端进程存活。

Consul：采用服务端主动探测机制。Consul Server 定期向服务实例发起 HTTP、TCP 或脚本检查。能更真实反映服务内部健康度（如端口通但业务死锁），但频繁探测会增加网络和服务端负载。

Nacos 健康检查配置实战

在 Spring Cloud Alibaba 项目中，健康检查主要通过客户端心跳配置实现。需区分临时实例与持久化实例。

1. 临时实例（默认）：服务下线后自动剔除，适合动态扩缩容。

spring:
  cloud:
    nacos:
      discovery:
        heartbeat-interval: 5000  # 心跳间隔，单位毫秒，默认 5000
        heartbeat-timeout: 15000  # 心跳超时时间，单位毫秒，默认 15000
        ip-delete-timeout: 30000  # 实例删除超时时间，单位毫秒，默认 30000
        ephemeral: true           # 是否为临时实例，默认 true

2. 持久化实例：服务下线后不会自动剔除，需手动管理，适合数据库等有状态服务。

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false          # 设置为持久化实例

注意：持久化实例即使服务进程停止，Nacos 控制台仍显示在线，需手动下线或编写脚本清理，否则可能导致流量路由到无效地址。

Consul 健康检查配置实战

Consul 需要在服务注册时定义 check 规则。可以通过配置文件或 API 注册。

1. 配置文件注册（configuration.hcl 或 service.json）：

{
  "service": {
    "name": "user-service",
    "port": 8080,
    "check": {
      "http": "http://localhost:8080/actuator/health",
      "interval": "10s",           # 检查间隔，建议不低于 10s
      "timeout": "5s",             # 超时时间
      "deregister_critical_service_after": "30s" # 连续失败后剔除时间
    }
  }
}

2. 关键参数建议：

• interval：建议设置为 10s 以上，过短（如 1s）会导致网络波动时频繁误判。
• timeout：应小于 interval，通常设为 interval 的 50%-80%。
• deregister_critical_service_after：防止故障实例长期残留，建议设置 30s-60s。

验证与排查

配置完成后，需通过命令行或 API 验证健康检查是否生效。

1. 验证 Nacos 实例状态：

curl -X GET "http://nacos-server:8848/nacos/v1/ns/instance/list?serviceName=user-service"

观察返回 JSON 中的 healthy 字段。手动停止服务实例，观察该字段变为 false 直至实例消失的时间是否符合配置。

2. 验证 Consul 服务状态：

curl -X GET "http://consul-server:8500/v1/health/service/user-service"

观察 Checks 数组中的 Status 字段（passing/critical）。修改服务接口使其返回 500，观察状态变更延迟。

3. 日志监控：

• Nacos：查看客户端日志 nacos.log，搜索 heartbeat 关键字，确认心跳发送频率。
• Consul：查看服务端日志，搜索 check 关键字，确认是否有频繁的检查失败记录。

生产环境常见坑

1. 服务抖动（Consul）：

检查间隔设置过短（如 1s），在网络波动时易误判服务下线，导致负载均衡频繁切换。建议生产环境 interval 不低于 10s。

2. 实例残留（Nacos）：

使用了持久化实例（ephemeral=false）但未配置自动清理机制。服务重启或迁移后，旧 IP 仍存在于注册中心。建议无状态服务保持默认临时实例配置。

3. 资源消耗（Consul）：

大规模服务下（上千实例），Consul 服务端主动检查会消耗较多 CPU 和带宽。需评估服务器性能，必要时调整检查频率或采用客户端上报模式。

4. 网络分区影响：

Nacos 在 AP 模式下，网络分区时仍可用但数据可能不一致；Consul 基于 Raft 强一致性，网络分区时可能不可写。需根据业务对一致性的容忍度选择模式。