2015年1月31日，阿里云課堂第六期在北京開課，“大型互聯(lián)網應用架構之存儲與分發(fā)”主題分享在眾多朋友的期待下精彩上演，現(xiàn)場觀眾再次爆滿。本次活動中，姚偉斌（花名：文景）和李文兆兩位講師為大家獻上了精彩演講，并在OpenSpace環(huán)節(jié)與觀眾展開討論，積極互動。應廣大用戶要求，我們將云課堂講師現(xiàn)場分享內容全文整理出來，供大家參考。阿里云課堂會繼續(xù)在全國各地陸續(xù)開課，歡迎大家繼續(xù)支持！
以下為講師姚偉斌（花名：文景）的分享內容：
我前面會講一下CDN的用途，也會講一些CDN產品，在后面我會講CDN的架構和設計。
一、CDN的用途
目前，CDN主要是分幾個方向發(fā)展，比如靜態(tài)內容的分發(fā)、視頻流媒體的分發(fā)、動態(tài)資源的加速、源站保護等，其中最基本的是用來做靜態(tài)內容分發(fā)。阿里CDN現(xiàn)在最大的用途是用作淘寶所有圖片的分發(fā)。視頻流媒體的分發(fā)功能使用，發(fā)展速度也非常之快。CDN一些特色功能的應用，如動態(tài)資源的加速，還有SSL的接入、SPDY的接入等。CDN還有一個功能是源站保護，它可以通過各種安全防御，實現(xiàn)源站流量的減少。
二、CDN的加速原理
CDN最大的特色在于加速。那么，CDN是如何實現(xiàn)各種“加速”，發(fā)揮“加速”功用呢？如下圖所示，CDN有很多節(jié)點，通過域名實現(xiàn)就近接入。當用戶發(fā)起一個請求后，CDN會回源取，然后把文件就近緩存在那個節(jié)點的服務器上。假設北京的用戶到北京節(jié)點只需4毫秒，后面寫了一個90%的請求其實都直接命中到了服務器，那么還有10%的流量回到了二級cache節(jié)點。而二級cache節(jié)點也是同樣的緩存服務器，假設它的命中率也是90%，那么最終只有1%的流量到源站。如果純粹回到源站可能需88毫秒，而通過訪問CDN就會大大縮短時間，甚至4毫秒就可以讓用戶拿到一個文件。這是CDN實現(xiàn)加速的基本原理。
三、阿里CDN分布
CDN加速的載體在于節(jié)點，阿里CDN節(jié)點分布可謂星羅棋布，如下圖所示。阿里CDN服務器原先主要用于淘寶圖片的分發(fā)，在全國32�。ㄊ�、區(qū)）均有服務器，有200多個節(jié)點，在一線城市運營商均有機房，甚至在外國也有30余個節(jié)點分布，以提供國外用戶的加速服務。
四、阿里CDN應用
這兩天，我去拜訪了一些客戶。他們把我們的CDN與業(yè)界其他一些比較有名的商業(yè)CDN進行比較統(tǒng)計，得出的結論是：我們CDN的平均延遲大概能有10%到20%的下降。
阿里從2008年開始，就著手自建CDN。不知不覺我們已成為世界上最大的圖片CDN。這可能跟中國的網上購物習慣有關-- 一個商品需要幾十張圖片進行介紹。這使得我們圖片CDN可能跟某些視頻CDN流量有的一拼。從2014年3月起，阿里CDN正式開啟商業(yè)化運營模式。商業(yè)化運營對阿里云CDN的需求，跟圖片CDN區(qū)別是非常大的，這對于我們有很多的挑戰(zhàn)。原來的圖片CDN，對于我們來說，主要是每年大促期間帶來的壓力，至少到2012年，我們CDN唯一任務就是為了“雙十一”。那時，我們會做很多預案以應對瘋狂的流量。下面這一張是CDN的流量圖，就可以看到我們2009到2012年，我們整個水位是非常滿的。這對于我們CDN來說，主要的挑戰(zhàn)在于：做到良好的均衡性。比如這個節(jié)點要把流量定量切到另外一個節(jié)點，我們做了很多的工作。另外，我們在節(jié)點內對軟件穩(wěn)定性和性能等方面也做很多優(yōu)化。比如說現(xiàn)在一個節(jié)點能服務40G，但是有時候節(jié)點面對突然涌過來的大流量時，你甚至來不及調度。這就要求你的軟件至少需要扛過大于40G的能力。每年我們會做5次以上的壓測。在跑滿40G的情況下面，連續(xù)跑一個星期，檢驗以保障我們CDN節(jié)點不會掛掉，能夠繼續(xù)提供比較可靠的服務。這對于軟件的可靠性方面，壓力也是非常大的。
從去年開始，我們整個團隊的開發(fā)方向就轉向做對外服務。從2013年開始，我們CDN的服務能力已經遠超我們自用的能力。就像我們一些PE所說，我們CDN團隊基本上可以坐在那里喝著茶看著雙十一的流量就可以了。
現(xiàn)在阿里CDN的目標是：做到能夠快速、安全、易用，能幫用戶減少成本。
下面是CDN的一些關鍵組件：
- IP庫
- 調度系統(tǒng)
- 緩存系統(tǒng)
- 刷新系統(tǒng)
- 日志系統(tǒng)
CDN需要知道用戶從哪里來，才能調度， IP數(shù)據(jù)庫我們已經做了好幾年。如果你們想去查一下某個IP是從哪里來的，ip.taobao.com這個外部的接口可以用。為了提高準確性，我們還會拿淘寶的收貨IP做對比，查是否這個IP是屬于這個地區(qū)的�，F(xiàn)在在市一級的準確率能做到96%左右。ECS用戶應該可以免費調用我們IP庫的接口。
現(xiàn)在CDN有兩個維度可以進行調度。一是地域的概念，比如說你去瀏覽器里面輸一個www.taobao.com，域名查詢請求會提交到運營商本地的DNS服務器，DNS服務器有一個迭代查詢的過程，最后到了調度中心。調度服務器會根據(jù)源IP。比如你是北京電信的DNS的IP，就將你調度到北京電信的機房去。二是CDN是有高可用性的，調度中心在不停的監(jiān)控所有節(jié)點的健康狀況，一旦發(fā)現(xiàn)這個節(jié)點有問題，會將用戶切換到另外一個節(jié)點。
上圖是CDN節(jié)點的緩存系統(tǒng)，LVS是4層的代理，Tengine主要進行并進行負載均衡，swift是一個高效的緩存服務器，作靜態(tài)文件的緩存用。Tengine和Swift進行一致性hash，可以提高命中率。其他還有一些控制機器，做刷新和配置這些功能。
上圖是Swift的緩存架構淘汰邏輯�，F(xiàn)在我們能做到內存、SSD、SATA三級緩存、可以適應各種尺寸的文件。我們的服務器既能做圖片的緩存，也能做視頻大文件緩存，熱對象會自動上升到內存，冷對象會被淘汰到SATA。為了提高IO性能，我們沒有使用文件系統(tǒng)，直接使用整個裸磁盤。在裸盤上，我們實現(xiàn)了Squid的COSS文件系統(tǒng)。COSS文件系統(tǒng)中都是一個Stripe進行IO寫操作。我們使用8M一個Stripe，新來的文件就append在Stripe里面，每次都是8M的寫，這樣就可以提高IOPS。當Stripe滿以后，寫SSD時，看原有的內容是否熱的，如果是熱點，就放到內存。如果是冷的，就淘汰到內存。
去年阿里CDN開始對外應用以后，用戶增加非常迅速。原來以配制文件的形式管理的配置系統(tǒng)，已經不能滿足業(yè)務需求。于是，我們開發(fā)了一個加載配制模塊，它是lazy的。它的局部性效果非常明顯，雖然我們線上有幾萬個域名，但在一個節(jié)點上，我們發(fā)現(xiàn)也就一兩千個域名在服務，所以按需加載的方式較好。另外我們也做了很多優(yōu)化，10萬域名只占500兆內存，非常高效。同時，我們也能做到全網分鐘級別配置分發(fā)，總體來說，我們的配制可以做到高可靠、可運維。
有時，CDN上的緩存文件更新了，我要把它刪掉。刷新需要全網分發(fā)，而全網的每一臺機器，每一個cache節(jié)點全部要刷，因為我不知道文件存在哪里，都是廣播的，而現(xiàn)在，我們按調度頻道來刷，就能減少一定量的刷新。另外，我們增加了合并功能。比如，現(xiàn)在有100個URL過來刷新，可以合并為一次提交到Cache服務器，從而減少刷新的QPS。此外，Swift支持正則和目錄刷新，只需提交一個請求就可以刷很多內容�，F(xiàn)在從統(tǒng)計數(shù)據(jù)上看，全球節(jié)點99%以上能做到1分鐘的刷新。
目前，我們阿里內部已經實現(xiàn)了海量日志搜集與分析系統(tǒng)。原來我們也是用syslog來搜集日志，在40G跑滿時，syslog丟包非常嚴重。特別是在對外商用以后，日志需要計費，對可靠性要求非常高，所以后來就開發(fā)了一個傳輸日志和實時分析系統(tǒng)。同時，內部也做了一些優(yōu)化，比如合并功能，多條日志合并后再發(fā)到日志服務器上，使用LZO進行流式壓縮，最終收集到中心�，F(xiàn)在我們可以做到產生的日志10分鐘傳到OSS上以供下載。這個速度在業(yè)界來說是非�？斓摹，F(xiàn)在，我們整個CDN的量級大概每天有幾百T的訪問日志，最終都會導入到阿里云ODPS上進行大數(shù)據(jù)分析，比如用戶行為分析。
阿里CDN針對TCP協(xié)議棧的做了優(yōu)化，比如說我們做了基于時間序的丟包發(fā)現(xiàn)機制，TCP的包是有序號的，我們按照序號來查看，如果發(fā)現(xiàn)高序號的TCP的ACK，但是低的沒有發(fā)過來。我們會以更快的一個重傳機制來確保我們低序丟失的包能夠快速發(fā)過來。結合自適應的初始窗口等單邊優(yōu)化措施，最終我們將小對象的平均RT降低20%以上。
這個功能是頁面內容優(yōu)化，就是按照前端優(yōu)化準則進行自動化的內容調整。比如說減少頁面中請求的數(shù)量。我們會做一些靜態(tài)資源文件合并。還有就是盡可能減少頁面大小，我們會主動刪除頁面空白符，還有一個智能Gzip，通過主動發(fā)起JS異步請求，進行探測，即使沒有Accept-Encoding頭也會主動做壓縮。CDN這邊也在跟前端的同學一起來做，比如做一個UA的數(shù)據(jù)庫，去保存每一個User Agent對應的分辨率，不同的分辨率選擇不同尺寸的圖片。
CDN其實不僅僅是靜態(tài)內容的HTTP加速，還可以做TCP協(xié)議的加速。如上圖所示案例顯示，我們最近發(fā)現(xiàn)臺灣用戶訪問淘寶頁面非常慢，特別是從國內到國外這個鏈路是比較差的。我們在臺灣有節(jié)點，香港有節(jié)點，上海有節(jié)點，臺灣到上海延時有200毫秒，臺灣到香港是20毫秒，香港到上海60毫秒。我們發(fā)現(xiàn)，從臺灣、香港再回來反倒更短，所以做了CDN之間的路由優(yōu)化，對TCP連接進行加速。這個圖最終會有很多節(jié)點，就是一個有向圖，我們在每一個CDN節(jié)點上做相互節(jié)點之間的網絡探測，檢測整個網絡的丟包率和延時，構建出一個有權值的表格，然后我們去計算最短路徑。
流媒體這個業(yè)務跟圖片有很大的區(qū)別。圖片的文件大小只有30到50K，但是視頻的平均文件大小可能會到500K到2M。首先，流媒體對于CDN節(jié)點的流量沖擊會非常大，基于傳統(tǒng)的DNS調度有緩存時間，一般有5到10分鐘的延時，甚至有一些節(jié)點都調不走。我們這邊就設計了一個中心式的，基于HTTP協(xié)議的調度方法。當請求某個URL的時候，CDN根據(jù)節(jié)點的負載會直接返回資源或者302重定向，作精確調度。幾乎就沒有延時時間，甚至可以在每個節(jié)點的機器間相互調度。
最近阿里云這邊在做無線加速的產品，我們現(xiàn)在使用了HTTP DNS。無線APP有自己的客戶端，HTTP DNS集成在APP SDK中，當APP啟動時會發(fā)起一個定期異步的請求，去中心請求域名解析，然后把IP保存下來。當下次發(fā)起真實請求時，可以直接去請求了。所以HTTP DNS可以節(jié)省域名解析的時延，也可以避免國內的一些運營商作的域名劫持。
另外一個就是做了SPDY的優(yōu)化，多路優(yōu)化有什么好處呢，一個是復用連接，減少連接數(shù)，提高頁面打開的速度，就手機淘寶這邊的經驗來看，做SPDY鏈路復用最終是能有20%到30%加載頁面時間的降低。
最后一個是安全功能，現(xiàn)在CDN提供了4、7層的DDoS安全防御和WAF，可以使用戶免于攻擊，并提供一站式解決方案。CDN可以提供源站保護功能，靜態(tài)資源CDN可以緩存，最終落到源站的流量都會合并，流量是非常小的�，F(xiàn)在安全服務是不額外收費的。
這是7層攻擊的一個案例，經常有一些用戶說，你們怎么防攻擊的流量算我錢，實際上防攻擊不是免費的。這是我昨天截的圖，這是7層的攻擊，突然間針對原來那個小站有15萬QPS的攻擊流量，它的響應大小是15KB�？梢钥吹街灰蜷_安全功能，CDN已經擋了99%以上的攻擊，并保證它的正常服務，幫用戶節(jié)省了17Gbps的流量費用。
