服务注册与心跳续租需用 etcd 的 Put 写入带 TTL 的 key 并通过 KeepAlive 流持续刷新;consul 可用 dns 或 http API 发现服务,推荐官方 go 客户端并定期缓存健康实例;注册发现逻辑应抽离为接口化模块,避免硬编码。

用 etcd 实现服务注册与心跳续租
Go 微服务要被其他服务找到,核心是把自身地址(如 10.0.1.5:8080)写入一个共享的、高可用的键值存储,并持续更新“我还活着”。etcd 是最常用选择,它支持 TTL 和 watch 机制,天然适配服务发现场景。
关键点不是“写一次”,而是“写完还要定期刷新过期时间”,否则节点下线后残留的注册信息会误导调用方。官方 clientv3 不直接提供自动续租,得自己用 KeepAlive 流处理。
- 注册时用
Put写入带 TTL 的 key,例如/services/order/10.0.1.5:8080 - 立即调用
client.KeepAlive获取一个chan *clientv3.LeaseKeepAliveResponse,并在 goroutine 中持续接收响应,维持租约
- 务必检查
ctx.Done()或err,避免续租失败后静默失效 - 服务退出前调用
client.Revoke主动释放 lease,减少 etcd 垃圾
用 consul 的本地 DNS 或 HTTP API 做服务发现
Consul 提供两种主流接入方式:DNS 查询(如 curl order.service.consul:8080)和 HTTP API(GET /v1/health/service/order?passing)。前者对语言透明但调试困难;后者可控性强,适合 Go 项目主动拉取。
Go 客户端推荐用官方 hashicorp/consul/api,注意它默认不重试失败请求,且服务列表缓存需自行管理。
立即学习“go语言免费学习笔记(深入)”;
- 初始化 client 时设置
Address和Timeout,超时太短会导致频繁报GetService: Get "http://...": context deadline exceeded - 调用
Health().Service时传passing=true参数,否则可能返回不健康实例 - 不要每次发请求都查一次服务列表——用 goroutine + ticker 定期刷新到内存 map,再配合读锁访问
- 若用 DNS 模式,确保容器或宿主机的
/etc/resolv.conf已配置 Consul DNS 地址,且服务名后缀为.service.consul
避免在 Go 中硬编码服务发现逻辑
把注册/发现代码散落在 main.go 或 handler 里,会导致测试难、复用差、升级痛。正确做法是抽成独立模块,通过接口隔离实现细节。
定义统一接口比直接依赖 etcd/consul client 更可持续:
type Registry interface { register(serviceName, addr string, ttl time.Duration) error Deregister() error WatchServices(serviceName string, ch chan<- []string) error }
- 实现层(如
etcdRegistry)只负责和底层交互,不参与业务路由逻辑 - HTTP handler 或 gRPC server 启动后调用
registry.Register,而非在每个 handler 里手动查实例 - 测试时可注入 mock registry,避免启动真实 etcd/consul
- 跨语言部署时,只要 registry 实现兼容同一后端,Go 服务就能无缝接入已有体系
gRPC 场景下如何让 resolver 动态感知服务变更
gRPC Go 默认 resolver 只解析一次 DNS,不支持服务列表热更新。必须自定义 resolver.Builder,监听服务发现后端变化,并触发 cc.UpdateState 通知连接管理器。
常见错误是只监听变更却忘了构造正确的 resolver.State:endpoints 必须是 resolver.Address 切片,且每个 Address 的 ServerName 字段要设为实际目标服务名,否则 TLS SNI 会失败。
- 监听 etcd key 前缀(如
/services/payment/)用Watch,收到事件后解析所有子 key 的 value 得到地址列表 - 每次更新调用
cc.UpdateState(resolver.State{Addresses: addrs}),gRPC 会自动重建连接池 - 务必在
Build方法里启动监听 goroutine,并在Close时 cancel context 清理资源 - 如果用 consul,可用
Health().Service轮询代替 watch,但间隔建议 ≥5s,避免压垮 consul API
服务注册与发现真正的复杂点不在“怎么连上 etcd”,而在于租约续期是否稳定、服务列表变更后客户端能否及时剔除故障节点、以及 resolver 更新是否触发了真实的连接重建。这些地方一旦出问题,表现往往是偶发超时或 503,日志里却找不到明显错误。