2015年1月31日，阿里雲課堂第六期在北京開課，“大型網際網路應用架構之儲存與分發”主題分享在眾多朋友的期待下精彩上演，現場觀眾再次爆滿。 本次活動中，姚偉斌（花名：文景）和李文兆兩位講師為大家獻上了精彩演講，並在OpenSpace環節與觀眾展開討論，積極互動。應廣大使用者要求，我們將 雲課堂講師現場分享內容全文整理出來，供大家參考。阿里雲課堂會繼續在全國各地陸續開課，歡迎大家繼續支援！

以下為講師姚偉斌（花名：文景）的分享內容：

　　我前面會講一下CDN的用途，也會講一些CDN產品，在後面我會講CDN的架構和設計。

一、CDN的用途

　　目前，CDN主要是分幾個方向發展，比如靜態內容的分發、視訊流媒體的分發、動態資源的加速、源站保護等，其中最基本的是用來做靜態內容分發。 阿里CDN現在最大的用途是用作淘寶所有圖片的分發。視訊流媒體的分發功能使用，發展速度也非常之快。CDN一些特色功能的應用，如動態資源的加速，還有 SSL的接入、SPDY的接入等。CDN還有一個功能是源站保護，它可以通過各種安全防禦，實現源站流量的減少。

二、CDN的加速原理

　　CDN最大的特色在於加速。那麼，CDN是如何實現各種“加速”，發揮“加速”功用呢？如下圖所示，CDN有很多節點，通過域名實現就近接入。 當用戶發起一個請求後，CDN會回源取，然後把檔案就近快取在那個節點的伺服器上。假設北京的使用者到北京節點只需4毫秒，後面寫了一個90%的請求其實都 直接命中到了伺服器，那麼還有10%的流量回到了二級cache節點。而二級cache節點也是同樣的快取伺服器，假設它的命中率也是90%，那麼最終只 有1%的流量到源站。如果純粹回到源站可能需88毫秒，而通過訪問CDN就會大大縮短時間，甚至4毫秒就可以讓使用者拿到一個檔案。這是CDN實現加速的基 本原理。

三、阿里CDN分佈

　　CDN加速的載體在於節點，阿里CDN節點分佈可謂星羅棋佈，如下圖所示。阿里CDN伺服器原先主要用於淘寶圖片的分發，在全國32省（市、區）均有伺服器，有200多個節點，在一線城市運營商均有機房，甚至在外國也有30餘個節點分佈，以提供國外使用者的加速服務。

四、阿里CDN應用

　　這兩天，我去拜訪了一些客戶。他們把我們的CDN與業界其他一些比較有名的商業CDN進行比較統計，得出的結論是：我們CDN的平均延遲大概能有10%到20%的下降。

　　阿里從2008年開始，就著手自建CDN。不知不覺我們已成為世界上最大的圖片CDN。這可能跟中國的網上購物習慣有關--  一個商品需要幾十張圖片進行介紹。這使得我們圖片CDN可能跟某些視訊CDN流量有的一拼。從2014年3月起，阿里CDN正式開啟商業化運營模式。商 業化運營對阿里雲CDN的需求，跟圖片CDN區別是非常大的，這對於我們有很多的挑戰。原來的圖片CDN，對於我們來說，主要是每年大促期間帶來的壓力， 至少到2012年，我們CDN唯一任務就是為了“雙十一”。那時，我們會做很多預案以應對瘋狂的流量。下面這一張是CDN的流量圖，就可以看到我們 2009到2012年，我們整個水位是非常滿的。這對於我們CDN來說，主要的挑戰在於：做到良好的均衡性。比如這個節點要把流量定量切到另外一個節點， 我們做了很多的工作。另外，我們在節點內對軟體穩定性和效能等方面也做很多優化。比如說現在一個節點能服務40G，但是有時候節點面對突然湧過來的大流量 時，你甚至來不及排程。這就要求你的軟體至少需要扛過大於40G的能力。每年我們會做5次以上的壓測。在跑滿40G的情況下面，連續跑一個星期，檢驗以保 障我們CDN節點不會掛掉，能夠繼續提供比較可靠的服務。這對於軟體的可靠性方面，壓力也是非常大的。

