2. 金融Serving基础
在进入可观测性与故障诊断的实战之前，必须先建立对金融在线服务（Financial Serving）本身的准确认知。金融Serving并非普通的Web服务，它承载的是资金流转、交易撮合、风控决策、额度计算等强一致性、强合规、强时效的业务逻辑。一次请求超时可能意味着用户错过行情，一次数据不一致可能触发监管问责。因此，理解其典型架构、服务等级体系以及故障代价，是后续所有诊断工作的前提。
一、金融在线服务的典型架构
金融Serving系统通常呈现"接入—编排—领域服务—数据访问—基础设施"的分层结构。接入层负责协议转换、鉴权、限流与灰度路由；编排层（BFF或API Gateway）聚合多个领域服务，完成一次业务请求的组装；领域服务层包含账户、交易、风控、行情、清算等核心微服务；数据访问层则混合使用关系型数据库、分布式缓存、消息队列与分布式事务组件。
与电商类服务不同，金融Serving对"确定性"要求极高：同一笔交易在任意副本上执行必须得到相同结果，因此幂等设计、序列化隔离、分布式锁、TCC/SAGA事务成为标配。同时，监管要求全链路留痕，意味着每一次调用都需要可追溯的Trace ID、业务流水号与操作审计日志。
二、SLA、SLO与SLI：从承诺到度量
三者构成层层递进的关系：SLI（Service Level Indicator）是可被直接测量的指标，如请求延迟、成功率、吞吐量；SLO（Service Level Objective）是对SLI设定的内部目标，例如"P99延迟小于200ms，月度达标率99.9%"；SLA（Service Level Agreement）则是与客户或监管签订的外部承诺，通常比SLO更宽松，并附带违约赔偿条款。
金融场景中，SLI的选择必须与业务语义对齐。例如交易服务的SLI不能只看HTTP 200，还要看"订单最终成交率"；行情推送的SLI要区分"推送延迟"与"数据完整性"。SLO的设定需要留出错误预算（Error Budget），错误预算消耗速度本身就是重要的告警信号。
| 层级 | 定义 | 金融场景示例 | 典型阈值 |
|---|---|---|---|
| SLI | 可测量的指标 | 交易接口P99延迟 | 实测值 |
| SLO | 内部目标 | P99 < 200ms，月度99.95% | 内部考核 |
| SLA | 外部承诺 | P99 < 500ms，月度99.9% | 违约赔偿 |
| Error Budget | 允许失败额度 | 月度0.05%不可用时间 | 约21分钟 |
三、高可用要求与故障代价
金融Serving的高可用不是简单的"多副本"，而是要在一致性、可用性、延迟三者之间做出业务可接受的权衡。核心交易链路通常要求同城双活+异地灾备，RTO（恢复时间目标）控制在分钟级，RPO（恢复点目标）接近零。行情类服务可接受短暂降级，但资金类服务宁可拒绝服务也不能返回错误结果。
故障代价可以从四个维度衡量：资金损失（错误交易、重复扣款）、合规风险（监管处罚、审计失败）、用户信任（挤兑、流失）、连锁反应（一个服务超时引发上游线程池耗尽，形成雪崩）。因此，故障诊断的目标不仅是"恢复"，更是"在错误预算耗尽前定位并止损"。
四、可观测性挑战与常见误区
金融Serving的可观测性面临三大挑战：数据量大（高频交易产生海量指标与日志）、链路长（一次请求跨越十几个服务）、语义复杂（业务状态与系统状态交织）。传统监控只关注"系统是否活着"，而可观测性要求回答"为什么这笔交易失败了"。
常见误区包括：
- 只采集指标，不采集上下文：看到P99飙升却不知道是哪类交易、哪个用户、哪个下游导致。
- 日志与Trace割裂：无法从一条错误日志直接跳转到完整调用链。
- 告警阈值拍脑袋：未基于SLO和错误预算设定，导致告警疲劳或漏报。
- 忽视业务指标：只监控CPU和内存，却未监控"订单成功率""资金对账差异"等业务SLI。