Consul 生产环境部署和运维有哪些关键要点？

Consul 生产部署的核心难点在于保证集群高可用的同时兼顾安全与性能。以下是实战中必须关注的要点。

集群架构：3-5 个 Server 节点是底线

Server 节点数量必须是奇数（3 或 5），因为 Consul 使用 Raft 协议，需要多数派达成共识才能提交写入。3 节点容忍 1 台宕机，5 节点容忍 2 台。Server 节点应跨可用区部署，避免单机房故障导致整体不可用。Client 节点与业务同机部署，负责本地健康检查和请求转发，单个数据中心建议不超过 5000 个 Client。

安全配置：TLS + ACL + Gossip 加密缺一不可

生产环境必须启用三项安全机制：RPC 通信走 TLS 双向认证，Gossip 协议使用 encrypt_key 加密，ACL 默认策略设为 deny 并按最小权限分配 Token。Bootstrap Token 权限极大，务必妥善保管，类似数据库 root 密码。启用 ACL 后注意开启 enable_token_persistence，避免节点重启后 Token 丢失导致集群通信中断。

性能调优：关注磁盘 IO 和 Raft 参数

Consul 写入性能主要受磁盘 IO 制约，Server 节点务必使用 SSD。关键参数 raft_multiplier 建议设为 1（最高性能模式），默认值 5 会让选举超时时间偏长，在低延迟内网环境下没有必要。snapshot_interval 可从默认 1 天缩短到 30s，避免 Raft 日志无限增长。读多写少的场景可将一致性模式设为 stale，让所有 Server 都能响应查询，减轻 Leader 压力。

常见故障：Leader 丢失和服务注册不同步

Leader 频繁选举通常是因为节点间网络不稳定或磁盘 IO 阻塞了 Raft 心跳。排查时先用 consul operator raft list-peers 确认集群成员状态，再检查网络延迟和磁盘 iops。服务注册后其他节点看不到，多半是 Client Agent 的缓存未刷新，可通过 DNS stale 读或适当降低 stale_read_time 缓解。Agent 宕机后其上的健康检查不会被其他节点接管，这是 Consul 的设计限制，需通过外部监控补偿。

追问：滚动更新时如何避免 no leader 错误？

调整 leave_drain_time（默认 5s）让 Server 在优雅退出时留出缓冲时间，配合 rpc_hold_timeout（默认 7s）使客户端在选举期间自动重试，基本可以消除滚动更新导致的瞬时不可用。