服務好「最後一千米」，高效CDN架構經驗

國內，隨着互聯網的高速發展，由於各大通訊公司的政策，形成了南電信北聯通互通有侷限性，再加上大小且質量良莠不齊的運營商，在這特殊的氛圍的互聯互通下號稱「八線合一」的機房開始嶄露頭角。互聯網的普遍性使得網民分散在全國各地，因爲全國地區的經濟發展和互聯網建設的不平衡，實際網民的體驗每每受限於最後一千米的速度。在技術大噴井的年代，一些無聊或者有目的******也開始涌現，不管是***仍是DDoS***都很是頻繁，時刻威脅着網站的安全……

上述種種問題，做爲應用服務提供商，咱們要如何解決此類問題呢？歸根結底就是要充分利用好CDN（Content Delivery Network，即內容分發網絡）。

CDN做用

緩存代理

緩存代理相似內容提供商源數據中心的一個透明鏡像，這些內容能夠在邊緣服務器中緩存和分發，對於普通的網絡用戶來說，它經過智能DNS的篩選，用戶的請求被透明地指向離他最近的省內骨幹節點，最大限度的縮短用戶信息的傳輸距離。在任什麼時候間、地點或者不一樣的運營商之間（尤爲在中國），快速響應用戶請求。

它是經過在網絡各處放置節點服務器，因此無需更改源站的網絡拓撲，而是根據智能路由和用戶就近原則匹配，從而確保了內容快又穩定的傳輸，大大提升了用戶訪問網站的響應速度。

路由加速

CDN服務初衷是確保快速可靠地分發靜態內容，相對於動態內容來講，因爲動態內容必須長鏈接來操持鏈接和通信，只是用戶到服務商之間的鏈路和質量都沒法控制。所以爲了提供快速的網絡體驗，有必要事先設置一些最佳路由。如省內骨幹網，雙線機房，以改善用戶的網絡體驗。在中國典型的互聯互通問題上，網絡遊戲加速就是一些最佳實踐。

安全防禦

利用好了CDN網絡，不管面對是***仍是DDoS***，***的目標大都會被指向到了CDN，進而保護了用戶源站。由於CDN是分佈式的，因此即便遭受DDoS***，也具有分散性，大大減小了源站收到毀滅打擊的可能性。在架構的前期，還能夠經過CDN作一些前置的安全保護工做，如攔截SQL注入、XSS跨站、網站掛馬、篡改等******。

節省成本

CDN節點機房只須要在當地運營商的單線機房，或者帶寬相對便宜的城市，採購成本低。因爲經過CDN減輕了源站壓力，節點越多，源站面對任什麼時候間高峯時的帶寬峯值會被平均拉低。從而下降了後端服務器硬件規模和帶寬的採購成本。 因爲源站服務器規模的減小，後期運維成本也大大減小，可謂是一舉多得。 

因而可知，爲了可以知足全國乃至世界各地和多線路運營商的不一樣用戶都有最好的體驗，構建CDN的分佈式服務其重要性不言而喻。可是，在面對如何根據自身場景去設計一個CDN架構，或者如何選擇以一個適合本身CDN服務提供商，這裏面也有許多問題須要考量。

CDN架構

存儲介質 vs IO的關係

這裏先簡單的介紹一下SSD介質的一些考量。SSD做爲採用電子存儲介質進行數據存儲和讀取的一種技術，突破了傳統機械硬盤的性能瓶頸，固態硬盤的全集成電路化、無任何機械運動部件的革命性設計，擁有極高的讀取性能。 

此環節，基本上不須要與傳統的SATA、SAS做性能上的比較，SSD的勝出毫無懸念。而在總體方案中，只須要考慮承受的價格、容量大小（如120GB，160GB，300GB等規格）、是否可以知足設計需求這些問題。

做者建議：若是容許， 能使用SSD，就必定要考慮採用，用空間換性能，提高很是明顯。 

這裏給幾個SSD實戰的小貼士：

• 選擇EXT4文件系統+TRIM模式（mount -o defaults,noatime,nodiratime,barrier=0,discard），Btrfs建議少冒險
  

• 若是是使用三星的固態硬盤，能夠嘗試它貢獻給開源的針對固態硬盤優化的F2FS文件系統，至關不錯的選擇
  

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

• 內核參數調整，SSD所在硬盤，echo 0 > /sys/block/sda/queue/rotational

隨機讀寫 vs 順序讀寫

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

在存儲小文件（圖片）、OLTP數據庫應用時，隨機讀寫性能（IOPS）是最重要指標。因爲固態硬盤沒有普通硬盤的機械結構，也不存在機械硬盤的尋道問題，所以系統可以在低於1ms的時間內對任意位置存儲單元完成輸入/輸出操做。

做者經驗筆記：

1. BIOS裏務必開啓AHCI模式（能支持SATA熱插拔和NCQ尋址方式，提速→300%，固然內核也要支持AHCI模式）
   

2. SSD的主控芯片至關於大腦中樞，很是重要，建議用Intel、Samsung、Marvell等知名品牌
   

