之前在設計自建cdn的內部結構時寫的一些文字，簡單貼下。
內部節點方案。大部分公司的做法都是lvs+keepalived
幾個廠商的不同作法：
1.pptv keepalived+nginx+squid+ts 節點靈活性比較高，小節點多機房，30左右節點數量，70臺左右的機器
2.迅雷 lvs+keepalived+ts+squid lvs是公用的，其他業務也會用到（機房業務比較多）
3.京東 lvs+keepalived+haproxy+squid 大幾點，20幾個機房，500臺左右的機器
4.新浪 lvs+keepalived+nginx+ts. 40左右節點，都算大節點。每節點數量在30臺左右，利用率80%
5.淘寶 lvs+keepalived+haproxy+ts 大節點，多服務，ssd。。。流量超大。
準備採用的Cdn整體結構及內部結構：
1）gslb，全局負載均衡使用三方智能dns解析，控制用戶到cdn節點的調度（cloudxns，支持到城市的調度，收費1999/(域名/年)）
2）lslb（本地負載均衡）：
方案1：
4層使用lvs+keepalived，7層使用nginx，這樣就可以保證4層到7層的高可用性和擴展性，單節點最少需要5個公網IP，4臺機器
方案2：
4層使用keepalived, 7層使用nginx，單節點最少需要4個公網IP，2臺機器，對比方案1的缺點是不能支持4層-----7層的檢測（即，機器掛掉可以實現auto failover，nginx掛掉不能）
Cache系統使用apache traffic server(對比squid，響應更快，性能更強)。
3）cdn節點到源站回源使用bind+lvs（每個bind集羣至少需要4臺機器，現節點對回源dns的ha要求不高，可以暫時不考慮ha），構建回源dns的高可用。
4）源站構建在雙線核心機房，用來保證網通和電信各自的回源質量（目前條件不允許）
5）也可以在cdn節點和源站直接構建2cache（測試階段可以電信，網通各一個），來緩解源站的壓力(這個也是需要的，之前在pptv出現過邊緣回源壓垮源站的問題，如果能夠在2cache有效緩存，就可以避免這種情況)
提供下方案1的Lvs+keepalived的結構圖：
幾點說明：
1.js,jpg,swf,gif等緩存時間比較長的，object size比較大的文件類型通過ats緩存，使用ats的raw來優化io。
2.html，xml的文件緩存時間比較短，使用squid做緩存，squid只使用內存做緩存。
附ats的一些性能指標：
1.ats vs squid 性能對比
今天review了下ts的性能表現，由於使用了多線程異步處理模型和分離的各個模塊子系統，ts的性能要優於squid很多。從響應時間上來看，相同的請求數量下，ts減少了3倍（由0.04s減少至0.01s），而且響應時間趨於平穩。
下面爲具體的數據（只取upstream add含有127.0.0.1:8080的訪問記錄，即proxy到ts的訪問記錄。sql不再列舉）
取切換前後webcdn機器訪問數據，環比12.20,12.06,12.13的數據來看。
1）.訪問量
12.6號的訪問量和12.20號的訪問量趨勢相當
2.）平均響應時間：
更換成ts後，響應時間明顯降低，由12.6號的。0.04s左右降低至0.01s，而且整體趨勢比較平穩，在流量高峯時響應時間也未見大幅增加。而更換ts之前的數據顯示，在12點-13點，18點-20點的流量高峯時，響應時間都較正常時段有所增加。
12.20號數據環比一天情況
整體的響應時間，13點左右，squid轉成ts，平均響應時間降低至0.01s左右。
zabbix監控圖：
相同訪問量的情況下，squid和ats響應時間對比（都未到達瓶頸），ts很平穩。比squid也低不少
rt,,urt:
（可以看到nginx的request_time也有兩個高峯，相反ts倒是很平穩）
nginx-proxy交互使用的時間：
（有兩個明顯的高峯，後端squid的響應沒有這麼明顯的變化，應該是nginx--squid的交互問題，比如長連接的支持，連接的複用）
切換前後響應時間對比圖：
2. ats raw vs ext3 io性能對比
相同流量下Tps,rtps,wtps的結果
Tps的比例是ram:ext3=1:2.45,從趨勢圖上也可看出，使用raw時，io是比較穩定和集中的，而使用ext3文件系統時，由於會有buffer flush的行爲，Io會每隔一段時間出現高峯值，不會穩定。
raw:
平均tps:98.59
平均wtps:50.32
平均rtps:48.27
ext3:
平均tps:241.99
平均rtps:144.61
平均wtps:97.38
響應時間對比
從ts的upstream的時間來看，ts在raw 和ext3兩種情況下，響應時間變化不大，也比較平穩。
nginx request time在高峯期時變化比較明顯
Avg-upstream_time avg_request_time (type):
0.0024 0.0090 (ext3)
0.0026 0.0093 (raw)
目前結論：Ts 使用raw的情景下，會有效的減低io的操作數，減少io的消耗，比例是ram:ext3=1:2.45,ts的響應速度上基本沒有變化。按現在的cdn節點壓力來看，io還沒有到達性能的瓶頸，所以可以暫不考慮raw的方案，如果以後機器的壓力上去了，io成爲瓶頸的話，可以將ext3換成raw