國內，隨著網際網路的高速發展，因為各大通訊公司的政策，造成了南電信北聯通互通有侷限性，再加上大小且質量參差不齊的運營商，在這特殊的氛圍的互聯互通下號稱“八線合一”的機房開始嶄露頭角。網際網路的廣泛性使得網民分散在全國各地，由於全國地區的經濟發展和網際網路建設的不平衡，實際網民的體驗往往受限於最後一公里的速度。在技術大噴井的年代，一些無聊或者有目的黑客攻擊也開始湧現，無論是滲透還是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實戰的小貼士：
1. 選擇EXT4檔案系統+TRIM模式(mount -o defaults,noatime,nodiratime,barrier=0,discard),Btrfs建議少冒險
2. 如果是使用三星的固態硬碟，可以嘗試它貢獻給開源的針對固態硬碟優化的F2FS檔案系統，相當不錯的選擇
3. I/OSchedulers排程演算法，可以使用CFQ或者Deadline演算法
4. 核心引數調整，SSD所在硬碟，echo0 > /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節點分解成反向代理+快取加速+攻擊防禦這三個不同層次的功能結構。
• 反向代理功能（作用：路由加速，隱藏主節點，負載均衡）
• 快取加速功能（作用：靜態推送，節省後端主節點頻寬）
• 攻擊防禦功能（作用：快速解析，匹配過濾惡意攻擊）
作為一個架構師，就必須要考慮如何選型，我們從效能、功能、配置上來進行比較篩選。
現在，我們對這三層功能結構充分了解，在測試調優及生產線的實踐檢驗中，我們發現：
• 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來實現可用性和可靠性的保證。
作者簡介：
邵海楊，UPYUN（又拍雲）聯合創始人兼運維總監，來自杭州Linux使用者組，新浪微博@海洋之心-悟空 ，資深系統運維架構師，業餘撰稿人，致力於開源軟體及前沿科技的研究和探索。
評論(0)