运行时埋点是生成可信服务拓扑图的唯一途径，需通过 http roundtripper、grpc interceptor、kafka topic 映射等方式采集真实调用关系，并以结构化 dependencyedge 统一上报至 opentelemetry collector 或 kafka。
不能靠 go mod graph 或 go list -m all 生成可用的服务拓扑图——它们只反映编译期模块引用，和“订单服务调用用户服务”完全无关。
运行时埋点才是唯一可信来源
真实依赖关系只存在于 HTTP 请求发往的域名、gRPC dial 的 target、Kafka 消费的 topic 这些运行期行为里。静态工具看不到配置驱动的调用（比如从 config.yaml 读取的 user_service_host），也分不清 import "database/sql" 实际连的是 MySQL 还是 SQLite。
- HTTP 客户端必须用自定义
http.RoundTripper包裹默认 transport，在RoundTrip入口提取req.URL.Host或约定 header（如X-Service-Target） - gRPC 客户端必须实现
grpc.UnaryClientInterceptor，从method字符串（如"/user.UserService/GetProfile"）解析目标服务名，比grpc.peer.address更可靠 - Kafka 消费者需在
consumer.Consume启动时，按业务约定映射 topic 到上游服务（如"order.created" → "order"），写入边记录 - 所有上报必须含语义字段：
Protocol（填"http"/"grpc"/"kafka"/"mysql"，不能填"tcp"或空字符串）、Environment（区分dev/staging/prod）、Port
结构化建模：DependencyEdge 是最小可行单元
别拼日志字符串，也别直接塞进 Prometheus label——结构不一致会导致前端无法聚合或渲染。必须统一用结构体封装边关系，字段不可省略：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
type DependencyEdge struct {
SourceService string `json:"source_service"`
TargetService string `json:"target_service"`
Protocol string `json:"protocol"`
Port int `json:"port,omitempty"`
Environment string `json:"env"`
Timestamp int64 `json:"ts"`
}
-
SourceService和TargetService必须是服务名（如"order-svc"），不是主机名或 IP -
Protocol值必须限定为已知协议枚举，避免自由填写导致分类混乱 - 异步上报（如写入本地 channel + 后台 goroutine 批量推送 Kafka），严禁阻塞主流程
- 每条边应带
Timestamp，便于后续做时间窗口聚合或断连检测
上报链路选型：避开 Pushgateway 和裸 Redis
Pushgateway 不适合长期拓扑数据存储——它设计用于短期指标聚合，且无 TTL 控制；裸 Redis Sorted Set 虽轻量，但缺乏 schema 校验和多维查询能力。真正可落地的组合是：
- 用 OpenTelemetry Collector 接收结构化
DependencyEdge数据，通过otlpreceiver + 自定义 exporter 转成标准 span 或 metric 上报 - 若已有 Kafka 集群，直接将边序列化为 JSON 写入专用 topic（如
dependency.edges.v1），由下游 Flink 或 Go 服务消费并写入图数据库（如 Neo4j）或时序库（如 TimescaleDB） - 禁用日志拼接方案：在 HTTP handler 里
log.Printf("%s → %s", svc, req.Host)看似简单，但字段无法结构化解析、时间戳不准、丢失协议/端口、且阻塞主流程 - 所有服务启动时，必须向中心 registry（如 etcd）注册自身元数据，含
service_name、host、env，否则上报的TargetService无法反查真实实例信息
最容易被忽略的一点：拓扑图里出现自循环（如 "job-svc → job-svc"）往往是因为定时任务 span 没设 peer.service，fallback 到了自身 service.name；而 MQ 链路断开，大概率是 producer 和 consumer 的 trace context 未正确 propagation，导致 trace_id 不一致——这些都不是靠改图算法能解决的，得回到埋点逻辑本身补全信号。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
