差友們，昨天站昨晚你們網(wǎng)速足夠快的個網(wǎng)更新國人話，應(yīng)該已經(jīng)見證了一場互聯(lián)網(wǎng)大戲——

Cloudflare 崩了。讓外

這可不是集體一般的崩，是斷網(wǎng)那種能讓半個地球互聯(lián)網(wǎng)一起陪葬的崩。

剛開始大伙兒還一臉懵逼，昨天站有人發(fā)現(xiàn)推特登不上了，個網(wǎng)更新國人好不容易登上去了吧，讓外啥也刷不出來。集體

同樣的斷網(wǎng)，ChatGPT 也寄了，昨天站設(shè)計工具 Canva 也打不開，個網(wǎng)更新國人國外兄弟正在打 LOL 和瓦羅蘭特的讓外排位呢，直接連不上服務(wù)器了。集體。斷網(wǎng)。

更離譜的是，當所有人想去 Down Detector 查查到底哪個網(wǎng)站崩了的時候，發(fā)現(xiàn) Down Detector 也崩了。

好好好，想看熱鬧，結(jié)果自己成了熱鬧。

差評君昨天也親身經(jīng)歷了這場災(zāi)難。

我正在 Product Hunt 給個 App 投票呢（因為投了給我打五折），結(jié)果死活點不動。后來刷朋友圈吧，又發(fā)現(xiàn)之前給大家推薦的網(wǎng)頁紅警也進不去了。

這一切的始作俑者，就是 Cloudflare。

大部分掛掉的網(wǎng)頁都出現(xiàn)了 Error 500，清清楚楚寫著 Cloudflare 炸了。

只能說一家公司打個噴嚏，全世界感冒。

眼看社交媒體不能逛，ChatGPT 不能聊，游戲不能打，全球網(wǎng)友開始了集體哀嚎。

有人哭訴：就因為 Cloudflare，我的 AI 女友都聯(lián)系不上了。。。

——怎么和美國人形容 Cloudflare 崩了有多嚴重？

——你們沒漢堡吃了（*點餐機崩了）

還有人截了一張動圖，展示了 Cloudflare 服務(wù)中斷后的互聯(lián)網(wǎng)世界。。。

甚至有人發(fā)現(xiàn)了新大陸，Cloudflare 崩了之后我的生活全是藍天白云。

就在這一片哀嚎聲中，有個叫 MrShibolet 的用戶發(fā)的推特，突然火了：

Cloudflare 入職第一天，推送了點更新，下午準備休息咯??

配圖里的他站在 Cloudflare 前臺前，擺著不太聰明的姿勢，雙手扶著衣邊，倔強的嘴角微微上揚。

這條推特一下傳開了，60 萬次閱讀，所有人都在說：兄弟第一天上班就是最后一天。。。

但其實，這哥們是整活的。

上個月 AWS 崩的時候，他也發(fā)過一模一樣的推文，這次無非是把名字換成了 Cloudflare。

行了，現(xiàn)在你應(yīng)該知道昨晚的互聯(lián)網(wǎng)有多熱鬧了。。。

到這肯定有人好奇，Cloudflare 到底是個啥？憑啥它崩了，這么多網(wǎng)站都得跟著炸？

簡單說，Cloudflare 就像是互聯(lián)網(wǎng)的物業(yè)公司，負責網(wǎng)站的安全、加速、流量管理。

主要業(yè)務(wù)包括 CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）、DDoS 防護、Web 應(yīng)用防火墻、DNS 服務(wù)等等。

正常情況下，你訪問一個網(wǎng)站，就是你的瀏覽器直接連到網(wǎng)站服務(wù)器。但如果網(wǎng)站用了 Cloudflare，流程就變成了：

你的瀏覽器 → Cloudflare → 網(wǎng)站服務(wù)器 → Cloudflare → 返回給你。

你說繞這么大圈子圖個啥呢？

圖的是：又快又穩(wěn)。

Cloudflare 在全球鋪了 330 多個數(shù)據(jù)中心，當你訪問用了 Cloudflare 的網(wǎng)站時，它會自動把你導(dǎo)向離你最近的那個數(shù)據(jù)中心，這樣訪問速度會快很多。

這就好比你網(wǎng)購，商家從本地倉發(fā)貨，當然比外地的總倉要快很多。

