【編者按】CDN的使用在Yahoo! Web性能規(guī)則上排第二條,面臨著地域性的網(wǎng)絡(luò)差異,CDN已成為提高網(wǎng)站性能的首選利器;不幸的是,雖然CDN已經(jīng)過多年發(fā)展,但是在國內(nèi)中小網(wǎng)站上仍然很少被使用,國內(nèi)開發(fā)者的CDN設(shè)計經(jīng)驗更是少之又少。近日,我們有幸邀請到國內(nèi)知名CDN服務(wù)提供商又拍云的聯(lián)合創(chuàng)始人兼運維總監(jiān)為我們深度分析這個技術(shù),以下為原文:
國內(nèi),隨著互聯(lián)網(wǎng)的高速發(fā)展,因為各大通信公司的政策,造成了南電信北聯(lián)通互通有局限性,再加上大小且質(zhì)量參差不齊的運營商,在這特殊的氛圍的互聯(lián)互通下號稱“八線合一”的機房開始嶄露頭角。互聯(lián)網(wǎng)的廣泛性使得網(wǎng)民分散在全國各地,由于全國地區(qū)的經(jīng)濟(jì)發(fā)展和互聯(lián)網(wǎng)建設(shè)的不平衡,實際網(wǎng)民的體驗往往受限于最后一公里的速度。在技術(shù)大噴井的年代,一些無聊或者有目的黑客攻擊也開始涌現(xiàn),無論是滲透還是DDoS攻擊都非常頻繁,時刻威脅著網(wǎng)站的安全……
上述種種問題,作為應(yīng)用服務(wù)提供商,我們要如何解決此類問題呢?歸根結(jié)底就是要充分利用好CDN(Content Delivery Network,即內(nèi)容分發(fā)網(wǎng)絡(luò))。
緩存代理類似內(nèi)容提供商源數(shù)據(jù)中心的一個透明鏡像,這些內(nèi)容可以在邊緣服務(wù)器中緩存和分發(fā),對于普通的網(wǎng)絡(luò)用戶來講,它通過智能DNS的篩選,用戶的請求被透明地指向離他最近的省內(nèi)骨干節(jié)點,最大限度的縮短用戶信息的傳輸距離。在任何時間、地點或者不同的運營商之間(尤其在中國),快速響應(yīng)用戶請求。
它是通過在網(wǎng)絡(luò)各處放置節(jié)點服務(wù)器,所以無需更改源站的網(wǎng)絡(luò)拓?fù)洌歉鶕?jù)智能路由和用戶就近原則匹配,從而確保了內(nèi)容快又穩(wěn)定的傳輸,大大提高了用戶訪問網(wǎng)站的響應(yīng)速度。
CDN服務(wù)初衷是確保快速可靠地分發(fā)靜態(tài)內(nèi)容,相對于動態(tài)內(nèi)容來說,由于動態(tài)內(nèi)容必須長連接來操持連接和通訊,只是用戶到服務(wù)商之間的鏈路和質(zhì)量都無法控制。因此為了提供快速的網(wǎng)絡(luò)體驗,有必要事先設(shè)置一些最佳路由。如省內(nèi)骨干網(wǎng),雙線機房,以改善用戶的網(wǎng)絡(luò)體驗。在中國典型的互聯(lián)互通問題上,網(wǎng)絡(luò)游戲加速就是一些最佳實踐。
利用好了CDN網(wǎng)絡(luò),無論面對是滲透還是DDoS攻擊,攻擊的目標(biāo)大都會被指向到了CDN,進(jìn)而保護(hù)了用戶源站。因為CDN是分布式的,所以即使遭受DDoS攻擊,也具備分散性,大大減少了源站收到毀滅打擊的可能性。在架構(gòu)的前期,還可以通過CDN做一些前置的安全保護(hù)工作,如攔截SQL注入、XSS跨站、網(wǎng)站掛馬、篡改等黑客攻擊。
CDN節(jié)點機房只需要在當(dāng)?shù)剡\營商的單線機房,或者帶寬相對便宜的城市,采購成本低。由于通過CDN減輕了源站壓力,節(jié)點越多,源站面對任何時間高峰時的帶寬峰值會被平均拉低。從而降低了后端服務(wù)器硬件規(guī)模和帶寬的采購成本。 由于源站服務(wù)器規(guī)模的減少,后期運維成本也大大減少,可謂是一舉多得。
由此可見,為了能夠滿足全國乃至世界各地和多線路運營商的不同用戶都有最好的體驗,構(gòu)建CDN的分布式服務(wù)其重要性不言而喻。但是,在面對如何根據(jù)自身場景去設(shè)計一個CDN架構(gòu),或者如何選擇以一個適合自己CDN服務(wù)提供商,這里面也有許多問題需要考量。
這里先簡單的介紹一下SSD介質(zhì)的一些考量。SSD作為采用電子存儲介質(zhì)進(jìn)行數(shù)據(jù)存儲和讀取的一種技術(shù),突破了傳統(tǒng)機械硬盤的性能瓶頸,固態(tài)硬盤的全集成電路化、無任何機械運動部件的革命性設(shè)計,擁有極高的讀取性能。
此環(huán)節(jié),基本上不需要與傳統(tǒng)的SATA、SAS作性能上的比較,SSD的勝出毫無懸念。而在整體方案中,只需要考慮承受的價格、容量大小(如120GB,160GB,300GB等規(guī)格)、是否能夠滿足設(shè)計需求這些問題。
作者建議:如果允許, 能使用SSD,就一定要考慮采用,用空間換性能,提升非常明顯。
這里給幾個SSD實戰(zhàn)的小貼士:
機械硬盤的連續(xù)讀寫性很好,但隨機讀寫性能很差。這是因為磁頭移動至正確的磁道上需要時間,隨機讀寫時,也就需要磁頭和探針頻繁的轉(zhuǎn)動,而機械結(jié)構(gòu)的磁頭和探針的位置調(diào)整是十分費時的,這就嚴(yán)重影響到硬盤的尋址速度,進(jìn)而影響到隨機寫入速度。
在存儲小文件(圖片)、OLTP數(shù)據(jù)庫應(yīng)用時,隨機讀寫性能(IOPS)是最重要指標(biāo)。由于固態(tài)硬盤沒有普通硬盤的機械結(jié)構(gòu),也不存在機械硬盤的尋道問題,因此系統(tǒng)能夠在低于1ms的時間內(nèi)對任意位置存儲單元完成輸入/輸出操作。
作者經(jīng)驗筆記:
大多數(shù)的存儲系統(tǒng)都是針對大文件而設(shè)計的,對小文件而言,大文件的存儲系統(tǒng)無法適應(yīng)小文件的存儲需求,它造成元數(shù)據(jù)管理、數(shù)據(jù)布局和I/O管理、Cache管理、網(wǎng)絡(luò)開銷等方面性能和存儲效率降低。
而且,文件系統(tǒng)的inode是線性存儲的,因此,我們遍歷一個目錄下的文件,需要讀取的磁盤的位置是來回跳躍的。不連續(xù)的讀取意味著磁盤要不斷的進(jìn)行尋道,那么性能自然可想而知。
作者經(jīng)驗筆記:
隨著時間的推移,硬件升級已經(jīng)突破了摩爾定律,在硬件不斷升級帶來的紅利下,我們從最初的雙核到四核、六核、八核心&超線程,從2G、4G內(nèi)存到 8G、16G甚至128G內(nèi)存的情況下,同樣的價格所帶來的硬件升級,性能提升也是非常可觀的,因此,設(shè)置合適的硬件淘汰時間點也很重要,當(dāng)老舊服務(wù)器超過3~5年的服役期,務(wù)必考慮做新陳代謝式的升級,充分利用好硬件潛力,保證架構(gòu)設(shè)計平滑有序穩(wěn)定的升級。
反觀軟件設(shè)計,相對硬件升級,可談的話題就比較多了,舉個反例:比如說 Squid軟件的缺點(當(dāng)然,誕生于1996年的Squid與Apache同樣的古老,昔日的時代也是立下了汗馬功勞,但時代進(jìn)步就不能固步自封必須考慮革新):
更多詳情參考:
Varnish Cache 的架構(gòu)筆記,為什么一些古老的軟件正在被新的設(shè)計思想所淘汰,如Nginx替代Apache,ATS替代Squid,Postfix替代Sendmail等等。
建議:
……這里就不展開詳述了,以后有機會再介紹。
開源世界里能夠擔(dān)當(dāng)反向代理及緩存的軟件不少,而且各有優(yōu)劣。在這里,我就不一一介紹每個軟件的介紹了,大家可以自行參考相關(guān)鏈接了解。
CDN架構(gòu)上要充分體現(xiàn)出抗攻擊能力和靈活應(yīng)變的原則。因此,我們將CDN節(jié)點分解成反向代理+緩存加速+攻擊防御這三個不同層次的功能結(jié)構(gòu)。
作為一個架構(gòu)師,就必須要考慮如何選型,我們從性能、功能、配置上來進(jìn)行比較篩選。
軟件名稱 | 性能 | 功能 | 過濾規(guī)則配置 |
Squid | 不能多核是硬傷; 磁盤緩存容量有優(yōu)勢; 性能中等 | 多; 支持ACL角色控制; 支持ICP緩存協(xié)議 | 支持外部文件讀取及熱加載; 支持熱啟動 |
Varnish | 多核支持; 內(nèi)存緩存; 性能強 | 夠用; 支持集群,但不支持ICP集群; 支持后端存活檢查 | 不支持外部文件讀取; 需要轉(zhuǎn)義; 支持熱啟動 |
Nginx | 多核支持; 支持代理插件; 性能較強 | 多; 支持集群,但不支持ICP集群; 支持后端存活檢查; 通過插件可以充當(dāng)多角色服務(wù)器 | 不支持外部文件讀取; 需要轉(zhuǎn)義; 支持熱啟動 |
Apache TS | 多核支持; 磁盤/內(nèi)存緩存; 性能強 | 夠用; 支持后端存活檢查; 支持ICP協(xié)議,Cluster不穩(wěn)定; 支持插件開發(fā); | 支持外部規(guī)則文件讀取及熱加載; 支持熱啟動 |
HAProxy | 多核支持; 無緩存; 支持HTTP頭部解析; 性能強 | 少,只專注HTTP頭部解析和轉(zhuǎn)發(fā)功能; 支持ACL角色控制; 支持后端存活檢查 | 支持外部規(guī)則文件讀取及熱加載; 支持熱啟動; 支持會話粘滯和長連接 |
現(xiàn)在,我們對這三層功能結(jié)構(gòu)充分了解,在測試調(diào)優(yōu)及生產(chǎn)線的實踐檢驗中,我們發(fā)現(xiàn):
LVS是個重量級、高效穩(wěn)定的四層轉(zhuǎn)發(fā),雖然不能作七層HTTP協(xié)議的識別,但完全可以架設(shè)在七層之前,與上述的各種軟件搭配使用。
所以,LVS的使用并不會影響網(wǎng)絡(luò)結(jié)構(gòu),后續(xù)仍然可以想上就上,前提是要兼顧到LVS的單點故障,這個我們可以通過Keepalived/Heartbeat來實現(xiàn)可用性和可靠性的保證。
作者簡介:
邵海楊,UPYUN(又拍云)聯(lián)合創(chuàng)始人兼運維總監(jiān),來自杭州Linux用戶組,新浪微博@海洋之心-悟空 ,資深系統(tǒng)運維架構(gòu)師,業(yè)余撰稿人,致力于開源軟件及前沿科技的研究和探索。