1. 课程导入
在支付系统的日常运行中，通道故障几乎是不可避免的：银行侧接口超时、第三方支付公司限流、网络抖动、证书过期、对账文件延迟，甚至某家通道在高峰期整体不可用。真正决定支付系统可用性的，往往不是"永远不出故障"，而是故障发生时系统能否快速降级、精准熔断、平滑切换。本课程围绕这一核心命题展开，帮助你把"通道容错"从零散的经验，升级为一套可设计、可度量、可演练的工程能力。
一、学习目标：从"救火"到"体系化容错"
本课程的学习目标分为四个层次，逐层递进：
- 认知层：理解支付通道降级、熔断、故障切换三者的边界与协作关系，明确它们分别解决"慢"、"错"、"挂"三类问题。
- 设计层：掌握通道健康度模型、熔断阈值、降级策略、路由切换规则的设计方法，能输出可落地的通道容错方案。
- 实现层：能够基于真实支付网关代码，实现熔断器、降级开关、多通道路由与自动切换逻辑。
- 运营层：建立监控告警、灰度演练、故障复盘机制，让容错能力在真实故障中被验证而非停留在文档里。
二、核心价值：为什么支付团队必须掌握它
支付通道是典型的外部依赖，其可用性不受我们控制。没有容错体系的支付系统，会呈现三种典型症状：
- 雪崩：某通道变慢，请求线程被大量占用，拖垮整个支付网关，其他健康通道也无法服务。
- 误伤：一次偶发超时就永久摘除通道，导致可用通道越来越少，成功率持续下降。
- 资损与客诉：切换过程中重复扣款、订单状态不一致，引发资金风险和用户投诉。
掌握本课程内容后，团队可以获得三重价值：可用性价值（支付成功率提升、故障恢复时间从小时级降到分钟级）、资金安全价值（切换过程幂等、状态可追溯）、工程效率价值（故障处理从"人肉切流"变为"策略自动执行"）。
三、整体知识框架：三层六域
本课程的知识体系可以概括为"三层六域"：接入层负责流量识别与路由，控制层负责健康判断与策略决策，执行层负责降级、熔断与切换动作。六个核心领域分别是：通道健康度建模、熔断器机制、降级策略、多通道路由、故障切换与回切、监控与演练。
四、实战路线图：从单通道到多活容错
课程按"由简到繁、由静到动"的路线推进，建议按以下阶段学习与实践：
| 阶段 | 核心任务 | 关键产出 | 验证方式 |
|---|---|---|---|
| 阶段一：单通道加固 | 超时、重试、幂等、异常分类 | 通道调用规范与异常码表 | 单通道故障不扩散 |
| 阶段二：熔断与降级 | 熔断器实现、降级开关、兜底逻辑 | 熔断配置与降级预案 | 慢通道被自动隔离 |
| 阶段三：多通道路由 | 权重路由、健康度评分、自动切换 | 路由策略与切换规则 | 主通道故障自动切备 |
| 阶段四：演练与复盘 | 故障注入、灰度回切、复盘改进 | 演练报告与改进清单 | RTO/RPO 达标 |
五、典型场景与常见误区
先看一个真实感较强的场景：某支付网关接入 A、B、C 三家通道，A 为主通道。某日 A 通道响应时间从 200ms 升至 3s，但并未报错。若没有熔断机制，请求会持续堆积，最终拖垮网关。正确做法是：健康度模型检测到 P99 超阈值，熔断器进入半开状态，路由层将新流量切至 B、C，同时对 A 保持小流量探测，待其恢复后逐步回切。
下面是一段熔断器核心参数的配置示例，后续章节会围绕它展开实现：
circuitBreaker:
channel: A-bank
windowSeconds: 60
minRequestAmount: 20
failureRateThreshold: 0.5
slowCallDurationMs: 1500
slowCallRateThreshold: 0.6
halfOpenProbeCount: 5
openStateDurationSeconds: 30
学习本课程时，请始终带着三个问题：当前通道健康吗？该不该切？切了之后资金和状态一致吗？把这三个问题贯穿到每一节的设计与编码中，你就能把支付通道容错真正做成体系，而不是一堆零散的开关。