文|邵海楊，UPYUN(又拍云)聯(lián)合創(chuàng)始人兼運維總監(jiān)

國內，隨著互聯(lián)網的高速發(fā)展，因為各大通信公司的政策，造成了南電信北聯(lián)通互通有局限性，再加上大小且質量參差不齊的運營商，在這特殊的氛圍的互聯(lián)互通下號稱“八線合一”的機房開始嶄露頭角?；ヂ?lián)網的廣泛性使得網民分散在全國各地，由于全國地區(qū)的經濟發(fā)展和互聯(lián)網建設的不平衡，實際網民的體驗往往受限于最后一公里的速度。在技術大噴井的年代，一些無聊或者有目的黑客攻擊也開始涌現(xiàn)，無論是滲透還是DDoS攻擊都非常頻繁，時刻威脅著網站的安全……

上述種種問題，作為應用服務提供商，我們要如何解決此類問題呢?歸根結底就是要充分利用好CDN(Content Delivery Network，即內容分發(fā)網絡)。

CDN的作用可以幫助我們解決哪些問題?

緩存代理

緩存代理類似內容提供商源數(shù)據(jù)中心的一個透明鏡像，這些內容可以在邊緣服務器中緩存和分發(fā)，對于普通的網絡用戶來講，它通過智能DNS的篩選，用戶的請求被透明地指向離他最近的省內骨干節(jié)點，最大限度的縮短用戶信息的傳輸距離。在任何時間、地點或者不同的運營商之間(尤其在中國)，快速響應用戶請求。

它是通過在網絡各處放置節(jié)點服務器，所以無需更改源站的網絡拓撲，而是根據(jù)智能路由和用戶就近原則匹配，從而確保了內容快又穩(wěn)定的傳輸，大大提高了用戶訪問網站的響應速度。

路由加速

CDN服務初衷是確?？焖倏煽康胤职l(fā)靜態(tài)內容，相對于動態(tài)內容來說，由于動態(tài)內容必須長連接來操持連接和通訊，只是用戶到服務商之間的鏈路和質量都無法控制。因此為了提供快速的網絡體驗，有必要事先設置一些最佳路由。如省內骨干網，雙線機房，以改善用戶的網絡體驗。在中國典型的互聯(lián)互通問題上，網絡游戲加速就是一些最佳實踐。

安全防護

利用好了CDN網絡，無論面對是滲透還是DDoS攻擊，攻擊的目標大都會被指向到了CDN，進而保護了用戶源站。因為CDN是分布式的，所以即使遭受DDoS攻擊，也具備分散性，大大減少了源站收到毀滅打擊的可能性。在架構的前期，還可以通過CDN做一些前置的安全保護工作，如攔截SQL注入、XSS跨站、網站掛馬、篡改等黑客攻擊。

節(jié)省成本

CDN節(jié)點機房只需要在當?shù)剡\營商的單線機房，或者帶寬相對便宜的城市，采購成本低。由于通過CDN減輕了源站壓力，節(jié)點越多，源站面對任何時間高峰時的帶寬峰值會被平均拉低。從而降低了后端服務器硬件規(guī)模和帶寬的采購成本。 由于源站服務器規(guī)模的減少，后期運維成本也大大減少，可謂是一舉多得。

由此可見，為了能夠滿足全國乃至世界各地和多線路運營商的不同用戶都有最好的體驗，構建CDN的分布式服務其重要性不言而喻。但是，在面對如何根據(jù)自身場景去設計一個CDN架構，或者如何選擇以一個適合自己CDN服務提供商，這里面也有許多問題需要考量。

我們要設計穩(wěn)定高效的CDN架構需要考慮哪些因素?

存儲介質 vs IO的關系

這里先簡單的介紹一下SSD介質的一些考量。SSD作為采用電子存儲介質進行數(shù)據(jù)存儲和讀取的一種技術，突破了傳統(tǒng)機械硬盤的性能瓶頸，固態(tài)硬盤的全集成電路化、無任何機械運動部件的革命性設計，擁有極高的讀取性能。

此環(huán)節(jié)，基本上不需要與傳統(tǒng)的SATA,SAS作性能上的比較，SSD的勝出毫無懸念。而在整體方案中，只需要考慮承受的價格、容量大小(如120GB,160GB,300GB等規(guī)格)、是否能夠滿足設計需求這些問題。