除了快，Cloudflare 還給網(wǎng)站當保鏢，防 DDoS 攻擊、管理機器人爬蟲、緩存內(nèi)容減輕源服務(wù)器壓力。

說白了，網(wǎng)站用了 Cloudflare，就相當于小區(qū)請了一個五星級物業(yè)。

有外人來了，他先站在門口驗個身份，填個來訪記錄，把可疑的人攔在外面，確認是正經(jīng)訪客了再給他們套個五速鞋，加速訪問。

但問題也來了——

一旦這個物業(yè)系統(tǒng)崩了，保安集體腦子宕機，那所有人都進不了小區(qū)——

想訪問網(wǎng)站的人，全被 Cloudflare 攔在了門外。

按理說，一個搞互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的公司，不應(yīng)該輕易崩掉。

可一旦它崩了，那就是真正的牽一發(fā)動全身，崩一屁臭整屋。

所以，什么情況下會崩？

Cloudflare 自己發(fā)了個事故報告，我看完了只有一個感覺：這也能崩？

咱簡單聊一下。

Cloudflare 有個功能叫 Bot Management（機器人管理），它不光能識別出惡意機器人 bot，還能給每個訪問者打分。

網(wǎng)站管理員可以自己定規(guī)矩：你這訪客素質(zhì)得到多少分，才配來我家玩。

比如電商網(wǎng)站可能設(shè)置 70 分以上才能下單，防止搶購機器人；新聞網(wǎng)站估計 30 分就行，畢竟得讓搜索引擎爬蟲進來。

這個打分系統(tǒng)需要一個特征文件，里面記錄了各種判斷標準，一般有 60 種。

訪問速度異?？欤繛g覽器信息很奇怪？扣分！

IP 地址很可疑？行為模式像爬蟲？扣分！

那這個文件是怎么生成的呢？

其實很簡單，系統(tǒng)每隔 5 分鐘就會向后臺數(shù)據(jù)庫喊一嗓子：“喂，把最新的 Bot 特征清單發(fā)我一份！”

這樣頻繁的更新，可以確保應(yīng)對最新的威脅。

本來這套一問一答的流程跑得穩(wěn)穩(wěn)當當。

但在 11 月 18 號上午 11 點（UTC 時間，下同），工程師對數(shù)據(jù)庫搞了一波權(quán)限微調(diào)，直接把數(shù)據(jù)庫搞精神分裂了。

首先，咱們要理解一下 Cloudflare 那個名叫 ClickHouse 的數(shù)據(jù)庫架構(gòu)，它是專門處理海量數(shù)據(jù)的。

另外 Cloudflare 的數(shù)據(jù)量是非常大，一臺服務(wù)器根本塞不下。所以，他們被迫搞了個分店模式（學(xué)名叫分片存儲）。

你可以把 Cloudflare 的數(shù)據(jù)庫想象成一家連鎖書店，在北上廣都有倉庫。

前臺總管（代號 Default）： 它坐在總部辦公室，手里只拿一張索引目錄。它不存真書，只負責告訴你書在哪兒。平時系統(tǒng)來查數(shù)，都是直接問它。

各地分倉庫（代號 r0）： 這些是分布在北京、上海、廣州等地的倉庫，真正的書（數(shù)據(jù)）都在這兒堆著。

原本的流程非常絲滑。

系統(tǒng)喊一嗓子：“給我一份 Bot 特征清單！” 前臺總管（Default） 微微一笑，遞出一張單子：“給，一共 60 個特征。”

特征 1: 訪問速度

特征 2: IP 地址

特征 3: 瀏覽器類型

。。。

系統(tǒng)接單，一切正常。

但在 18 號一波權(quán)限調(diào)整后，把原本指向前臺總管的單線電話，改成了一個連接全公司的大喇叭。

這時候，系統(tǒng)再喊那句老話：“給我一份 Bot 特征清單！”，問題就出現(xiàn)了。

因為沒指名道姓，對面徹底亂套，所有人都在搶答：

前臺總管：“給，這是 60 個特征！”

北京分倉庫（r0-分片 1）：“俺也一樣！這是 60 個特征！”

上海分倉庫（r0-分片 2）：“巧了！我也有一份 60 個特征！”