3. SSD更適合應用在隨機讀寫場景，所以須要認真思考什麼場合應用

大文件 vs 小文件

大多數的存儲系統都是針對大文件而設計的，對小文件而言，大文件的存儲系統沒法適應小文件的存儲需求，它形成元數據管理、數據佈局和I/O管理、Cache管理、網絡開銷等方面性能和存儲效率下降。 

並且，文件系統的inode是線性存儲的，所以，咱們遍歷一個目錄下的文件，須要讀取的磁盤的位置是來回跳躍的。不連續的讀取意味着磁盤要不斷的進行尋道，那麼性能天然可想而知。

做者經驗筆記： 

1. 不管大小文件，首選EXT4文件系統，Reiserfs/Btrfs不要輕易嘗試（雖然B-tree設計先進）
   

2. EXT4針對小文件有所改進，使用了inode預分配，這使得inode具備很好的局部性特徵，同一目錄文件inode儘可能放在一塊兒，加速了目錄尋址與操做性能。
   

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

4. XFS在大文件方面，表現得不錯，可使用。
   

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

6. 有開發實力的能夠選用基於LevelDB或其它的KV存儲做底層文件系統，此爲後話。

硬件紅利 vs 軟件設計

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

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

1. 沒法利用多核優點，形成單核CPU壓力過高；
   

2. 雞肋的DNS進程必需要運行；
   

3. 沒法利用大內存作緩存加速；

4. COSS設計上的先天缺陷，初始化甚至重啓後重建索引慢；

5. 偶然機器重啓，修復的效率很是漫長，慢到讓人崩潰；
   

更多詳情參考： 

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

建議：

1. 負載均衡技術應用得當，如haproxy、lvs。一方面能夠互援互備，另外一方面也能夠方便輪流升級；

2. 要嘗試新的軟件開發思路和網絡模型，如epoll、aio、內存加速，鏈接複用和事件驅動機制；

系統優化

1. 系統服務精簡瘦身；
   

2. 文件系統性能調優；
   

3. 提升磁盤IO性能；
   

4. 優化網絡性能；
   

5. 優化路由策略；
   

6. 數據庫的優化；
   

……這裏就不展開詳述了，之後有機會再介紹。 

CDN開源

開源世界裏可以擔當反向代理及緩存的軟件很多，並且各有優劣。在這裏，我就不一一介紹每一個軟件的介紹了，你們能夠自行參考相關連接瞭解。

CDN架構上要充分體現出抗***能力和靈活應變的原則。所以，咱們將CDN節點分解成反向代理+緩存加速+***防護這三個不一樣層次的功能結構。 

• 反向代理功能（做用：路由加速，隱藏主節點，負載均衡）

• 緩存加速功能（做用：靜態推送，節省後端主節點帶寬）
  

• ***防護功能（做用：快速解析，匹配過濾惡意***）

做爲一個架構師，就必需要考慮如何選型，咱們從性能、功能、配置上來進行比較篩選。

軟件名稱	性能	功能	過濾規則配置
Squid	不能多核是硬傷； 磁盤緩存容量有優點； 性能中等	多； 支持ACL角色控制； 支持ICP緩存協議	支持外部文件讀取及熱加載； 支持熱啓動
Varnish	多核支持； 內存緩存； 性能強	夠用； 支持集羣，但不支持ICP集羣； 支持後端存活檢查	不支持外部文件讀取； 須要轉義； 支持熱啓動
Nginx	多核支持； 支持代理插件； 性能較強	多； 支持集羣，但不支持ICP集羣； 支持後端存活檢查； 經過插件能夠充當多角色服務器	不支持外部文件讀取； 須要轉義； 支持熱啓動
Apache TS	多核支持； 磁盤/內存緩存； 性能強	夠用； 支持後端存活檢查； 支持ICP協議，Cluster不穩定； 支持插件開發；	支持外部規則文件讀取及熱加載； 支持熱啓動
HAProxy	多核支持； 無緩存； 支持HTTP頭部解析； 性能強	少，只專一HTTP頭部解析和轉發功能； 支持ACL角色控制； 支持後端存活檢查	支持外部規則文件讀取及熱加載； 支持熱啓動； 支持會話粘滯和長鏈接

如今，咱們對這三層功能結構充分了解，在測試調優及生產線的實踐檢驗中，咱們發現：

• HTTP防護性能：HAProxy在應對大流量CC***時，作正則匹配及頭部過濾時，CPU消耗只佔10%~20%。其它軟件均狂佔CPU資源約90%以上，容易成瓶頸致使整個系統無響應。
  

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

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

負載均衡——高可用性:LVS

LVS是個重量級、高效穩定的四層轉發，雖然不能做七層HTTP協議的識別，但徹底能夠架設在七層以前，與上述的各類軟件搭配使用。

因此，LVS的使用並不會影響網絡結構，後續仍然能夠想上就上，前提是要兼顧到LVS的單點故障，這個咱們能夠經過Keepalived/Heartbeat來實現可用性和可靠性的保證。

               -----The End-----