作者建議：如果允許， 能使用SSD，就一定要考慮采用，用空間換性能，提升非常明顯。

這里給幾個SSD實戰(zhàn)的小貼士：

1.選擇EXT4文件系統(tǒng)+TRIM模式(mount -o defaults,noatime,nodiratime,barrier=0,discard),Btrfs建議少冒險

2.如果是使用三星的固態(tài)硬盤，可以嘗試它貢獻給開源的針對固態(tài)硬盤優(yōu)化的F2FS文件系統(tǒng)，相當不錯的選擇

3.I/O Schedulers調度算法，可以使用CFQ或者Deadline算法

4.內核參數(shù)調整，SSD所在硬盤，echo 0 > /sys/block/sda/queue/rotational

隨機讀寫 vs 順序讀寫

機械硬盤的連續(xù)讀寫性很好，但隨機讀寫性能很差。這是因為磁頭移動至正確的磁道上需要時間，隨機讀寫時，也就需要磁頭和探針頻繁的轉動，而機械結構的磁頭和探針的位置調整是十分費時的，這就嚴重影響到硬盤的尋址速度，進而影響到隨機寫入速度。

在存儲小文件(圖片)、OLTP數(shù)據(jù)庫應用時，隨機讀寫性能(IOPS)是最重要指標。由于固態(tài)硬盤沒有普通硬盤的機械結構，也不存在機械硬盤的尋道問題，因此系統(tǒng)能夠在低于1ms的時間內對任意位置存儲單元完成輸入/輸出操作。

作者經驗筆記：

1.BIOS里務必開啟AHCI模式(能支持SATA熱插拔和NCQ尋址方式，提速→300%，當然內核也要支持AHCI模式)

2.SSD的主控芯片相當于大腦中樞，非常重要，建議用Intel,Samsung,Marvell等知名品牌

3.SSD更適合應用在隨機讀寫場景，因此需要認真思考什么場合應用

大文件 vs 小文件

大多數(shù)的存儲系統(tǒng)都是針對大文件而設計的，對小文件而言，大文件的存儲系統(tǒng)無法適應小文件的存儲需求，它造成元數(shù)據(jù)管理、數(shù)據(jù)布局和I/O管理、Cache管理、網絡開銷等方面性能和存儲效率降低。

而且，文件系統(tǒng)的inode是線性存儲的，因此，我們遍歷一個目錄下的文件，需要讀取的磁盤的位置是來回跳躍的。不連續(xù)的讀取意味著磁盤要不斷的進行尋道，那么性能自然可想而知。

作者經驗筆記：

1.無論大小文件，首選EXT4文件系統(tǒng)，Reiserfs/Btrfs不要輕易嘗試(雖然B-tree設計先進)

2.EXT4針對小文件有所改進，使用了inode預分配，這使得inode具有很好的局部性特征，同一目錄文件inode盡量放在一起，加速了目錄尋址與操作性能。

3.EXT4針對大文件使用了extent/delay/multi的數(shù)據(jù)塊分配策略。這些策略使得大文件的數(shù)據(jù)塊保持連續(xù)存儲在磁盤上，數(shù)據(jù)尋址次數(shù)大大減少，顯著提高I/O吞吐量。

4.XFS在大文件方面，表現(xiàn)得不錯，可以使用。

5.SSD盡量應用在隨機小文件讀寫的應用場景，畢竟容量寶貴，在有限的空間保存更多的文件是個明智之選。

6.有開發(fā)實力的可以選用基于LevelDB或其它的KV存儲作底層文件系統(tǒng)，此為后話。

硬件紅利 vs 軟件設計

隨著時間的推移，硬件升級已經突破了摩爾定律，在硬件不斷升級帶來的紅利下，我們從最初的雙核到四核、六核、八核心&超線程，從2G、4G內存到 8G、16G甚至128G內存的情況下，同樣的價格所帶來的硬件升級，性能提升也是非?？捎^的，因此，設置合適的硬件淘汰時間點也很重要，當老舊服務器超過3～5年的服役期，務必考慮做新陳代謝式的升級，充分利用好硬件潛力，保證架構設計平滑有序穩(wěn)定的升級。

