雲時代服務器端工程師必備 CDN 技能包

直播很久沒有曝光量了,自薦一波《PHP進階之路》(PHPer們,很久沒有投資本身了呢?)
本文原文地址:https://mengkang.net/641.html
原創一篇博客不容易,請勿隨意轉載css

雲時代,爲了提高靜態資源的加載速度,大夥都是拼了。這促使近些年國內 CDN 的使用逐步普及。而做爲一家以圖片分享社區爲核心業務的公司,圖片 CDN 的使用比較多,下面梳理下本身的一些經驗。閉門造車,若有勘誤,你們多多包涵。html

主要包括瞭如下內容:前端

  1. CDN使用背景,圖片的分佈式存儲
  2. CDN 網絡原理概述
  3. 批量添加、切換 CDN 的步驟和注意事項
  4. 多 CDN 切換的步驟和注意事項
  5. CDN 訪問故障分析

CDN使用背景,圖片的分佈式存儲

由於下文中的CDN的使用都是基於咱們當前的圖片存儲,爲了下文介紹不是那麼突兀描述下當前圖片存儲的結構圖:
1478785170477282.jpgnginx

CDN 網絡原理概述

簡單畫了一張圖予以說明:
1478785430303547.png數據庫

實際咱們在第五步,回源的時候,咱們會要求 CDN 服務商,不能全部節點直接回源到咱們源站,協商要求他們使用統一代理回源咱們源站,也就是說同一個資源只許他們回源一次。以後,其餘邊緣節點沒有緩存,請求他們自身的代理。segmentfault

也就是說他們的 CDN 是有多級緩存的。瀏覽器

批量添加 CDN 的步驟和注意事項

業務需求:如今須要將某個域名(a.mengkang.net)下的圖片訪問的流量切換到 CDN 上。緩存

操做步驟:服務器

先對原域名下訪問日誌作統計,統計出訪問頻次較高的圖片地址(好比20萬個地址),把這些地址交給cdn服務商。網絡

  1. 讓他們先去預熱抓取這20萬個地址的資源。
  2. 預熱完畢後,咱們再把(a.mengkang.net)的一部分域名換爲(b.mengkang.net)。而後把b.mengkang.net作cname解析到cdn服務器給定的域名地址上去(好比b.mengkang.ccgslb.com.cn)。
  3. 經過wget測試是訪問域名b.mengkang.net下的圖片是否可以被cdn緩存住。
  4. cache測試沒有問題以後,我再把a.mengkang.net下的部分流量切到b.mengkang.net上去,同事運維的同事監控流量回源的狀況,根據回源狀況再對分配流量的大小作調整。

多 CDN 切換的步驟和注意事項

需求

把網宿 maa 的 cdn 切 400M 到藍訊 mplus 上。

切換原理

最初,咱們配置了n (好比 n=100)個二級域名,而後把這 n 個域名中的一半解析到網宿,另外一半解析到藍訊。好比:

  1. a001.zhoumengkang.com 解析到了藍訊,回源的地址爲y.a001.zhoumengkang.com;
  2. a001.mengkang.net 解析到了藍訊,回源的地址爲y.a001.mengkang.net;
  3. 圖片資源是分佈式存儲存儲在各個主機上,要確保上面兩個回源域名指向的服務以及服務器路徑是同樣的。這樣,這兩個域名就能夠相互切換了,可是切換的時候須要觀察回源的壓力。

這裏說的「切」是從咱們自身的業務代碼動刀,而不是切換和 cdn 的域名解析合做。圖片資源在數據庫有全局惟一的uuid,而後根據該uuid生成url,只須要在這裏控制url的域名輸出便可。

執行步驟

  1. 查看網宿 maa 下各個域名的流量請求帶寬。
  2. 查看網宿 maa 和藍訊 mplus 回源地址相同的對應域名。
  3. 統計該域名下的熱點資源地址,而後到即將切換的 cdn 服務商作預加載,不然客戶端加載時,即便回源帶寬不至於打滿,可是會出現請求時間過長,圖片沒法顯示的狀況。
  4. 修改業務代碼,減掉網宿 maa 的圖片地址的輸出,替換爲藍訊 mplus 的域名。逐步替換,單域名下流量過大,還須要慢慢降權重轉移,而不是一次性,以防回源壓力過大,致使源站沒法承受。
  5. 監控兩邊 cdn 帶寬,新 cdn 的緩存命中率,源站帶寬和服務器負載、I/O以及前端圖片服務器負載均衡服務器總帶寬(由於和錢直接相關,必須關注)。

