微服务拆分之后，一个请求会经过网关、订单、库存、支付、数据库和第三方接口等多个环节。单个服务运行正常但是整个系统的响应时间却越来越差，这就是分布式系统中典型的“跨服务性能盲区”。Apache SkyWalking通过无侵入探针来收集Trace和Metric数据，把分散的调用整合成一条可以观察到的链路。
核心架构分为四层：Agent探针用字节码增强来生成TraceID和Span，在跨服务之间通过HTTP头以及RPC上下文进行传递；OAP服务器负责流式聚合；Elasticsearch或者BanyanDB用来存储数据；UI展示拓扑图、慢请求和调用链。
落地的时候先部署OAP和UI，存储不用默认的H2，在生产环境中切换到ES集群；Java服务只加上了-javaagent参数以及声明了service_name和后端地址11800，不需要修改业务代码。在流量高峰期间开启动态采样、核心链路保全量、普通流量按比例降级来降低存储成本。
瓶颈定位采用三层下钻的方式：拓扑图上标出高延迟调用边，端点面板筛选出 P99 异常接口，Trace 详情按照 Span 耗时排序。常见的根本原因包括数据库慢查询、连接池满、缓存击穿、外部 API 阻塞以及线程池排队等。一个下单接口由原来的 200ms 下降到现在的 1.2s，在链路中直接暴露出库存服务内部循环查库的 Span 占用时间为 800ms，经过索引优化之后又恢复正常了。
把TraceID放到MDC中，实现链路和日志之间的相互跳转，再加上P99告警就构成了一个完整的闭环。
SkyWalking 的价值不仅仅在于可以看到调用链，更重要的是可以把模糊的“系统变慢”的问题具体化为某条服务、某个 Span 或者某类依赖所导致的性能下降。零侵入接入和拓扑分析以及采样功能使得跨服务性能治理由原来的翻日志、猜根因的方式转变为数据驱动的方式。