支付宝、淘宝、闲鱼又双叕崩了，Cloudflare也瘫了连监控都挂，根因藏在哪？

最近两天的互联网堪称 “故障连连看”——12 月 4 号晚上阿里系集体 “掉链子”，支付宝、淘宝、闲鱼付款乱套！

5 号 Cloudflare 又崩了，连带着 Shopify、宕机监控平台 DownDetector 一起 “躺平”！

打开网易新闻 查看精彩图片

先看 12.4 阿里系：支付扣钱不更新订单，用户被逼重复付款

这事儿发生在 12 月 4 日晚 21 点左右，不少人正趁着睡前刷淘宝、闲鱼下单，结果直接撞上 “支付黑洞”—— 银行卡明明扣了钱，订单却一直显示 “待付款”；有人以为没付成功，手一抖多点了几下，同一笔订单被扣了两三遍。

星哥翻了下用户反馈和媒体报道，这波故障的 “症状” 太典型了：

  • •时间线很清晰：21 点开始有用户反馈异常，21:41 米哈游《原神》直接发公告 “甩锅”，说支付宝服务异常导致充值不到账；22 点左右 “淘宝崩了”“支付宝崩了”“闲鱼崩了” 三个话题直接冲上天眼热搜前十；直到 23:37，第一财经才确认故障基本修复，前后折腾了近 2 个半小时。

  • 打开网易新闻 查看精彩图片

  • •影响范围超广：不只是支付宝和淘宝，闲鱼、1688、饿了么、盒马整个阿里电商生态的支付链路全受波及；第三方应用更惨，除了《原神》，还有不少小平台因为接入支付宝接口，直接没法收付款。

  • •客服彻底瘫痪：闲鱼客服排队人数破 9000，用户想查个订单、退个款都找不到人；淘宝客服只会机械回复 “不要重复支付，稍后更新”，至于 “到底为啥崩”，截至星哥发稿，阿里和蚂蚁还没给过明确的技术说明。

打开网易新闻 查看精彩图片

从技术角度扒：大概率还是 “消息队列” 惹的祸？

熟悉分布式系统的朋友应该知道，支付宝这种量级的支付平台，靠的是 “分布式事务” 保证数据一致性 —— 这里就得提支付宝用的 TCC（Try-Confirm-Cancel）模型：用户点支付后，支付服务先扣钱（Try 阶段），再发一条 “Confirm 消息” 给订单服务，通知它把状态改成 “已支付”。

这次故障的核心，就是 “Confirm 消息” 没传到位。星哥分析了下，排除掉三种不可能：

  1. 1.不是风控误杀：要是风控触发，用户会看到 “登录环境异常” 之类的提示，但这次所有人都是 “扣钱成功订单不变”，没任何风控报错；

  2. 2.不是数据库宕机：核心数据库要是挂了，支付本身就会失败，根本不会出现 “扣钱成功” 的情况；

  3. 3.不是网络中断：网络问题只会导致请求超时，不会出现 “支付成了、订单没成” 这种 “半吊子” 状态。

最可能的还是消息队列或分布式事务协调出了问题—— 支付宝用的消息中间件是基于 RocketMQ 的，负责在支付、订单、账务这些微服务之间传消息。要是消息队列积压、消费端超时，或者事务回查机制失效，订单服务收不到 “付款成功” 的通知，自然就卡在 “待付款”。

打开网易新闻 查看精彩图片

再看 12.5 Cloudflare：500 错误连串炸，监控平台都崩了

这边阿里系的故障刚平息，12 月 5 号下午 Cloudflare 又 “掉链子” 了 —— 打开 Cloudflare 官网、Shopify，甚至监控宕机的 DownDetector，全是 “500 Internal Server Error”。

打开网易新闻 查看精彩图片

星哥去 Cloudflare 状态页查了下，官方倒是更新了信息，但看下来更像是 “维护翻车”：

  • •故障范围：不只是 Cloudflare 自身，依赖它的 Shopify（独立站卖家哭晕）、Zendesk、GitLab 这些平台都出现访问问题；更讽刺的是，监控宕机的 DownDetector 也因为用了 Cloudflare，自己先崩了，用户连 “看谁崩了” 都做不到。

  • •官方说法：状态页显示，底特律（DTW）、芝加哥（ORD）数据中心正在进行计划维护，时间是 12 月 5 日 07:00-13:00 UTC（对应国内下午 3 点到晚上 9 点），维护期间会重路由流量，可能导致延迟；同时还在调查 “控制面板及 API 服务问题”，用户调用 API 会失败或报错。

  • •监控数据佐证：Datadog 的 Updog 监控显示，从 5 号下午 4 点 45 分开始，Cloudflare API 出现 “持续降级”，截至星哥写稿，故障已经持续了 25 分钟以上 —— 要知道 Cloudflare 号称 “赛博菩萨”，负责全球大量网站的 CDN 和安全防护，它一崩，连锁反应比想象中还大。

总结：大型系统的 “稳定性”，从来不是小事

结合10月微软、11月的Cloudflare的事故，2025年的注定是个不安定的时间

虽然影响对象不同，但暴露的问题很值得行业反思：

对阿里系这种支付生态来说，分布式事务的 “最后一公里” 太关键了—— 消息队列作为微服务之间的 “信使”，一旦出问题，支付和订单就会 “各说各的”，用户的钱和订单状态对不上，信任度很容易崩塌。而且相比 2024 年双十一还给了 “消息库故障” 的说明，这次至今没给技术细节，沉默反而容易引发更多猜测。

最后说句实在的：现在大家的生活、工作全靠互联网撑着，支付系统扣钱不接单、云服务说崩就崩，影响的是千万人的体验。

希望不管是阿里还是 Cloudflare，都能尽快给出完整的技术复盘，也给行业提个醒 —— 大型系统的稳定性，真的容不得半点马虎。