反觀軟件設計，相對硬件升級，可談的話題就比較多了，舉個反例：比如說 Squid軟件的缺點(當然，誕生于1996年的Squid與Apache同樣的古老，昔日的時代也是立下了汗馬功勞，但時代進步就不能固步自封必須考慮革新)：

1. 無法利用多核優(yōu)勢，造成單核CPU壓力太高;

2. 雞肋的DNS進程必須要運行;

3. 無法利用大內存做緩存加速;

4. COSS設計上的先天缺陷，初始化甚至重啟后重建索引慢;

5. 偶然機器重啟，修復的效率非常漫長，慢到讓人崩潰。

更多詳情參考：

Varnish Cache 的架構筆記，為什么一些古老的軟件正在被新的設計思想所淘汰，如Nginx替代Apache，ATS替代Squid，Postfix替代Sendmail等等。

建議：

1. 負載均衡技術應用得當，如haproxy,lvs。一方面可以互援互備，另一方面也可以方便輪流升級;

2. 要嘗試新的軟件開發(fā)思路和網絡模型，如epoll,aio,內存加速，連接復用和事件驅動機制。

系統(tǒng)優(yōu)化

1. 系統(tǒng)服務精簡瘦身;

2. 文件系統(tǒng)性能調優(yōu);

3. 提高磁盤IO性能;

4. 優(yōu)化網絡性能;

5. 優(yōu)化路由策略;

6. 數(shù)據(jù)庫的優(yōu)化;

……

這里就不展開詳述了，以后有機會再介紹。

我們有哪些開源的軟件可供選擇，我們了解它們嗎?

開源世界里能夠擔當反向代理及緩存的軟件不少，而且各有優(yōu)劣。在這里，我就不一一介紹每個軟件的介紹了，大家可以自行參考相關鏈接了解。

CDN架構上要充分體現(xiàn)出抗攻擊能力和靈活應變的原則。因此，我們將CDN節(jié)點分解成反向代理+緩存加速+攻擊防御這三個不同層次的功能結構。

•反向代理功能(作用：路由加速，隱藏主節(jié)點，負載均衡)

•緩存加速功能(作用：靜態(tài)推送，節(jié)省后端主節(jié)點帶寬)

•攻擊防御功能(作用：快速解析，匹配過濾惡意攻擊)

作為一個架構師，就必須要考慮如何選型，我們從性能、功能、配置上來進行比較篩選。

現(xiàn)在，我們對這三層功能結構充分了解，在測試調優(yōu)及生產線的實踐檢驗中，我們發(fā)現(xiàn)：

•HTTP防御性能：HAProxy在應對大流量CC攻擊時，做正則匹配及頭部過濾時，CPU消耗只占10%~20%。其它軟件均狂占CPU資源約90%以上，容易成瓶頸導致整個系統(tǒng)無響應。

•反向代理性能：單純轉發(fā)效率以內存緩存型的Varnish性能最強，ATS和Nginx次之，考慮大容量緩存因素，ATS也是個不錯的選擇。Nginx是專門針對C10K的產物，性能不錯，配合自己編寫插件，業(yè)務可塑性很強。

•過濾規(guī)則的可配置性：HAProxy，ATS，Squid均支持規(guī)則文件讀取、ACL定制和熱加載、熱啟動。Nginx則不支持外部文件正則匹配，略差一點，但可塑性強。

負載均衡

高可用性:LVS

LVS是個重量級、高效穩(wěn)定的四層轉發(fā)，雖然不能作七層HTTP協(xié)議的識別，但完全可以架設在七層之前，與上述的各種軟件搭配使用。

所以，LVS的使用并不會影響網絡結構，后續(xù)仍然可以想上就上，前提是要兼顧到LVS的單點故障，這個我們可以通過Keepalived/Heartbeat來實現(xiàn)可用性和可靠性的保證。

作者簡介：

邵海楊，UPYUN(又拍云)聯(lián)合創(chuàng)始人兼運維總監(jiān)，來自杭州Linux用戶組，新浪微博@海洋之心-悟空 ，資深系統(tǒng)運維架構師，業(yè)余撰稿人，致力于開源軟件及前沿科技的研究和探索。