拉卡拉开放平台

依赖的外部服务总有不可用的时候。区别在于：有的团队提前想好了怎么办，有的团队到时候才开始想。

不可用有哪几种表现

降级与备用通道

• 降级：暂时关闭或简化某些非核心能力，保住主链路；
• 备用通道：切换到另一条可用路径，能力不缺失但可能成本或体验不同。

前者牺牲能力保稳定，后者牺牲部分体验保能力。选择哪一个，取决于业务能否接受能力缺失。

没演练过的不算兜底

写进文档的兜底方案，如果没有实际跑通过，在真正需要时大概率也跑不通。

演练应当覆盖：触发条件是否可靠、切换是否顺畅、切换后功能是否正常。

恢复之后的收尾

1. 确认不可用期间的请求状态，特别是结果不明的那些；
2. 逐笔核对，确认没有遗漏或重复处理；
3. 补充对账，把这一段时间单独核对一遍；
4. 记录全过程，作为后续改进的依据。

第三步尤其重要：异常时段的账目最容易留下隐患，单独核对一遍能避免问题延后爆发。

把不可用当成常态

高可用不是从不发生问题，而是问题发生时系统仍能给出可控的结果。从这个角度设计，兜底就不是额外工作，而是主链路的一部分。

超时设定的层次

超时不是一个值，而是一组值。不同环节应当有不同的超时设定：

分层设定的好处是：能区分是连不上、处理慢还是整体卡住，从而采取不同的应对。

依赖清单

兜底设计的前提是知道自己依赖了什么。建议维护一份依赖清单：

• 列出所有外部依赖及其作用；
• 标注每一项不可用时会发生什么；
• 写明每一项的兜底方式。

这份清单在系统规模变大之后尤其重要——没有人能凭记忆说清所有的依赖关系。

兜底的代价也要考虑

兜底不是免费的：备用路径可能成本更高，降级可能损失体验，自动重试可能增加延迟。

因此兜底方案应当说明代价，让决策者知道触发兜底意味着什么，而不是把它当成一个无害的开关。

把演练变成例行

兜底方案写成文档只是第一步，真正可靠的方式是定期演练：在可控环境下模拟不可用，走一遍完整的兜底流程。演练中发现的问题，正是真正发生时最可能绊住你的那些。

通知不到的情况也要考虑

兜底方案里最容易漏掉的一环是通知：系统出问题时，如果通知本身也依赖出问题的通道，那么相关人员可能很久才知道。

• 告警通道应与业务通道相互独立；
• 关键告警应有多种送达方式；
• 定期验证告警是否真的能收到。

一个从来没被验证过的告警，在最需要它的那一刻往往不会响。

兜底方案的存在感，只在真正出问题的那几分钟里体现。但恰恰是这几分钟，决定了这次故障是一次事故还是一次小插曲。

兜底方案写在文档里只是开始，定期演练才是让它真正可用的唯一方式。没有演练过的方案，在关键时刻往往只是一纸空文。

兜底不是可有可无的附加项，而是系统在异常时刻唯一能依靠的东西。提前想清楚、提前演练过，它才会在关键时刻真的顶用。