go mod graph不能当服务依赖图用，因为它输出的是Go模块的import关系（如myapp → logrus），而非运行时服务调用关系（如“订单服务调用用户服务”）；它无法区分强弱依赖、混入底层包导致节点爆炸、且不能体现协议/环境等关键拓扑语义。
go mod graph 为什么不能当服务依赖图用
它输出的是模块 import 关系，不是服务调用关系。你看到的 myapp → github.com/sirupsen/logrus 和“订单服务调用用户服务”完全无关。
常见误用现象：
- 用
go mod graph | grep user当成“谁在调用户服务”，结果匹配到的是本地user-api客户端 SDK 的 import，而非真实 HTTP/gRPC 请求 - 把
golang.org/x/net这类底层包渲染进拓扑图，节点爆炸、语义失真 - 无法区分强依赖（必须连通）和弱依赖（降级可用），而这两者在故障决策中完全不同
HTTP/gRPC 调用怎么准确上报依赖边
关键不是“有没有埋点”，而是“埋对没埋对”。OpenTelemetry 的 peer.service 和 rpc.service 字段必须显式设，否则 fallback 到自身 service.name，导致自循环边。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- HTTP 客户端：用自定义
http.RoundTripper包裹默认 transport，在RoundTrip入口提取req.URL.Host或X-Service-Targetheader，调用span.SetAttributes(attribute.String("peer.service", "user-svc")) - gRPC 客户端：实现
grpc.UnaryClientInterceptor，从method字符串（如/user.UserService/GetProfile）解析目标服务名，别依赖不稳定的grpc.peer.address - 务必过滤掉
SpanKindInternal类型的 span——它们是函数内调用，不是跨服务通信
DependencyEdge 结构体里哪些字段不能少
只传 source_service 和 target_service 是最常见错误。没有协议和环境标签，拓扑图就失去分层能力，MySQL 和 Kafka 全被当成“服务”，掩盖真实架构意图。
必须包含的字段：
-
Protocol：固定为"http"、"grpc"、"kafka"、"mysql"等标准值，禁止用"tcp"或"network" -
Environment：来自启动参数或os.Getenv("ENV")，不能硬编码 -
Port：HTTP 用req.URL.Port()，gRPC 从 dial target 解析，MySQL 从 DSN 提取 -
Timestamp：用time.Now().UnixMilli()，别用纳秒级时间戳——前端聚合易溢出
上报目标选什么才不至于压垮系统
别自己写中心存储服务。独立开发拓扑中心成本高、收敛慢、易成单点瓶颈。
生产环境推荐组合：
- Prometheus Pushgateway：适合短期聚合、轻量上报，但需注意其不支持多实例去重
- Redis Sorted Set：按
timestamp去重，配合 Lua 脚本做 TTL 清理，吞吐高、延迟低 - OpenTelemetry Collector：开箱支持 OTLP 协议、内置 batch/exporter pipeline，适配度最高
所有服务上报前必须异步聚合、带采样（比如每 10 秒 flush 一次 buffer），否则高频调用下直接打满网络和中心存储。
