支付寶、淘寶、閑魚又雙叕崩了，Cloudflare也癱了連監(jiān)控都掛，根因藏在哪？

支付寶、淘寶、閑魚又雙叕崩了，Cloudflare也癱了連監(jiān)控都掛，根因藏在哪？

最近兩天的互聯(lián)網(wǎng)堪稱 “故障連連看”——12 月 4 號晚上阿里系集體 “掉鏈子”，支付寶、淘寶、閑魚付款亂套！

5 號 Cloudflare 又崩了，連帶著 Shopify、宕機監(jiān)控平臺 DownDetector 一起 “躺平”！

先看 12.4 阿里系：支付扣錢不更新訂單，用戶被逼重復(fù)付款

這事兒發(fā)生在 12 月 4 日晚 21 點左右，不少人正趁著睡前刷淘寶、閑魚下單，結(jié)果直接撞上 “支付黑洞”—— 銀行卡明明扣了錢，訂單卻一直顯示 “待付款”；有人以為沒付成功，手一抖多點了幾下，同一筆訂單被扣了兩三遍。

星哥翻了下用戶反饋和媒體報道，這波故障的 “癥狀” 太典型了：

• ?時間線很清晰：21 點開始有用戶反饋異常，21:41 米哈游《原神》直接發(fā)公告 “甩鍋”，說支付寶服務(wù)異常導(dǎo)致充值不到賬；22 點左右 “淘寶崩了”“支付寶崩了”“閑魚崩了” 三個話題直接沖上天眼熱搜前十；直到 23:37，第一財經(jīng)才確認(rèn)故障基本修復(fù)，前后折騰了近 2 個半小時。

• 
  

• ?影響范圍超廣：不只是支付寶和淘寶，閑魚、1688、餓了么、盒馬整個阿里電商生態(tài)的支付鏈路全受波及；第三方應(yīng)用更慘，除了《原神》，還有不少小平臺因為接入支付寶接口，直接沒法收付款。

• ?客服徹底癱瘓：閑魚客服排隊人數(shù)破 9000，用戶想查個訂單、退個款都找不到人；淘寶客服只會機械回復(fù) “不要重復(fù)支付，稍后更新”，至于 “到底為啥崩”，截至星哥發(fā)稿，阿里和螞蟻還沒給過明確的技術(shù)說明。

從技術(shù)角度扒：大概率還是 “消息隊列” 惹的禍？

熟悉分布式系統(tǒng)的朋友應(yīng)該知道，支付寶這種量級的支付平臺，靠的是 “分布式事務(wù)” 保證數(shù)據(jù)一致性 —— 這里就得提支付寶用的 TCC（Try-Confirm-Cancel）模型：用戶點支付后，支付服務(wù)先扣錢（Try 階段），再發(fā)一條 “Confirm 消息” 給訂單服務(wù)，通知它把狀態(tài)改成 “已支付”。

這次故障的核心，就是 “Confirm 消息” 沒傳到位。星哥分析了下，排除掉三種不可能：

1. 1.不是風(fēng)控誤殺：要是風(fēng)控觸發(fā)，用戶會看到 “登錄環(huán)境異常” 之類的提示，但這次所有人都是 “扣錢成功訂單不變”，沒任何風(fēng)控報錯；

2. 2.不是數(shù)據(jù)庫宕機：核心數(shù)據(jù)庫要是掛了，支付本身就會失敗，根本不會出現(xiàn) “扣錢成功” 的情況；

3. 3.不是網(wǎng)絡(luò)中斷：網(wǎng)絡(luò)問題只會導(dǎo)致請求超時，不會出現(xiàn) “支付成了、訂單沒成” 這種 “半吊子” 狀態(tài)。

最可能的還是消息隊列或分布式事務(wù)協(xié)調(diào)出了問題—— 支付寶用的消息中間件是基于 RocketMQ 的，負(fù)責(zé)在支付、訂單、賬務(wù)這些微服務(wù)之間傳消息。要是消息隊列積壓、消費端超時，或者事務(wù)回查機制失效，訂單服務(wù)收不到 “付款成功” 的通知，自然就卡在 “待付款”。

再看 12.5 Cloudflare：500 錯誤連串炸，監(jiān)控平臺都崩了

這邊阿里系的故障剛平息，12 月 5 號下午 Cloudflare 又 “掉鏈子” 了 —— 打開 Cloudflare 官網(wǎng)、Shopify，甚至監(jiān)控宕機的 DownDetector，全是 “500 Internal Server Error”。

星哥去 Cloudflare 狀態(tài)頁查了下，官方倒是更新了信息，但看下來更像是 “維護(hù)翻車”：

• ?故障范圍：不只是 Cloudflare 自身，依賴它的 Shopify（獨立站賣家哭暈）、Zendesk、GitLab 這些平臺都出現(xiàn)訪問問題；更諷刺的是，監(jiān)控宕機的 DownDetector 也因為用了 Cloudflare，自己先崩了，用戶連 “看誰崩了” 都做不到。

• ?官方說法：狀態(tài)頁顯示，底特律（DTW）、芝加哥（ORD）數(shù)據(jù)中心正在進(jìn)行計劃維護(hù)，時間是 12 月 5 日 07:00-13:00 UTC（對應(yīng)國內(nèi)下午 3 點到晚上 9 點），維護(hù)期間會重路由流量，可能導(dǎo)致延遲；同時還在調(diào)查 “控制面板及 API 服務(wù)問題”，用戶調(diào)用 API 會失敗或報錯。

• ?監(jiān)控數(shù)據(jù)佐證：Datadog 的 Updog 監(jiān)控顯示，從 5 號下午 4 點 45 分開始，Cloudflare API 出現(xiàn) “持續(xù)降級”，截至星哥寫稿，故障已經(jīng)持續(xù)了 25 分鐘以上 —— 要知道 Cloudflare 號稱 “賽博菩薩”，負(fù)責(zé)全球大量網(wǎng)站的 CDN 和安全防護(hù)，它一崩，連鎖反應(yīng)比想象中還大。

結(jié)合10月微軟、11月的Cloudflare的事故，2025年的注定是個不安定的時間

雖然影響對象不同，但暴露的問題很值得行業(yè)反思：

對阿里系這種支付生態(tài)來說，分布式事務(wù)的 “最后一公里” 太關(guān)鍵了—— 消息隊列作為微服務(wù)之間的 “信使”，一旦出問題，支付和訂單就會 “各說各的”，用戶的錢和訂單狀態(tài)對不上，信任度很容易崩塌。而且相比 2024 年雙十一還給了 “消息庫故障” 的說明，這次至今沒給技術(shù)細(xì)節(jié)，沉默反而容易引發(fā)更多猜測。

最后說句實在的：現(xiàn)在大家的生活、工作全靠互聯(lián)網(wǎng)撐著，支付系統(tǒng)扣錢不接單、云服務(wù)說崩就崩，影響的是千萬人的體驗。

希望不管是阿里還是 Cloudflare，都能盡快給出完整的技術(shù)復(fù)盤，也給行業(yè)提個醒 —— 大型系統(tǒng)的穩(wěn)定性，真的容不得半點馬虎。