SkyWalking 接入全链路追踪：第一次把服务调用看清楚了

微服务架构下，A 调 B、B 再调 C 和数据库，接口最终超时了，你只知道「慢了」，不知道慢在哪一段。各服务的日志是分开的，时间戳要手动对比，效率很低。接入 SkyWalking 之后，一个请求完整的调用链路和每段耗时，在一张 Trace 图里都能看到。

接入两步走

第一步：部署 OAP Server 和 UI

用 Docker Compose 快速启动：

version: '3.8'
services:
  oap:
    image: apache/skywalking-oap-server:9.4.0
    container_name: sw-oap
    ports:
      - "11800:11800"   # gRPC，Java Agent 上报数据
      - "12800:12800"   # REST API
    environment:
      SW_STORAGE: h2    # 测试用 H2，生产改为 elasticsearch

  ui:
    image: apache/skywalking-ui:9.4.0
    container_name: sw-ui
    ports:
      - "8080:8080"
    environment:
      SW_OAP_ADDRESS: http://oap:12800
    depends_on:
      - oap

UI 地址：http://localhost:8080，查 Trace 在左侧菜单「Trace」，可按 Service / Endpoint / TraceId 搜索。

第二步：Java Agent 挂载

# 启动 Java 应用时添加 javaagent 参数
java -javaagent:/opt/skywalking-agent/skywalking-agent.jar \
     -Dskywalking.agent.service_name=order-service \
     -Dskywalking.collector.backend_service=127.0.0.1:11800 \
     -jar order-service.jar

关键配置说明：

• service_name：服务名，Trace 图里区分不同服务的依据，每个微服务必须不同
• collector.backend_service：OAP Server 的 gRPC 地址（端口 11800）

Docker 部署时，把 -javaagent 参数加到 Dockerfile 的 JAVA_OPTS 环境变量里，Agent 目录通过 COPY 或 volume 挂入镜像。

一次真实的排查

接入后用 Trace 图解决的第一个问题：订单查询接口 P99 达到 2 秒。

在 Trace 搜索页按 Endpoint 过滤这个接口的慢请求，点开一条，调用链如下：

order-service /api/order/detail  [2100ms]
├── inventory-service.getStock       [15ms]
└── product-service.getProductDetail [2050ms]
    └── DB: SELECT * FROM product WHERE id=?  [2040ms]

一眼定位到 product-service 里有一条 SQL 耗时 2040ms。排查后发现查询条件里对 id 字段做了函数运算（DATE(create_time) = ?），导致索引失效全表扫描。加了正确的索引后，这个接口响应时间降到 80ms 以内。

没有链路追踪时，这类问题要手动比对各服务日志，可能花几小时；有了 Trace 图，定位过程大概 10 分钟。

选型对比

工具	特点	适合场景
SkyWalking	Java Agent 无侵入，UI 功能完整（Trace + 拓扑图 + 性能指标）	Java 微服务，首选
Zipkin	轻量，功能基础	小规模项目，或非 Java 技术栈
Jaeger	CNCF 标准，K8s 云原生生态友好	已上 K8s 且重度使用 Istio 的场景

选 SkyWalking 的理由：Java Agent 挂上去就能收数据，不需要改一行业务代码；UI 里开箱即用，可以同时看 Trace、服务拓扑和慢接口排行。