服务注册：如何把服务信息“告诉”etcd
要让调用方找到服务，第一步得让服务自己“报名”——把自己的IP、端口这些信息告诉etcd。你可以把etcd想象成一个“动态通讯录”，服务注册就是在这个通讯录上登记信息，还得定期“签到”证明自己还活着。
先搞懂etcd里的“登记规则”
在etcd里存服务信息，键（key）的设计很关键。我见过有人直接用服务名当key，结果多个实例存进去就覆盖了，这就像两个人重名只登记一个名字，根本分不清谁是谁。正确的做法是用“分层路径”，比如/microservices/user-service/10.0.0.1:8080，前面是服务类型（user-service），后面是实例唯一标识（IP+端口）。这样既能按服务名筛选，又能区分不同实例。值（value）就存JSON格式的服务详情，比如{"ip":"10.0.0.1","port":8080,"weight":50,"health":"ok"}，方便调用方解析。
注册逻辑：从“登记”到“保活”
注册流程其实不复杂，我拆成三步你就明白了。第一步是连etcd，用Go的etcd客户端clientv3，几行代码就能搞定：
cli, err = clientv3.New(clientv3.Config{
Endpoints: []string{"http://etcd1:2379", "http://etcd2:2379"}, // 集群地址
DialTimeout: 5 time.Second,
})
这里要注意，连etcd集群时多填几个节点地址，万一某个节点挂了，客户端会自动切换，这是我之前踩过的坑——单节点连etcd，节点一挂整个注册就卡住了。
第二步是“登记信息”，用Put操作把服务信息写入etcd。但光存进去还不够，万一服务突然崩溃没来得及删除信息，etcd里就会留个“僵尸记录”。所以得给记录加个“过期时间”（TTL），比如30秒，然后定期“续约”（KeepAlive），就像你租房子，到期前续租才能继续住。代码里用Grant申请租约，再用Put绑定租约：
lease, err = cli.Grant(context.TODO(), 30) // 30秒租约
_, err = cli.Put(context.TODO(), key, value, clientv3.WithLease(lease.ID))
// 启动续约协程
ch, err = cli.KeepAlive(context.TODO(), lease.ID)
// 监听续约结果（非必需，但 加，方便排查续约失败问题）
go func() {
for ka = range ch {
log.Printf("服务续约成功，剩余TTL: %d秒", ka.TTL)
}
}()
第三步是“优雅退出”，服务正常关闭时，记得主动删除etcd里的记录，避免等待TTL过期。可以用signal.Notify监听退出信号，收到信号时调用Delete：
sig = make(chan os.Signal, 1)
signal.Notify(sig, syscall.SIGINT, syscall.SIGTERM)
<-sig // 等待退出信号
_, err = cli.Delete(context.TODO(), key)
log.Println("服务已下线，etcd记录删除成功")
避坑指南：这3个细节别忽略
我之前带团队落地时，踩过几个典型坑，你可以提前避开。一是租约时间别设太短，比如5秒，网络稍微抖动一下续约就失败了， 15-30秒，亲测这个区间比较稳妥。二是键名里别包含特殊字符，比如冒号、斜杠要注意转义，之前有同事在IP端口里用了下划线，结果etcd查询时匹配不到，排查半天才发现是键名格式问题。三是续约协程要加错误处理，万一etcd集群不可用，ch会被关闭，这时候可以触发服务告警，而不是默默失败。
服务发现：实时“跟踪”服务状态的实现
服务注册好了，接下来就是调用方怎么“找到”这些服务。如果调用方每次都去etcd查一次，效率低不说，还可能拿到过期信息。etcd的Watch机制就能解决这个问题——它像个“实时通知器”，服务上下线时会主动告诉你，调用方只要“盯着”通知就行。
从“查通讯录”到“实时监听”
服务发现有两种方式，各有适用场景。一次性查询适合对实时性要求不高的场景，比如定时任务调度，直接用Get操作拿当前所有服务实例：
resp, err = cli.Get(context.TODO(), "/microservices/user-service/", clientv3.WithPrefix())
// 解析结果
for _, kv = range resp.Kvs {
serviceInfo = parseServiceInfo(string(kv.Value)) // 自定义解析函数
fmt.Printf("发现服务实例: %s:%dn", serviceInfo.Ip, serviceInfo.Port)
}
实时监听
则适合需要秒级响应的场景，比如API网关。用Watch监听服务前缀，服务新增、删除、修改时，etcd会推送事件，调用方可以实时更新本地缓存。代码示例：
watchCh = cli.Watch(context.TODO(), "/microservices/user-service/", clientv3.WithPrefix())
for wresp = range watchCh {
for _, ev = range wresp.Events {
switch ev.Type {
case mvccpb.PUT: // 服务上线或更新
updateServiceCache(string(ev.Kv.Key), string(ev.Kv.Value))
case mvccpb.DELETE: // 服务下线
removeServiceCache(string(ev.Kv.Key))
}
}
}
这里有个小技巧，本地可以维护一个“健康服务列表”缓存，Watch事件来的时候更新缓存，调用时直接从缓存取，不用每次查etcd，性能能提升不少。我之前做的项目里，没加缓存时每次调用都查etcd，QPS一高就卡顿，加了本地缓存后响应时间从50ms降到5ms以内。
筛选“活着”的服务：健康检查不能少
光拿到服务列表还不够，得确保这些服务是“活着”的。除了依赖etcd的TTL机制，最好再加一层应用层健康检查，比如调用服务的/health接口。我一般在解析服务信息后，启动一个定时检查协程，标记不健康的实例，调用时过滤掉：
// 健康检查函数
func checkHealth(ip string, port int) bool {
resp, err = http.Get(fmt.Sprintf("http://%s:%d/health", ip, port))
if err != nil || resp.StatusCode != http.StatusOK {
return false
}
return true
}
// 定时检查并更新状态
go func() {
ticker = time.NewTicker(10 time.Second)
for range ticker.C {
for _, service = range serviceCache {
if !checkHealth(service.Ip, service.Port) {
markServiceUnhealthy(service.ID) // 标记为不健康
}
}
}
}()
为什么要双重检查？因为etcd的TTL只能保证服务“能续约”，但服务可能CPU打满、内存溢出，虽然还在续约，但已经无法处理请求了。双重检查能进一步提高调用成功率，这是我从生产故障里 的教训——之前只依赖TTL，结果有个服务实例僵死但还在续约，导致调用方一直重试失败，加上应用层检查后，这种问题就没再发生过。
性能优化：让服务发现“跑”得更快
如果你的服务实例特别多（比如成百上千个），可以试试这两个优化技巧。一是批量注册/发现，多个服务实例一起注册或查询，减少etcd请求次数。etcd的Put和Get都支持批量操作，我之前帮一个有200+实例的项目做优化，把单次注册改成批量后，etcd的请求量降了60%。二是合理设置Watch粒度，如果服务分环境（开发/测试/生产），可以在键名里加环境前缀，比如/microservices/dev/user-service/，这样Watch时只监听对应环境的前缀，减少不必要的事件推送。
最后想说，服务发现看起来复杂，但核心就是“登记-通知-查询”这三步。你可以先搭个简单的demo，用本地etcd单节点，跑通注册和发现流程，再逐步优化细节。我当时就是这么做的，从只会调用etcd的Put/Get，到能处理各种异常场景，前后也就花了一周时间。如果你按这个流程试了，遇到什么问题或者有更好的优化点子，欢迎在评论区告诉我，咱们一起把服务发现做得更稳定～
你想想，如果两个服务实例都叫“user-service”，你直接把服务名当key存到etcd里，后启动的实例信息不就把前面的覆盖了吗？这就像你公司通讯录里有两个同事都叫“李华”，你只记“李华”这个名字，根本分不清哪个是技术部的李华，哪个是运营部的李华，打电话过去八成找错人。之前我帮朋友排查问题时，他就犯过这错，三个user-service实例启动后，etcd里永远只存着最后一个启动的，结果调用方只能找到一个实例，其他两个明明活着却没人用，资源全浪费了。
所以咱们得给每个服务实例“加个身份证号”，分层路径就是干这个的。比如“/microservices/user-service/10.0.0.1:8080”，前面“user-service”是服务类型，后面“10.0.0.1:8080”是实例的具体地址，这样每个实例都有独一无二的key，存多少个都不会打架。而且etcd有个好用的功能叫前缀查询，你想找所有“user-service”的实例，直接查“/microservices/user-service/”这个前缀，所有实例的IP、端口、权重这些信息都能一次性拉出来，调用方就能根据负载均衡策略挑一个健康的实例发请求，对吧？这比瞎猜地址靠谱多了。
为什么选择etcd作为Go服务的注册中心？
etcd作为分布式键值存储，具备高可用（支持集群部署）、强一致性（基于Raft协议）和原生Go语言支持的特点，适合Go微服务场景。相比其他注册中心（如Consul、ZooKeeper），etcd轻量易部署，客户端API简洁，且与Go生态兼容性更好，能减少跨语言依赖问题。
服务注册时为什么不能直接用服务名作为etcd的键（key）？
直接用服务名作为key会导致多个服务实例信息被覆盖（如同一个服务名对应多个实例，后注册的会覆盖先注册的）。采用分层路径（如/microservices/user-service/10.0.0.1:8080）可区分不同实例，既支持按服务名筛选（通过前缀查询），又能唯一标识每个实例，避免信息冲突。
服务注册时TTL（租约时间）设置多少合适？
设置15-30秒的TTL。设置太短（如5秒内）可能因网络抖动导致续约失败，误判服务下线；设置太长（如超过60秒）则服务异常下线后，etcd中僵尸记录清除延迟，可能导致调用方访问无效实例。实际可根据服务稳定性和网络环境调整，一般15-30秒是兼顾可靠性和实时性的区间。
服务发现中Watch机制和定时轮询哪种方式更好？
Watch机制（实时监听etcd事件）适合对实时性要求高的场景（如API网关），能秒级感知服务上下线，减少无效调用；定时轮询（定期查询etcd）实现简单，但存在感知延迟（取决于轮询间隔），适合对实时性要求低的场景（如后台任务调度）。实际项目中推荐优先使用Watch，搭配本地缓存提升性能。
服务注册时已经有TTL保活，为什么还需要应用层健康检查？
TTL保活仅能确认服务实例与etcd的通信正常，无法判断服务是否能正常处理业务（如服务CPU/内存耗尽、接口异常）。应用层健康检查（如调用/health接口）可验证服务实际可用性，双重检查能大幅降低调用失败概率，尤其适合核心业务服务。
