证券交易系统微服务可观测性建设实践

背景与痛点

某券商把核心交易从单体拆成网关、订单、撮合、清算等十几个微服务后，故障定位时间从分钟级恶化到小时级。一个订单失败，可能是网关超时、订单服务限流、还是撮合拒绝，靠人肉翻日志根本查不过来。更麻烦的是开盘前 30 分钟是全天的关键窗口，任何抖动都会被放大成事故。

统一 traceId 打通全链路

第一步是把 traceId 贯穿所有服务。网关在入口生成 traceId，通过 HTTP Header 透传，各服务日志统一打印 traceId 和 spanId。这样任意一笔委托都能用订单号反查到 traceId，再定位到具体服务和调用段。

炬鲸 OBSERVE 支持用业务字段（orderNo）关联 trace：排查时先按 orderNo 检索日志拿到 traceId，再下钻整条链路。上线后平均定位时间从 40 分钟降到 5 分钟以内，大部分问题在第一个 span 就能看出是超时还是被拒。

开盘高峰的告警治理

开盘瞬间委托量是平时的 10 倍，直接按静态阈值告警会疯狂误报。我们做了三件事：

1. 告警基线按「昨日同期 + 上周同期」动态计算，而不是写死阈值；
2. 加静默窗口：9:15-9:25 集合竞价阶段降低告警灵敏度，避免撮合抖动刷屏；
3. 区分「单笔失败」和「成功率下跌」，只有成功率连续 2 分钟跌破 99.9% 才触发 P1，单笔失败只进待办不打扰。

告警分级也很关键：P1 直接电话 + 短信，P2 走企业微信，P3 进邮件。否则开盘高峰一旦触发告警风暴，值班人员会直接静音群，真正严重的告警反而被淹没。

SLO 设计

对交易链路定义三个 SLO：下单接口 P99 延迟 ≤ 200ms、订单成功率 ≥ 99.99%、撮合确认时延 ≤ 1s。SLO 用 28 天滚动窗口计算，误差预算不足时先暂停非紧急发布，而不是等问题爆发。这套指标让开发和运维第一次用同一把尺子说话，发布前能预估"这次改动会不会烧预算"。

SLO 还有一个配套动作：烧毁率告警。误差预算在短时间内被快速消耗（比如 1 小时烧掉 10%），比事后看成功率下跌更早暴露问题，能抢在用户投诉前介入。

经验总结

• 先打通 traceId 再谈告警，链路不通的告警只是噪音；
• 高峰期的告警必须动态化，静态阈值在金融场景基本不可用；
• SLO 要挂在业务指标上（成功率、时延），不要挂在 CPU / 内存这类基础设施指标上；
• 可观测性不是一次性项目，采样率、告警基线、SLO 阈值都要跟着业务变化持续调。