發表於 20小時前|
csdn|
邵海楊雲計算
cdn架構開源
摘要：如何以近實時的方式交付內容一直廣受網際網路公司關注，而cdn也毫無疑問的成為了許多雲服務提供商的淘金熱點。近日，我們通過又拍雲邵海楊對cdn進行了一次深度接觸，其中包括作用、架構、可選用開源技術等多個方面。
【編者按】cdn的使用在yahoo! web效能規則上排第二條，面臨著地域性的網路差異，cdn已成為提高**效能的首選利器；不幸的是，雖然cdn已經過多年發展，但是在國內中小**上仍然很少被使用，國內開發者的cdn設計經驗更是少之又少。近日，我們有幸邀請到國內知名cdn服務提供商又拍雲的聯合創始人兼運維總監為我們深度分析這個技術，以下為原文：
國內，隨著網際網路的高速發展，因為各大通訊公司的政策，造成了南電信北聯通互通有侷限性，再加上大小且質量參差不齊的運營商，在這特殊的氛圍的互聯互通下號稱「八線合一」的機房開始嶄露頭角。網際網路的廣泛性使得網民分散在全國各地，由於全國地區的經濟發展和網際網路建設的不平衡，實際網民的體驗往往受限於最後一公里的速度。在技術大噴井的年代，一些無聊或者有目的黑客攻擊也開始湧現，無論是滲透還是ddos攻擊都非常頻繁，時刻威脅著**的安全……
上述種種問題，作為應用服務提供商，我們要如何解決此類問題呢？歸根結底就是要充分利用好cdn（content delivery network，即內容分發網路）。
快取**類似內容提供商源資料中心的乙個透明映象，這些內容可以在邊緣伺服器中快取和分發，對於普通的網路使用者來講，它通過智慧型dns的篩選，使用者的請求被透明地指向離他最近的省內骨幹節點，最大限度的縮短使用者資訊的傳輸距離。在任何時間、地點或者不同的運營商之間（尤其在中國），快速響應使用者請求。
它是通過在網路各處放置節點伺服器，所以無需更改源站的網路拓撲，而是根據智慧型路由和使用者就近原則匹配，從而確保了內容快又穩定的傳輸，大大提高了使用者訪問**的響應速度。
cdn服務初衷是確保快速可靠地分發靜態內容，相對於動態內容來說，由於動態內容必須長連線來操持連線和通訊，只是使用者到服務商之間的鏈路和質量都無法控制。因此為了提供快速的網路體驗，有必要事先設定一些最佳路由。如省內骨幹網，雙線機房，以改善使用者的網路體驗。在中國典型的互聯互通問題上，網路遊戲加速就是一些最佳實踐。
利用好了cdn網路，無論面對是滲透還是ddos攻擊，攻擊的目標大都會被指向到了cdn，進而保護了使用者源站。因為cdn是分布式的，所以即使遭受ddos攻擊，也具備分散性，大大減少了源站收到毀滅打擊的可能性。在架構的前期，還可以通過cdn做一些前置的安全保護工作，如攔截sql注入、xss跨站、**掛馬、篡改等黑客攻擊。
cdn節點機房只需要在當地運營商的單線機房，或者頻寬相對便宜的城市，採購成本低。由於通過cdn減輕了源站壓力，節點越多，源站面對任何時間高峰時的頻寬峰值會被平均拉低。從而降低了後端伺服器硬體規模和頻寬的採購成本。 由於源站伺服器規模的減少，後期運維成本也大大減少，可謂是一舉多得。
由此可見，為了能夠滿足全國乃至世界各地和多線路運營商的不同使用者都有最好的體驗，構建cdn的分布式服務其重要性不言而喻。但是，在面對如何根據自身場景去設計乙個cdn架構，或者如何選擇以乙個適合自己cdn服務提供商，這裡面也有許多問題需要考量。
這裡先簡單的介紹一下ssd介質的一些考量。ssd作為採用電子儲存介質進行資料儲存和讀取的一種技術，突破了傳統機械硬碟的效能瓶頸，固態硬碟的全積體電路化、無任何機械運動部件的革命性設計，擁有極高的讀取效能。
此環節，基本上不需要與傳統的sata、sas作效能上的比較，ssd的勝出毫無懸念。而在整體方案中，只需要考慮承受的**、容量大小（如120gb，160gb，300gb等規格）、是否能夠滿足設計需求這些問題。
作者建議：如果允許， 能使用ssd，就一定要考慮採用，用空間換效能，提公升非常明顯。
這裡給幾個ssd實戰的小貼士：
機械硬碟的連續讀寫性很好，但隨機讀寫效能很差。這是因為磁頭移動至正確的磁軌上需要時間，隨機讀寫時，也就需要磁頭和探針頻繁的轉動，而機械結構的磁頭和探針的位置調整是十分費時的，這就嚴重影響到硬碟的定址速度，進而影響到隨機寫入速度。
在儲存小檔案（）、oltp資料庫應用時，隨機讀寫效能（iops）是最重要指標。由於固態硬碟沒有普通硬碟的機械結構，也不存在機械硬碟的尋道問題，因此系統能夠在低於1ms的時間內對任意位置儲存單元完成輸入/輸出操作。
作者經驗筆記：
bios裡務必開啟ahci模式（能支援sata熱插拔和ncq定址方式，提速→300%，當然核心也要支援ahci模式）
ssd的主控晶元相當於大腦中樞，非常重要，建議用intel、samsung、marvell等知名品牌
ssd更適合應用在隨機讀寫場景，因此需要認真思考什麼場合應用
大多數的儲存系統都是針對大檔案而設計的，對小檔案而言，大檔案的儲存系統無法適應小檔案的儲存需求，它造成元資料管理、資料布局和i/o管理、cache管理、網路開銷等方面效能和儲存效率降低。
而且，檔案系統的inode是線性儲存的，因此，我們遍歷乙個目錄下的檔案，需要讀取的磁碟的位置是來回跳躍的。不連續的讀取意味著磁碟要不斷的進行尋道，那麼效能自然可想而知。
作者經驗筆記：
無論大小檔案，首選ext4檔案系統，reiserfs/btrfs不要輕易嘗試（雖然b-tree設計先進）
ext4針對小檔案有所改進，使用了inode預分配，這使得inode具有很好的區域性性特徵，同一目錄檔案inode盡量放在一起，加速了目錄定址與操作效能。
ext4針對大檔案使用了extent/delay/multi的資料塊分配策略。這些策略使得大檔案的資料塊保持連續儲存在磁碟上，資料定址次數大大減少，顯著提高i/o吞吐量。
xfs在大檔案方面，表現得不錯，可以使用。
ssd盡量應用在隨機小檔案讀寫的應用場景，畢竟容量寶貴，在有限的空間儲存更多的檔案是個明智之選。
有開發實力的可以選用基於leveldb或其它的kv儲存作底層檔案系統，此為後話。
隨著時間的推移，硬體公升級已經突破了摩爾定律，在硬體不斷公升級帶來的紅利下，我們從最初的雙核到四核、六核、八核心&超執行緒，從2g、4g記憶體到 8g、16g甚至128g記憶體的情況下，同樣的**所帶來的硬體公升級，效能提公升也是非常可觀的，因此，設定合適的硬體淘汰時間點也很重要，當老舊伺服器超過3～5年的服役期，務必考慮做新陳代謝式的公升級，充分利用好硬體潛力，保證架構設計平滑有序穩定的公升級。
反觀軟體設計，相對硬體公升級，可談的話題就比較多了，舉個反例：比如說 squid軟體的缺點（當然，誕生於2023年的squid與apache同樣的古老，昔日的時代也是立下了汗馬功勞，但時代進步就不能固步自封必須考慮革新）：
無法利用多核優勢，造成單核cpu壓力太高；
雞肋的dns程序必須要執行；
無法利用大記憶體做快取加速；
coss設計上的先天缺陷，初始化甚至重啟後重建索引慢；
偶然機器重啟，修復的效率非常漫長，慢到讓人崩潰；
varnish cache 的架構筆記，為什麼一些古老的軟體正在被新的設計思想所淘汰，如nginx替代apache，ats替代squid，postfix替代sendmail等等。
建議：
負載均衡技術應用得當，如haproxy、lvs。一方面可以互援互備，另一方面也可以方便輪流公升級；
要嘗試新的軟體開發思路和網路模型，如epoll、aio、記憶體加速，連線復用和事件驅動機制；
系統服務精簡**；
檔案系統效能調優；
提高磁碟io效能；
優化網路效能；
優化路由策略；
資料庫的優化；
……這裡就不展開詳述了，以後有機會再介紹。
cdn架構上要充分體現出抗攻擊能力和靈活應變的原則。因此，我們將cdn節點分解成反向**+快取加速+攻擊防禦這三個不同層次的功能結構。
作為乙個架構師，就必須要考慮如何選型，我們從效能、功能、配置上來進行比較篩選。
軟體名稱
效能功能
過濾規則配置
squid
不能多核是硬傷；
磁碟快取容量有優勢；
效能中等
多；支援acl角色控制；
支援icp快取協議
支援外部檔案讀取及熱載入；
支援熱啟動
varnish
多核支援；
記憶體快取；
效能強夠用；
支援集群，但不支援icp集群；
支援後端存活檢查
不支援外部檔案讀取；
需要轉義；
支援熱啟動
nginx
多核支援；
支援**外掛程式；
效能較強
多；支援集群，但不支援icp集群；
支援後端存活檢查；
通過外掛程式可以充當多角色伺服器
不支援外部檔案讀取；
需要轉義；
支援熱啟動
apache ts
多核支援；
磁碟/記憶體快取；
效能強夠用；
支援後端存活檢查；
支援icp協議，cluster不穩定；
支援外掛程式開發；
支援外部規則檔案讀取及熱載入；
支援熱啟動
haproxy
多核支援；
無快取；
支援http頭部解析；
效能強少，只專注http頭部解析和**功能；
支援acl角色控制；
支援後端存活檢查
支援外部規則檔案讀取及熱載入；
支援熱啟動；
支援會話粘滯和長連線
現在，我們對這三層功能結構充分了解，在測試調優及生產線的實踐檢驗中，我們發現：
lvs是個重量級、高效穩定的四層**，雖然不能作七層http協議的識別，但完全可以架設在七層之前，與上述的各種軟體搭配使用。
所以，lvs的使用並不會影響網路結構，後續仍然可以想上就上，前提是要兼顧到lvs的單點故障，這個我們可以通過keepalived/heartbeat來實現可用性和可靠性的保證。
作者簡介：
服務好「最後一公里」，高效CDN架構經驗
國內，隨著網際網路的高速發展，因為各大通訊公司的政策，造成了南電信北聯通互通有侷限性，再加上大小且質量參差不齊的運營商，在這特殊的氛圍的互聯互通下號稱 八線合一 的機房開始嶄露頭角。網際網路的廣泛性使得網民分散在全國各地，由於全國地區的經濟發展和網際網路建設的不平衡，實際網民的體驗往往受限於最後一公...
關於最後一公里
最後一公里 last kilometer 在英美也常被稱為last mile 最後一英里 最後一公里 原意指完成長途跋涉的最後一段里程，被引申為完成一件事情的時候最後的而且是關鍵性的步驟 通常還說明此步驟充滿困難 通訊行業經常使用 最後一公里 來指代從通訊服務提供商的機房交換機到使用者計算機等終端裝...
Scrum最後一公里
研發部門試點敏捷，前面的過程基本都比較正常，使用者故事，計畫會議 短迭代 站立會議 回顧會 功能驗收，基本都能正常完成，但是把產品發布出去，給生產部門使用後，總是得不到及時的反饋，總是等到系統正是開始使用後，才發現這樣問題 那樣不好用 之前推動生產部門的下的作業人員，希望他們能積極配合 及時反饋看看...