3月3日， CloudFlare經歷了過去四年間第三次嚴重的事故。UTC時間9：47(北京時間3月3日17：47)，CloudFlare的邊緣路由器發生故障，這導致使用CDN和安全服務的785000多個網站受到影響。約30分鐘后故障被排除，事故持續影響了一個多小時。
CloudFlare的聯合創始人及CEO Matthew Prince在事故當天就通過 blog對事故進行了分析，并向用戶道歉。從廣泛的評論來看，主流輿論對于此次事故還是報以寬容和理解，對CloudFlare的勇于認錯的態度和快速的行動進行了肯定。
圖：CloudFlare的實現原理
據TechCrunch 報道，中國是除美國本土外CloudFlare的最大市場，盡管此次事故在國內也引起了大量討論，但還沒有商業用戶的抱怨聲音(企業用戶每月需支付3000美元)。
去年四月，CloudFlare的月PV達到400億，目前這個數據已經達到1000億。CloudFlare幫助網站節省帶寬、提高訪問速度，并過濾惡意攻擊。
什么引起了事故?
Matthew Prince在blog上表示：
CloudFlare 的管理團隊發現一處DDoS攻擊，監測工具顯示攻擊包大小在 99971 ~ 99985 bytes 左右(正常包大小是 1500 bytes，通常都在 500 ~ 600 bytes)，于是將其規則加入 Juniper 的 Junos 防火墻設置中，不過預期大小的包并沒有被攔截，因為實際上并不存在這么大的數據包，取而代之的是匹配規則的數據包沖刷到內存中，直到內存耗盡，系統崩潰。
通常系統崩潰會自動重啟而恢復工作，但這次例外了。由于系統沒有正常啟動，管理端口沒有響應控制，于是CloufFlare的管理中心只能電話通知全球 14 個國家的 23 個數據中心的管理員硬啟動機器，這個過程大概花費了 30 分鐘。最早恢復的數據中心由于負荷了最多了訪問流量，仍然導致了 CloudFlare 服務的不穩定性，加上等待 DNS 緩存更新等，服務恢復時已經影響已持續超過 1 小時。
我們學到了什么?
網絡技術工程師 IKE123在微博上評論：
1、主因：flowspec的bug引起的加載filter的時候導致的內存泄露。
2、Crash以后未能自動重啟，所有收到該flowspec路由的邊緣設備全玩完。
3、非架構問題，所以SDN/Openflow不會更好。
4、軟件都有bug，這只是flowspec用的少，才有低級錯誤，不過換SDN估計更差(使用案例更少)。
5、ISP玩PCEP(路徑計算單元通信協議)。
他特意向CSDN澄清：SDN和這次事故無關，只是有人提出來說SDN能有幫助。他認為：ISP骨干應該用PCEP，而不是Openflow。 PCEP是集中計算RSVP TE(基于流量工程擴展的資源預留協議)，下發到設備上。Google是大驅動因素。
藍盾股份是國內提供類CloudFlare服務的公司之一，該公司負責應用安全產品線研發總監 余志剛告訴CSDN：
我最近研發的產品是 云防線，技術架構與CloudFlare類似。
CloudFlare 這種技術架構中DNS服務集群充當的是全局負載均衡、智能路由的角色，而其他的分數據中心的運作都將依賴全局的DNS智能集群，如果這個中心集群宕機，將導致整個系統癱瘓，哪怕分中心無任何問題，數據流量也將路由不到。
通過分析官方blog的內容，我猜測CloudFlare 的DNS應該是有熱備的，但可能這兩套系統都在這個核心路由器后面。路由器出問題后導致兩套系統都無法訪問。
余志剛認為，這次事故反映出這種基于SaaS概念的安全系統需要完善一下幾個方面：
1、加強全局負載均衡，也就是DNS智能集群的安全防護及運營水平。
2、在財力允許的情況下，盡量建立DNS智能集群的備份系統，兩套系統做到熱備。
3、將用戶管理系統也就是www.cloudflare.com這個網站管理系統和核心系統分開，當DNS智能集群宕機，無法為用戶網站提供加速、防護服務后，保證管理系統能正常使用，然后給用戶提供快速切換到原有DNS解析服務器的選項。
陳利人認為：
CloudFlare CDN加速的原理：當用戶訪問已經啟用CloudFlare CDN加速網站時，首先通過DNS重定向技術確定最接近用戶的最佳CDN節點，同時將用戶的請求指向該節點。當用戶的請求到達指定節點 時，CloudFlare的服務器(節點上的高速緩存)負責將用戶請求的內容提供給用戶。說白了，就是基于DNS的負載均衡。
在Hacker News上對此次事故有著瘋狂的 討論：
“如果你將Juniper和Cisco的設備放在一起，那么就會產生很多奇怪的問題。”
“最好不用只使用一家供應商。”
“Junos的更新速度顯然慢了。”
“任何設備都不能保證網絡萬無一失。”
敏捷開發者、趴貓網 創始人 王龍：
自己運營的主打產品不要用任何第三方的產品，金窩銀窩不如自己的草窩，所有東西自己來搭建，框架用自己開發的，平臺用自己運維的，服務器用自己的，插件自己來寫，CDN自己搭建，云架構自己部署，就不會出現這種由于第三方問題出現的問題，起碼問題是可控的。
行人23：
電話14個國家23個數據中心管理員只需要30分鐘，放到國內廠商需要多久呢?
wanght1979：
作為剛剛從機房出來的苦逼，深刻理解其困擾。
如果你有任何觀點，不妨在評論中告訴我們。
國內的類CloudFlare市場
在國內， 安全寶、 知道創宇和云防線都提供類CloudFlare的服務。國內兩大CDN 服務商網宿和藍汛這塊業務躍躍欲試，電信運營商已經參與這個市場。盡管市場競爭非常激烈，但和所有其它云計算服務一樣，用戶的 接受程度還很低，“目前來說用戶對這種SaaS概念的安全服務接受程度還比較有限。隨著發展，SaaS服務慢慢被大家接受，這肯定是未 來安全行業發展的方向”，余志剛表示。