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

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

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

5 號(hào) Cloudflare 又崩了，連帶著 Shopify、宕機(jī)監(jiān)控平臺(tái) DownDetector 一起 “躺平”！

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

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

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

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

• 
  

• ?影響范圍超廣：不只是支付寶和淘寶，閑魚、1688、餓了么、盒馬整個(gè)阿里電商生態(tài)的支付鏈路全受波及；第三方應(yīng)用更慘，除了《原神》，還有不少小平臺(tái)因?yàn)榻尤胫Ц秾毥涌冢苯記]法收付款。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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