3. 支付系统高可用概述

支付系统的高可用不是一句“系统别挂”就能概括的目标，它需要被拆解为可度量、可设计、可验证的工程体系。本节从高可用目标出发，串联 SLA/SLO、容错设计原则，并深入分析单点故障与雪崩效应这两类最典型的可用性杀手，为后续的降级、熔断与故障切换实战打下概念基础。

一、高可用目标：从“不宕机”到“可接受的失败”

支付系统的高可用目标，本质是在故障不可避免的前提下，保证核心交易链路仍能对外提供可接受的服务。这里的“可接受”包含三个维度：

• 可用性：系统在给定时间内可正常处理请求的比例，通常用“几个9”衡量。
• 连续性：故障发生时，业务恢复的时间窗口（RTO）与数据丢失容忍度（RPO）。
• 一致性：在降级或切换过程中，资金、订单、账务状态不能出现错乱。

对支付而言，高可用不等于所有功能都可用。更现实的目标是：核心支付链路优先保障，非核心功能允许降级。例如，营销查询、积分展示可以短暂不可用，但下单、扣款、回调必须保持可用与最终一致。

二、SLA、SLO与SLI：把可用性变成可管理的数字

很多团队把SLA当成口号，问题在于缺少中间的SLO和底层的SLI。三者关系可以这样理解：

SLO通常比SLA更严格，留出“内部缓冲”。例如对外SLA承诺99.99%，内部SLO应设为99.995%，这样才有余量应对突发故障。SLI的采集必须贴近真实用户路径，不能只看网关入口，还要覆盖下游渠道、数据库和回调链路。

# 示例：支付核心接口SLO定义
slo:
  name: payment_core_success_rate
  sli: success_requests / total_requests
  target: 99.95%
  window: 30d
  error_budget: 0.05%
  alert: burn_rate > 2 for 5m

错误预算（Error Budget）是SLO落地的关键：当预算消耗过快时，应暂停非必要变更，优先修复稳定性问题。这让高可用从“运维背锅”变成“研发、运维、业务共同约束”。

三、容错设计原则：假设一切都会失败

容错设计的核心思想是：不要假设依赖永远可用。支付系统依赖银行渠道、第三方支付、数据库、缓存、消息队列，任何一环都可能抖动或超时。常见原则包括：

1. 冗余与隔离：关键组件多实例部署，按机房、渠道、租户隔离，避免故障扩散。
2. 超时与重试：所有远程调用必须设置合理超时，重试要带退避和幂等保护。
3. 熔断与降级：当依赖错误率超过阈值时快速失败，切换到备用通道或返回兜底结果。
4. 幂等与补偿：支付请求、回调、退款必须支持幂等，失败后通过补偿任务修复。
5. 可观测性：日志、指标、链路追踪缺一不可，否则故障切换就是盲切。

四、单点故障与雪崩效应：可用性的两大天敌

单点故障（SPOF）是指系统中某个组件一旦失效，整个链路或大部分链路不可用。支付系统中常见的单点包括：单一数据库主库、单一渠道证书、单一配置中心、单一DNS、单一机房出口。单点不一定是一个节点，也可能是一个逻辑角色，例如“唯一负责回调的消费者”。

雪崩效应则更隐蔽：某个下游变慢，导致上游线程池被占满，进而拖垮整个服务，最终引发全链路崩溃。典型场景是支付网关调用银行渠道超时，线程堆积，网关无法处理新请求，商户端重试又加剧流量，形成恶性循环。

上图展示了从商户请求到银行渠道的典型链路：当渠道A变慢，网关线程堆积，若没有熔断和隔离，故障会反向传播到整个支付系统。正确的做法是在渠道适配层设置熔断，快速切换到渠道B/C，同时限制重试次数，避免流量放大。

五、案例与复盘：一次渠道超时引发的全站故障

某支付平台曾因银行渠道A升级导致响应时间从200ms升至5s。网关未设置合理超时，线程池在几分钟内被占满，随后所有支付请求失败。商户端自动重试，流量翻倍，最终连查询接口也被拖垮。复盘发现三个问题：

• 渠道调用超时设置为30s，远大于业务容忍度；
• 没有熔断机制，错误率100%仍持续调用；
• 线程池未隔离，渠道A的故障影响了所有渠道。

改进措施包括：将超时降至800ms，增加熔断器（错误率50%持续10s即熔断），按渠道隔离线程池，并配置备用渠道自动切换。上线后再次遇到渠道抖动时，系统在3秒内完成降级，核心支付成功率保持在99.9%以上。

总结来看，支付系统高可用需要从目标定义开始，用SLA/SLO/SLI把可用性量化，用容错原则指导设计，并重点识别单点故障与雪崩效应。只有把“失败”作为设计输入，后续的降级、熔断与故障切换才有坚实的落地基础。