　從去年開始，我們整個團隊的開發方向就轉向做對外服務。從2013年開始，我們CDN的服務能力已經遠超我們自用的能力。就像我們一些PE所說，我們CDN團隊基本上可以坐在那裡喝著茶看著雙十一的流量就可以了。

　　現在阿里CDN的目標是：做到能夠快速、安全、易用，能幫使用者減少成本。

下面是CDN的一些關鍵元件：

• IP庫
• 排程系統
• 快取系統
• 刷新系統
• 日誌系統

　　CDN需要知道使用者從哪裡來，才能排程， IP資料庫我們已經做了好幾年。如果你們想去查一下某個IP是從哪裡來的，ip.taobao.com這個外部的介面可以用。為了提高準確性，我們還會拿 淘寶的收貨IP做對比，查是否這個IP是屬於這個地區的。現在在市一級的準確率能做到96%左右。ECS使用者應該可以免費呼叫我們IP庫的介面。

現在CDN有兩個維度可以進行排程。一是地域的概念，比如說你去瀏覽器裡面輸一個www.taobao.com，域名查詢請求會提交到運營商本 地的DNS伺服器，DNS伺服器有一個迭代查詢的過程，最後到了排程中心。排程伺服器會根據源IP。比如你是北京電信的DNS的IP，就將你排程到北京電 信的機房去。二是CDN是有高可用性的，排程中心在不停的監控所有節點的健康狀況，一旦發現這個節點有問題，會將使用者切換到另外一個節點。

上圖是CDN節點的快取系統，LVS是4層的代理，Tengine主要進行並進行負載均衡，swift是一個高效的快取伺服器，作靜態檔案的快取用。Tengine和Swift進行一致性hash，可以提高命中率。其他還有一些控制機器，做重新整理和配置這些功能。

上圖是Swift的快取架構淘汰邏輯。現在我們能做到記憶體、SSD、SATA三級快取、可以適應各種尺寸的檔案。我們的伺服器既能做圖片的緩 存，也能做視訊大檔案快取，熱物件會自動上升到記憶體，冷物件會被淘汰到SATA。為了提高IO效能，我們沒有使用檔案系統，直接使用整個裸磁碟。在裸盤 上，我們實現了Squid的COSS檔案系統。COSS檔案系統中都是一個Stripe進行IO寫操作。我們使用8M一個Stripe，新來的檔案就 append在Stripe裡面，每次都是8M的寫，這樣就可以提高IOPS。當Stripe滿以後，寫SSD時，看原有的內容是否熱的，如果是熱點，就 放到記憶體。如果是冷的，就淘汰到記憶體。

　　去年阿里CDN開始對外應用以後，使用者增加非常迅速。原來以配製檔案的形式管理的配置系統，已經不能滿足業務需求。於是，我們開發了一個載入配 制模組，它是lazy的。它的區域性性效果非常明顯，雖然我們線上有幾萬個域名，但在一個節點上，我們發現也就一兩千個域名在服務，所以按需載入的方式較 好。另外我們也做了很多優化，10萬域名只佔500兆記憶體，非常高效。同時，我們也能做到全網分鐘級別配置分發，總體來說，我們的配製可以做到高可靠、可 運維。

有時，CDN上的快取檔案更新了，我要把它刪掉。重新整理需要全網分發，而全網的每一臺機器，每一個cache節點全部要刷，因為我不知道檔案存在 哪裡，都是廣播的，而現在，我們按排程頻道來刷，就能減少一定量的重新整理。另外，我們增加了合併功能。比如，現在有100個URL過來重新整理，可以合併為一次 提交到Cache伺服器，從而減少重新整理的QPS。此外，Swift支援正則和目錄重新整理，只需提交一個請求就可以刷很多內容。現在從統計資料上看，全球節點 99%以上能做到1分鐘的重新整理。

　　目前，我們阿里內部已經實現了海量日誌蒐集與分析系統。原來我們也是用syslog來蒐集日誌，在40G跑滿時，syslog丟包非常嚴重。特 別是在對外商用以後，日誌需要計費，對可靠性要求非常高，所以後來就開發了一個傳輸日誌和實時分析系統。同時，內部也做了一些優化，比如合併功能，多條日 志合併後再發到日誌伺服器上，使用LZO進行流式壓縮，最終收集到中心。現在我們可以做到產生的日誌10分鐘傳到OSS上以供下載。這個速度在業界來說是 非常快的。現在，我們整個CDN的量級大概每天有幾百T的訪問日誌，最終都會匯入到阿里雲ODPS上進行大資料分析，比如使用者行為分析。