注意事項

  1. 關注源站的負載和 I/O

    # top
    top - 16:25:34 up 273 days,  8:54,  1 user,  load average: 5.54, 5.34, 5.19
    Tasks: 209 total,   1 running, 208 sleeping,   0 stopped,   0 zombie
    Cpu(s):  0.2%us,  0.4%sy,  0.0%ni, 47.9%id, 51.0%wa,  0.0%hi,  0.5%si,  0.0%st
    Mem:  32945488k total, 32851176k used,    94312k free,  7033172k buffers
    Swap: 12485164k total,      204k used, 12484960k free, 22568232k cached
  2. cdn 切換以後,除了觀察新 cdn 的流量,還須要監控新 cdn 的緩存命中率,能夠經過後期的回源比例來監控,也能夠經過循環腳本執行wget來監測。

    $ wget -S -O /dev/null f1.topitme.com/1/40/33/1110152459d0433401m.jpg
    --2015-12-29 11:11:01--  http://f1.topitme.com/1/40/33/1110152459d0433401m.jpg
    Resolving f1.topitme.com... 220.181.64.145
    Connecting to f1.topitme.com|220.181.64.145|:80... connected.
    HTTP request sent, awaiting response... 
      HTTP/1.1 200 OK
      Content-Type: image/jpeg
      Content-Length: 33061
      Accept-Ranges: bytes
      Server: nginx
      Date: Mon, 30 Nov 2015 07:47:09 GMT
      Last-Modified: Mon, 08 Sep 2014 05:00:59 GMT
      Expires: Thu, 27 Nov 2025 07:47:09 GMT
      Cache-Control: max-age=315360000
      Powered-By-ChinaCache: HIT from 010519g3H8.6
      Age: 2489032
      Powered-By-ChinaCache: HIT from 01001023P2.2
      Switch:FSCS
    Length: 33061 (32K) [image/jpeg]
    Saving to: '/dev/null'
     
    /dev/null           100%[=====================>]  32.29K  --.-KB/s   in 0.09s  
     
    2015-12-29 11:11:02 (372 KB/s) - '/dev/null' saved [33061/33061]

    這裏出現了Powered-By-ChinaCache爲HIT說明命中了,若是是MISS則沒有命中,該規則須要諮詢 cdn 運營商。

後記

根據每一個產品的屬性,每日流量確定都有高峯和低谷期,我以前設置的天然回源,雖然在流量高峯期,設置的比例很小,可是基數很大,因此切過去的量比較大,應該選擇在流量比較少的時間,執行預加載,這樣保證了帶寬的使用率。

CND資源訪問故障的定位

案例一:圖片大面積沒法加載

現象:同一圖片地址,時而能打開,時而沒法訪問。沒法訪問時,單獨訪問圖片地址發現還跳轉到了一個遊戲網站主頁。

聯繫 CDN 客服,獲得的反饋是運營商 DNS 劫持,他們的服務沒問題。(很是的消極怠工)

拿下面這張圖片做爲例子 http://f4.topit.me/4/2d/d1/11...

首先咱們肯定咱們源站資源是可訪問的,在 CDN 回源上不存在問題。

咱們經過wget命令綁定域名host,假如源站ip爲111.1.23.214,這樣則會繞過 CDN,直接訪問咱們源站了。

wget -S -0 /dev/null --header="Host: f4:topit.me" http://111.1.23.214/4/2d/d1/1133196716aead12d4s.jpg

確認圖片是能正常訪問的。

而後經過wget -S打印詳細的 http 頭信息

wget -S  http://f4.topit.me/4/2d/d1/1133196716aead12d4s.jpg

請求結果以下

# wget -S  http://f4.topit.me/4/2d/d1/1133196716aead12d4s.jpg
--2014-11-08 21:47:34--  http://f4.topit.me/4/2d/d1/1133196716aead12d4s.jpg
Resolving f4.topit.me... 123.150.50.14, 123.150.50.13
Connecting to f4.topit.me|123.150.50.14|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 302 Moved Temporarily
  Server: nginx/1.7.3
  Date: Sat, 08 Nov 2014 13:45:31 GMT
  Content-Type: text/html; charset=iso-8859-1
  Content-Length: 218
  Location: http://www.aiaigame.com/index.html
  Cache-Control: max-age=300
  Expires: Sat, 08 Nov 2014 13:50:31 GMT
  Powered-By-ChinaCache: MISS from CHN-SX-3-3gC.2
  Age: 125
  Powered-By-ChinaCache: HIT from CHN-TJ-7-3V2.6
  Connection: close
