下面，我們將介紹自建CDN的具體建設規劃，主要從以下幾個方面進行考量：硬體成本、頻寬成本、架構設計、實際部署。

硬體成本

在硬體上，我們選型的需求是在1U的基礎上具有強勁的效能，同時價效比要高。

我們選擇了（強氧）雙子星伺服器，其硬體規格為：1U機身+支援雙路至強CPU+最大支援48G記憶體+雙千兆網口x2+H3C S1208八口千兆，提供三年質保服務，總價約1.5萬。

頻寬成本

單線機房的機房和頻寬資源，由於不需要經過第三方拉線撮合，直接從運營代理商購買，因此選擇餘地大，價效比高。以租用電信、聯通單線資源為例，每條線獨享100M頻寬，提供8個IP，有些機房自帶硬防，能夠防禦5G-10G流量。

平均費用，每個節點頻寬成本基本在1.6~2.5萬/年。

架構設計

CDN架構上要充分體現出抗攻擊能力和靈活應變的原則。因此，我們將CDN節點分解成反向代理+快取加速+攻擊防禦這三個不同層次的功能結構。

• 反向代理功能（作用：路由加速，隱藏主節點，負載均衡）
• 快取加速功能（作用：靜態推送，節省後端主節點頻寬）
• 攻擊防禦功能（作用：快速解析，匹配過濾惡意攻擊）

開源世界裡能夠擔當反向代理及快取的軟體不少，而且各有優劣。作為架構師，要考慮如何選型，我們從效能、功能、配置上來進行比較篩選。

我們對這三層功能結構分別進行了測試調優及生產線的實踐檢驗，從以下方面評估：

• HTTP防禦性能：HAProxy在應對大流量CC攻擊時，做正則匹配及頭部過濾時，CPU消耗只佔10%~20%。其它軟體均狂佔CPU資源約90%以上，容易成瓶頸導致整個系統無響應。
• 反向代理效能：單純轉發效率以記憶體快取型的Varnish效能最強，ATS和Nginx次之，考慮大容量快取因素，ATS也是個不錯的選擇，但文件缺乏，需要持續關注。Nginx是專門針對C10K的產物，效能不錯，配合眾多外掛，改造性很強。
• 過濾規則的可配置性：HAProxy，ATS，Squid均支援規則檔案讀取、ACL定製和熱載入、熱啟動。Nginx則不支援外部檔案正則匹配，略差一點，但可塑性強。

因此，綜合上述考慮，最終我們採用的架構是HAProxy+Varnish/ATS/Nginx的組合，即防禦型反向代理快取方案，功能角色如下：

• 前面由HAProxy全力負責動靜資源分離，實現會話粘滯，節點負載均衡，故障轉移，遇到危急時承擔基於Http協議的CC型別攻擊防禦。
• 後面為可插拔替換的反向代理快取引擎：根據生產線上的實際應用場景及快取物件的容量來決定使用記憶體型的varnish或者是磁碟型的ats，如果需要定製功能很強（防盜鏈）的反向代理如Nginx+plugins。

這個組合最大的特點是：

• 支援外部過濾規則的讀取，尤其是關鍵字串無需轉義，可直接追加到檔案中。
• 支援配置檔案熱載入生效，都支援reload，服務平滑生效。
• 可插拔式的快取元件靈活應對各種業務需求。
• 部署簡單，節點失效/生效切換方便。

LVS缺席：為什麼這裡沒有提及LVS，因為LVS是個重量級、高效穩定的四層轉發，不能作七層HTTP協議的識別，但完全可以架設在七層之前。所以，LVS的使用並不會影響網路結構，後續仍然可以想上就上，只是前提要兼顧到LVS的單點故障。

實際部署

最終我們在主節點周圍一共部署了8個CDN節點（節點數量根據自身公司實力及實際生產環境要求而靈活調整，此數字僅作參考），這些節點又按照地域劃分成了四個大區：北方（以山東，河北為主）、西南（以四川為主）、華東（以寧波，嘉興為主） 華南（以福建，湖南為主 ）兼顧全國各個省份。

總體成本情況

8個單線加速節點，每個節點100Mx8，8臺雙子星伺服器，總共投資約30W（後續費用只考慮頻寬支出，約15W/年），我們應急撥款為10W，每個月CDN預算為2W。

專案進度安排：