　　阿里CDN針對TCP協議棧的做了優化，比如說我們做了基於時間序的丟包發現機制，TCP的包是有序號的，我們按照序號來檢視，如果發現高序號 的TCP的ACK，但是低的沒有發過來。我們會以更快的一個重傳機制來確保我們低序丟失的包能夠快速發過來。結合自適應的初始視窗等單邊優化措施，最終我 們將小物件的平均RT降低20%以上。

　　這個功能是頁面內容優化，就是按照前端優化準則進行自動化的內容調整。比如說減少頁面中請求的數量。我們會做一些靜態資原始檔合併。還有就是盡 可能減少頁面大小，我們會主動刪除頁面空白符，還有一個智慧Gzip，通過主動發起JS非同步請求，進行探測，即使沒有Accept-Encoding頭也 會主動做壓縮。CDN這邊也在跟前端的同學一起來做，比如做一個UA的資料庫，去儲存每一個User Agent對應的解析度，不同的解析度選擇不同尺寸的圖片。

　CDN其實不僅僅是靜態內容的HTTP加速，還可以做TCP協議的加速。如上圖所示案例顯示，我們最近發現臺灣使用者訪問淘寶頁面非常慢，特別是 從國內到國外這個鏈路是比較差的。我們在臺灣有節點，香港有節點，上海有節點，臺灣到上海延時有200毫秒，臺灣到香港是20毫秒，香港到上海60毫秒。 我們發現，從臺灣、香港再回來反倒更短，所以做了CDN之間的路由優化，對TCP連線進行加速。這個圖最終會有很多節點，就是一個有向圖，我們在每一個 CDN節點上做相互節點之間的網路探測，檢測整個網路的丟包率和延時，構建出一個有權值的表格，然後我們去計算最短路徑。

流媒體這個業務跟圖片有很大的區別。圖片的檔案大小隻有30到50K，但是視訊的平均檔案大小可能會到500K到2M。首先，流媒體對於CDN 節點的流量衝擊會非常大，基於傳統的DNS排程有快取時間，一般有5到10分鐘的延時，甚至有一些節點都調不走。我們這邊就設計了一箇中心式的，基於 HTTP協議的排程方法。當請求某個URL的時候，CDN根據節點的負載會直接返回資源或者302重定向，作精確排程。幾乎就沒有延時時間，甚至可以在每 個節點的機器間相互排程。

　　最近阿里雲這邊在做無線加速的產品，我們現在使用了HTTP DNS。無線APP有自己的客戶端，HTTP DNS整合在APP SDK中，當APP啟動時會發起一個定期非同步的請求，去中心請求域名解析，然後把IP儲存下來。當下次發起真實請求時，可以直接去請求了。所以HTTP DNS可以節省域名解析的時延，也可以避免國內的一些運營商作的域名劫持。

　　另外一個就是做了SPDY的優化，多路優化有什麼好處呢，一個是複用連線，減少連線數，提高頁面開啟的速度，就手機淘寶這邊的經驗來看，做SPDY鏈路複用最終是能有20%到30%載入頁面時間的降低。

　　最後一個是安全功能，現在CDN提供了4、7層的DDoS安全防禦和WAF，可以使使用者免於攻擊，並提供一站式解決方案。CDN可以提供源站保護功能，靜態資源CDN可以快取，最終落到源站的流量都會合並，流量是非常小的。現在安全服務是不額外收費的。

這是7層攻擊的一個案例，經常有一些使用者說，你們怎麼防攻擊的流量算我錢，實際上防攻擊不是免費的。這是我昨天截的圖，這是7層的攻擊，突然間 針對原來那個小站有15萬QPS的攻擊流量，它的響應大小是15KB。可以看到只要開啟安全功能，CDN已經擋了99%以上的攻擊，並保證它的正常服務， 幫使用者節省了17Gbps的流量費用。