Location: http://www.aiaigame.com/index.html [following]
--2014-11-08 21:47:36--  http://www.aiaigame.com/index.html
Resolving www.aiaigame.com... 119.90.14.54, 119.90.14.59, 220.181.64.153, ...
Connecting to www.aiaigame.com|119.90.14.54|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Sat, 08 Nov 2014 13:42:50 GMT
  Server: Apache/2.2.10 (Unix) DAV/2 PHP/5.2.6 mod_ssl/2.2.10 OpenSSL/0.9.8e-fips-rhel5
  Last-Modified: Fri, 07 Nov 2014 09:14:50 GMT
  ETag: "31a8087-132ee-507413eb6f680"
  Accept-Ranges: bytes
  Content-Length: 78574
  Cache-Control: max-age=300
  Expires: Sat, 08 Nov 2014 13:47:50 GMT
  Vary: Accept-Encoding,User-Agent
  Content-Type: text/html
  Powered-By-ChinaCache: HIT from 01011623g3.3
  Age: 288
  Powered-By-ChinaCache: HIT from 01001743SJ
  Connection: keep-alive
Length: 78574 (77K) [text/html]
Saving to: 「index.html.4」
  
100%[=====================================================================================================================================================>] 78,574      --.-K/s   in 0.005s  
  
2014-11-08 21:47:38 (16.3 MB/s) - 「index.html.4」 saved [78574/78574]

經過該請求,咱們能夠清楚的看到,請求是先已經鏈接到了123.150.50.14:80而後發生的302跳轉,頭信息裏清楚的寫到Powered-By-ChinaCache: HIT from CHN-TJ-7-3V2.6,也就是說是 CDN 自身的問題,並且下面的跳轉的網頁也是使用ChinaCache的客戶。

這樣問題獲得了定位,CDN 那邊也沒法再推脫,才着手處理。

案例二:訪問網頁時 css 裏面的圖片都沒法訪問

訪問網頁時 css 裏面的圖片都沒法訪問,單獨打開圖片地址能訪問。使用 wget --referer 定位是防盜鏈錯誤設置

故障截圖(有點醜)

1478785497119895.jpeg

我把這個問題反饋給客服,給個人答覆是他們沒有作任何限制,是咱們源站的問題。那隻能講證據了。

首先確認源站沒問題,模擬瀏覽器訪問時帶上referer

wget -S -O /dev/null --header="Host: img.topit.me" --referer="http://static.topitme.com/s/css/main21.css" http://211.155.84.132/img/bar/next.png

結果以下,說明源站是沒有設置權限的

wget -S -O /dev/null --header="Host: img.topit.me" --referer="http://static.topitme.com/s/css/main21.css" http://211.155.84.132/img/bar/next.png
--2015-05-07 13:52:50--  http://211.155.84.132/img/bar/next.png
Connecting to 211.155.84.132:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Server: nginx
  Date: Thu, 07 May 2015 05:52:50 GMT
  Content-Type: image/png
  Content-Length: 3022
  Connection: keep-alive
  Last-Modified: Wed, 04 Jan 2012 14:44:07 GMT
  Expires: Sun, 04 May 2025 05:52:50 GMT
  Cache-Control: max-age=315360000
  Accept-Ranges: bytes
Length: 3022 (3.0K) [image/png]

同時,綁定host的也採用另外一種方式wget -e http_proxy

wget -SO /dev/null --referer="http://static.topitme.com/s/css/main21.css" http://img.topit.me/img/style/icon_heart.png -e http_proxy=211.155.84.137

而後直接請求,不綁定host再請求

wget -S  -O /dev/null  --referer="http://static.topitme.com/s/css/main21.css"  http://img.topit.me/img/bar/next.png
--2015-05-07 11:29:21--  http://img.topit.me/img/bar/next.png
Resolving img.topit.me... 111.202.7.252, 125.39.78.164
Connecting to img.topit.me|111.202.7.252|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 403 Forbidden
  Server: nginx
  Date: Thu, 07 May 2015 03:29:21 GMT
  Content-Type: text/html
  Content-Length: 162
  Connection: keep-alive
2015-05-07 11:29:21 ERROR 403: Forbidden.

能夠清晰的看到域名的解析過程,CDN DNS 經過預約義策略,返回到最優的 ip 111.202.7.252予以訪問。而後返回了403。只有我截圖對比了兩種狀況,CDN 客服才主動着手處理這個問題。

永遠不要期望着客服來幫你解決問題,只有本身找到問題。

相關文章
相關標籤/搜索