1～4個月抓進度：特點是快速部點。這裡有個訣竅，前期可以先跟IDC按月或者季度簽約，然後通過監控看連續的節點質量，如果節點質量不佳，更換提供商，這樣損失不會太大，如果節點質量好，就半年付或者年付，這樣就可以保證質量和價效比最高；

5～8個月為完善期：根據預算，有節奏的加點，加頻寬，保證頻寬的冗餘度；

8個月以後為穩定期：根據實際情況保證節點的最大可用性，同時也提升了整體防禦能力。

如何做防護策略

開啟HAProxy的httplog功能，記錄日誌。

HAProxy的配置策略：

global
    nbproc 24
    pidfile /var/run/haproxy.pid
    daemon
    quiet
    user nobody
    group nobody
    chroot /opt/haproxy
    spread-checks 2

defaults
    log 127.0.0.1   local5
    mode    http
    option  forwardfor
    option  httplog
    option  dontlognull
    option  nolinger # reduce FIN_WAIT1
    option  redispatch
    retries 3
    option  http-pretend-keepalive
    option  http-server-close
    option  accept-invalid-http-request
    timeout client 15s
    timeout connect 15s
    timeout server 15s
    timeout http-keep-alive 15s
    timeout http-request 15s

    stats enable
    stats uri /stats
    stats realm 53KF\ Proxy\ Status
    stats refresh 60s
    stats auth admin:adminxxx

listen Web_FB 0.0.0.0:80
    option httpchk GET /alive.php HTTP/1.0

    acl invalid_referer hdr_sub(referer) -i -f /opt/haproxy/etc/bad_ref.conf
    acl invalid_url url_sub -i -f /opt/haproxy/etc/bad_url.conf
    acl invalid_methods method -i -f /opt/haproxy/etc/bad_method.conf
    block if invalid_referer || invalid_url || invalid_methods

    acl dyn_host hdr(host) -i -f /opt/haproxy/etc/notcache_host.conf
    acl static_req path_end -i -f /opt/haproxy/etc/allow_cache_file.conf
    use_backend img_srv if static_req !dyn_host

# acl shaohy
    acl geek hdr_dom(host) -i 17geek.com
    use_backend geek if geek

# backend shaohy
backend geek
    mode http
    balance source
    cookie SESSION_COOKIE insert indirect nocache
    option tcpka
    server geek_1 127.0.0.1:81 cookie geek_1 maxconn 10000 weight 8

backend img_srv
    mode http
    option tcpka
    server img_srv 127.0.0.1:88 maxconn 30000 weight 8

Varnish的配置策略：

backend h_17geek_com_1 {        
    .host="127.0.0.1";      
    .port="81";         
    .connect_timeout=300s;      
    .first_byte_timeout=300s;   
    .between_bytes_timeout=300s;    
 }                  

director geek srv {         
    { .backend=h_17geek_com_1; .weight=3;}
 }                  

sub vcl_recv {
    if (req.http.host~"^(www).?17geek.com$"){
        set req.backend=geek_srv;       
        if (req.request != "GET" && req.request != "HEAD") {
            return (pipe);              
        }                       
        if(req.url ~ "\.(php|jsp)($|\?)") {         
            return (pass);              
        }                       
        else {                      
            return (lookup);            
        }                   
    }                       
 }

對於CC型別的DDoS攻擊，通過第一篇當中介紹的監控異常流量的方法依然適用，而且優勢更明顯，因為：

• 節點各自承擔相應的日誌記錄，分析日誌的系統開銷，發現異常請求後直接在haproxy前端做ACL規則 過濾，因此，攻擊壓力不會傳遞給後端伺服器，保證後端安全。
• 節點受到的攻擊流量過大，機房可以拉黑IP或者引流，後端智慧DNS會自動把這個節點剔除，後續請求不要通過此節點。

在本系列的下一篇文章中，我們會介紹這個CDN架構的一些後續改進工作，包括智慧DNS、大規模日誌分析、利用OpenCDN改善後臺管理等。

作者簡介

邵海楊（個人頁面），來自杭州Linux使用者組。網名“海洋之心”，系統架構師，業餘撰稿人，致力於開源軟體及前沿科技的研究和探索。

張磊（微博，部落格），來自杭州谷歌開發者社群。專注於資訊保安技術領域，曾主導多項銀行/證券行業網站安全測試和入侵取證分析專案，為四大銀行提供安全防護技術支援。目前創業做網際網路安全防護。  

相關閱讀