服务发现需主动实现而非依赖框架自动完成，应选etcd/Consul/Nacos或K8s DNS；etcd注册须绑定lease并KeepAlive续租，退出前Revoke；K8s中优先用Service DNS；客户端需自行实现负载均衡与健康探测。
服务发现不是“加个库就自动好了”
在云环境里，Go 服务本身不内置服务发现能力。你得明确选一种注册中心（如 etcd、Consul、Nacos）或依赖平台能力（如 Kubernetes 的 Service DNS），然后自己实现注册、心跳、反注册和发现逻辑。别指望 net/http 或 gin 自动帮你做这件事。
用 etcd 实现注册与健康检查最可控
etcd 是云原生场景下最常被 Go 服务选用的注册中心，因为它的 Watch 机制和 TTL Lease 天然适合服务上下线管理。关键点不在“能不能连上”，而在“怎么保活”和“断连后如何清理”。
- 注册必须绑定
lease，不能直接写 key；否则服务挂了也不会自动删除 - 心跳要用
KeepAlive，而不是反复Grant新 lease——后者会快速耗尽 etcd 连接和配额 - 服务退出前必须显式调用
Revoke，否则依赖超时清理可能延迟几十秒 -
go.etcd.io/etcd/client/v3是当前唯一维护的客户端，v2已废弃，别再搜旧教程
client, _ := clientv3.New(clientv3.Config{Endpoints: []string{"http://127.0.0.1:2379"}})
lease := clientv3.NewLease(client)
resp, _ := lease.Grant(context.TODO(), 10) // 10秒TTL
client.Put(context.TODO(), "/services/myapp/10.0.1.5:8080", "alive", clientv3.WithLease(resp.ID))
ch, _ := lease.KeepAlive(context.TODO(), resp.ID) // 后台自动续租
go func() {
for range ch { } // 忽略续租响应，只保证通道活跃
}()
Kubernetes 环境优先走 Service DNS，别自己搞注册
如果你的服务跑在 Kubernetes 上，Go 应用该做的不是连 etcd，而是直接依赖集群 DNS 和 Service 对象。自己在 Pod 里再搞一套服务发现，既冗余又容易出错。
- 用
http://my-service.default.svc.cluster.local:80访问，KubeDNS 会自动解析到 endpoints - 需要动态感知后端变化？用
client-go监听Endpoints资源，比轮询/health更准、更轻量 - 别在代码里硬编码节点 IP 或端口；Pod IP 不稳定，Service ClusterIP 才是稳定入口
- StatefulSet 场景下若需区分实例，可用 headless Service + DNS SRV 记录，解析出
pod-0.my-svc.default.svc.cluster.local
客户端负载均衡必须和服务发现解耦
发现服务地址只是第一步。拿到一串 []string（比如 ["10.0.1.5:8080", "10.0.1.6:8080"]）之后，Go 代码还得决定“这次请求发给谁”。net/http 默认不支持这个，得自己选策略或引入库。
mallcloud商城
下载
mallcloud商城基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba并采用前后端分离vue的企业级微服务敏捷开发系统架构。并引入组件化的思想实现高内聚低耦合，项目代码简洁注释丰富上手容易，适合学习和企业中使用。真正实现了基于RBAC、jwt和oauth2的无状态统一权限认证的解决方案，面向互联网设计同时适合B端和C端用户，支持CI/CD多环境部署，并提
立即学习“go语言免费学习笔记（深入）”；
- 简单轮询或随机选一个？可以，但没健康探测，故障实例会持续被命中
- 想用
grpc-go的round_robin？它只认resolver.Builder，你得包装一层把服务发现结果转成Address列表 - 避免在每次 HTTP 请求前查一次注册中心；应缓存并后台定期刷新，或监听变更事件
- 超时和重试要和服务发现联动：比如某实例连续 3 次
ConnectTimeout，就临时从本地缓存剔除 30 秒
复杂点在于，服务发现的“最终一致性”和客户端缓存的“局部视图”之间总有延迟。这个 gap 无法消除，只能靠探测频率、缓存过期、失败熔断来收窄。