廣州分倉庫（r0-分片 3）：“俺也一樣！”

一堆分倉庫沖上來對著你的耳朵瘋狂復(fù)讀，原本只有 60 行的特征清單，瞬間被復(fù)制成了幾百行。

尷尬的是，Cloudflare 在設(shè)計系統(tǒng)時，為了性能考慮，給特征文件設(shè)了個上限：最多 200 個特征。

他們想著平時也就 60 多個，撐死 100 個，200 怎么著也夠用了。

誰能想到這幫哥們一復(fù)讀，數(shù)據(jù)量原地起飛，瞬間沖破 200 大關(guān)。

系統(tǒng)一看到這清單，當場兩眼一黑，崩潰不干了。

這還沒完，更騷的來了。

這個崩潰它不是一直崩，而是仰臥起坐的崩。

因為 Cloudflare 數(shù)據(jù)庫集群的更新，是分批進行的。有些節(jié)點數(shù)據(jù)庫更新了，有的還是老版本。

所以系統(tǒng)每 5 分鐘進來抓一個數(shù)據(jù)庫問話，都相當于一次開盲盒。

運氣好 → 碰到老版本 → 總管答復(fù) → 60 條特征數(shù)據(jù) → 網(wǎng)站恢復(fù)了。

運氣背 → 碰到新版本 → 一群人答復(fù) → 幾百條重復(fù)數(shù)據(jù) → 網(wǎng)站又崩了。。。

這就是為啥一開始在用戶眼里，這些網(wǎng)站時好時壞。

上一秒還在罵娘，下一秒突然刷出來了；剛想上推特學(xué)習，看到一半又卡了。

這張 GIF 更傳神了

Cloudflare 的工程師一開始也蒙圈，看著流量忽高忽低、網(wǎng)站時好時壞，第一反應(yīng)是：完了，是不是又被 DDoS 攻擊了？

畢竟前段時間才剛擋下一個 7.3Tbps 的超級攻擊，這種癥狀太像攻擊流量的波動了。

更巧的是，連他們自己的狀態(tài)頁也崩了（后來發(fā)現(xiàn)純屬巧合），搞得工程師們一度懷疑：這是有人連我們的狀態(tài)頁一起攻擊?。?/p>

在嘗試了限流、切換路由等各種操作后，他們終于發(fā)現(xiàn)了是自己人在背刺。

于是 14:24，他們趕緊停止自動生成新配置文件，手動翻出一個之前能正常工作的舊版本，測試確認沒問題，然后推送到全球所有服務(wù)器，大部分服務(wù)開始恢復(fù)。

最終 17:06，所有下游服務(wù)逐步重啟完成，清理掉之前的錯誤狀態(tài)，宕機正式結(jié)束。

整個過程持續(xù)了將近 6 個小時。。。

Cloudflare 在官方事故報告里承認了自己的錯誤，并承諾會加強配置文件檢查、審查所有模塊的容錯能力，具體細節(jié)差評君就不展開了。

這些措施聽起來都挺合理，但每次大廠宕機后都會發(fā)類似的保證書。

上個月 AWS 崩了，這個月 Cloudflare 崩了，過段時間說不定又輪到誰。

對于大多數(shù)普通用戶來說，昨天這場宕機可能就是“網(wǎng)站打不開了，等等就好”。但對于那些嚴重依賴在線服務(wù)的企業(yè)來說，這是真金白銀的損失。

上個月 AWS 的宕機影響了 60 個國家 1700 多萬用戶 ，導(dǎo)致 3500 多家公司業(yè)務(wù)中斷，經(jīng)濟損失每小時超過 7500 萬美元。

這次 Cloudflare 宕機 6 小時，損失恐怕也少不了。

用戶們可能什么都做不了，開發(fā)者可以考慮多云部署、備用方案，但成本和復(fù)雜度都會大大增加，小公司根本玩不起。

咱們就只能期待這些基礎(chǔ)設(shè)施公司真的能從每次事故中吸取教訓(xùn)。

畢竟整個互聯(lián)網(wǎng)就是建立在極少數(shù)基礎(chǔ)設(shè)施公司之上，它就像一座空中樓閣，看起來宏偉無比，但地基只有那么幾根柱子。

哪根柱子晃一晃，整座樓都得跟著顫。