一次促销，客户下单时发现库存校验接口超时，整站下单失败。半小时损失几十万。查下来是第三方库存系统在维护，没有任何降级方案，主流程被一个外部依赖卡死了。
分清哪些依赖可以不要
把外部依赖按重要性分类：核心的（支付跟下单）和可降级的（推荐与评分）以及可延后的（积分跟通知）。别怕麻烦。核心依赖失效要有兜底，可降级的直接跳过，可延后的进队列稍后处理。推荐、评价与积分这类功能，挂了不该影响下单。这方案贵在哪？
技术上就是把它们做成异步或者可跳过的分支，异常时返回空结果，而不是让整个请求失败。这一条改动不大，收益很明显。把必须完成但不要求实时的动作放进队列：发短信和推积分与同步到CRM以及生成报表。第一期做多少？
队列解决"必须做但现在做不了"
对方系统挂了，消息留在队列里，恢复后继续消费。业务主流程不受影响。队列要有重试和死信处理。失败重试几次还不行。就进死信队列并告警，人工介入。没有死信队列，消息会一直堆积或者直接丢掉。两种都不好。
有些环节技术兜不住，只能靠人。比如支付渠道全部不可用，就得有客服手工处理订单的流程。这个流程要提前写下来，谁有权操作、怎么记录以及事后怎么核对，都写清楚。兜底流程平时用不上，但不写就一定乱。
人工兜底要有路径
真出事时，大家都在灭火，没人有空设计流程。提前写好一页纸，比事后复盘十页纸有用。末了顺口提一句：集成系统要假设对方会挂。降级、队列与兜底三手准备，业务才不会被一个外部接口拖停。
系统集成的常见疑问
第三方接口挂了怎么办
按依赖重要性分级：核心依赖设兜底，可降级功能直接跳过，可延后动作进队列。
队列要注意什么
需配置重试与死信队列，失败超限时告警并转人工处理，避免消息堆积或丢失。
什么情况需要人工兜底
外部渠道全都不可用、技术也降不了级，那就得有明确的操作流程和记录机制。
末尾是监控外部依赖。给每个第三方接口设成功率与耗时阈值，掉了就报警。别等业务方发现下不了单，才发现对方的接口早就开始超时了。
总结：系统集成要防单点。分清依赖、用队列缓冲与备人工兜底，业务才不会停。