中小型網站架構分析及優化

李振良發表於2015-11-25

先看網站架構圖:

wKiom1WKdbGgXLOGAAHVOEBTyTg628.jpg

以上網站架構廣泛運用中大型網站中,本文從架構每一層分析所用主流技術和解決手段,有助於初入網站運維朋友們,進一步對網站架構認識,從而自己形成一套架構概念。

第一層:CDN

國內網路分佈主要南電信北聯通,造成跨地區訪問延遲大問題,對於有一定訪問量網站來說,增加CDN(內容分發網路)層可有效改善此現象,也是網站加速的最好選擇。CDN把網站頁面快取到全國分佈的節點上,使用者訪問時從最近的機房獲取資料,這樣大大減少網路訪問的路徑。如果想自己搭建CDN,不建議這麼做,因為什麼呢?其實說白了,就是什麼事別往運維上攔。CDN架構部署不復雜,影響效果的因素卻很多,後期管理維護也比較複雜,想達到預期的效果確非易事,這是一個費力不討好的活,最後老闆還是感覺是你能力不足。建議找專做CDN的公司,費用也不貴,有抗流量攻擊能力,效果也很好,運維也少很多事,何樂而不為呢!

第二層:反向代理(網頁快取)

如果CDN沒有快取要請求的資料則向這層發起請求,在代理伺服器配置快取功能(本地),代理伺服器就查詢本地快取是否有CDN請求的資料,如果有就直接返回給CDN,如果沒有則請求後端負載均衡器然後轉發給WEB伺服器返回資料給代理伺服器,代理伺服器再將結果給CDN。代理伺服器一般快取不經常變動的靜態頁面,如image、js、css、html等,主流的快取軟體有Squid、Varnish、Nginx。

第三層:負載均衡

訪問量較大的網站都會用到負載均衡,因為這是解決單臺伺服器效能瓶頸的最好辦法。反向代理將請求轉發給負載均衡器,負載均衡器根據演算法(輪訓、負載情況選擇後端等)交給後端WEB服務處理,WEB服務處理完成後直接返回資料給反向代理伺服器。負載均衡合理分配請求給後端多臺WEB伺服器,減輕單臺伺服器併發負載,並保證服務可用性。主流的負載均衡軟體有LVS、HAProxy、Nginx。

第四層:WEB服務

WEB服務是處理使用者請求的,WEB服務處理效率,直接影響到訪問速度,為避免這層因素造成訪問慢,應對其進行調優,讓WEB服務發揮到最佳狀態。常見的WEB服務有Apache和Nginx。

Apache優化:

1).mod_deflate壓縮模組

檢視是否載入:

# apachectl M |grep deflate

如果沒有安裝使用apxs編譯進去:

# /usr/local/apache/bin/apxs c I A apache原始碼目錄/modules/mod_deflate.c

deflate配置引數:

DeflateCompressionLevel6      #壓縮等級(1-9),數值越大效率越高,消耗CPU也就越高
SetOutputFilterDEFLATE      #啟用壓縮
AddOutputFilterByTypeDEFLATE text/html text/plain text/xml #壓縮型別
AddOutputFilterByTypeDEFLATE css js html htm xml php

2).mod_expires快取模組

檢視是否載入:

# apachectl M |grep expires

如果沒有安裝使用apxs編譯進去:

# /usr/local/apache/bin/apxs c I A apache原始碼目錄/modules/mod_expires.c

再在httpd.conf啟用模組:LoadModule expires_module modules/mod_expires.so

快取機制有三種用法:全域性、目錄和虛擬主機

全域性配置,在配置檔案末尾新增:

ExpiresActiveon       #啟用有效期控制,會自動清除已過期的快取,然後從伺服器獲取新的
ExpiresDefault "accessplus 1 days"       #預設任意格式的文件都是1天后過期
ExpiresByTypetext/html "access plus 12 months"  
ExpiresByTypeimage/jpg "access plus 12 months"   #jpg格式圖片快取12月

3).工作模式選擇及優化

apache有兩種常見工作模式,worker和prefork,預設是worker,是混合型的MPM(多路處理模組),支援多程式和多執行緒,由執行緒來處理請求,所以可以處理更多請求,提高併發能力,系統資源開銷也小於基於程式的MPM,由於執行緒使用程式記憶體空間,程式崩潰會導致其下執行緒崩潰。而prefork是非執行緒型MPM,程式佔用系統資源也比worker多,由於程式處理連線,在工作效率上也比worker更穩定。可通過apache2 l檢視當前工作模式,在編譯時使用—with-mpm引數指定工作模式。根據自己業務需求選擇不同工作模式,再適當增加工作模式相關引數,可提高處理能力。

配置引數說明:

StartServers      8   #預設啟動8個httpd程式
MinSpareServers    5    #最小的空閒程式數
MaxSpareServers    20   #最大的空閒程式數,如果大於這個值,apache會自動kill一些程式
ServerLimit      256   #伺服器允許程式數的上限
MaxClients       256  #同時最多發起多少個訪問,超過則進入佇列等待
MaxRequestsPerChild  4000  #每個程式啟動的最大執行緒

Nginx優化:

1).gzip壓縮模組

http {
    ……
    gzip on;
    gzip_min_length 1k;   #允許壓縮的頁面最小位元組數,預設是0,多大都壓縮,小於1k的可能適得其反
    gzip_buffers 4 16k;   #gzip申請記憶體的大小,按資料大小的4倍去申請記憶體
    gzip_http_version 1.0;  #識別http協議版本
    gzip_comp_level 2;    #壓縮級別,1壓縮比最小,處理速度最快,9壓縮比最大,處理速度最慢
    gzip_types text/plainapplication/x-javascripttext/css application/xml image/jpg;  #壓縮資料型別
    gzip_vary on;      #根據客戶端的http頭來判斷,是否需要壓縮
}

2).expires快取模組

server {
    location ~ .*.(gif|jpg|png|bmp|swf)$   #快取資料字尾型別
    {
      expires 30d;   #使用expires快取模組,快取到客戶端30天
    }
    location ~ .*.( jsp|js|css)?$
    {
      expires 1d;
    }
}

3).fastcgi優化

nginx不支援直接呼叫或者解析動態程式(php),必須通過fastcgi(通用閘道器介面)來啟動php-fpm程式來解析php指令碼。也就是說使用者請求先到nginx,nginx再將動態解析交給fastcgi,fastcgi啟動php-fpm解析php指令碼。所以我們有必要對fastcgi和php-fpm進行適當的引數優化。

http {
    ……
    fastcgi_cache_path/usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;  
    # FastCGI快取指定一個檔案路徑、目錄結構等級、關鍵字區域儲存時間和非活動刪除時間
    fastcgi_connect_timeout 300;    #指定連線到後端FastCGI的超時時間
    fastcgi_send_timeout 300;     #指定向FastCGI傳送請求的超時時間
    fastcgi_read_timeout 300;     #指定接收FastCGI應答的超時時間
    fastcgi_buffer_size 64k;      #指定讀取FastCGI應答第一部分需要多大的緩衝區
    fastcgi_buffers 4 64k;      #指定本地需要用多少盒多大的緩衝區來緩衝FastCGI的應答請求
    fastcgi_busy_buffers_size 128k;   
    fastcgi_temp_file_write_size 128k;  #表示在寫入快取檔案時使用多大的資料塊,預設值是fastcgi_buffers的兩倍
    fastcgi_cache TEST;          #開啟fastcgi_cache快取並指定一個TEST名稱
    fastcgi_cache_valid 200 302 1h;   #指定200、302應答程式碼的快取1小時
    fastcgi_cache_valid 301 1d;     #將301應答程式碼快取1天
    fastcgi_cache_valid any 1m;     #將其他應答均快取1分鐘
{

php-fpm.conf配置引數:

pm =dynamic        #兩種控制子程式方式(static和dynamic)
pm.max_children= 5     #同一時間存活的最大子程式數
pm.start_servers= 2    #啟動時建立的程式數
pm.min_spare_servers= 1  #最小php-fpm程式數
pm.max_spare_servers= 3  #最大php-fpm程式數

4).proxy_cache本地快取模組

http {
        ……
   proxy_temp_path  /usr/local/nginx/proxy_cache/temp;    #快取臨時目錄
   proxy_cache_path /usr/local/nginx/proxy_cache/cache levels=1:2 keys_zone=one:10m inactive=1d max_size=1g;
   #快取檔案實際目錄,levels定義層級目錄,1:2說明1是一級目錄,2是二級目錄,keys_zone儲存後設資料,並分配10M記憶體空間。inctive表示1天沒有被訪問的快取就刪除,預設10分鐘。max_size是最大分配磁碟空間
   server {
      listen 80;
      server_name 192.168.1.10;
      location / {
        proxy_cache one;   #呼叫快取區
        #proxy_cache_valid 200 304 12h; #可根據HTTP狀態碼設定不同的快取時間
        proxy_cache_valid any  10m;    #快取有效期為10分鐘
      }
      #清除URL快取,允許來自哪個網段的IP可以清除快取(需要安裝第三方模組"ngx_cache_purge"),清除URL快取方法:訪問http://192.168.1.10/purge/檔名
      location ~ /purge(/.*){
        allow 127.0.0.1;
        allow 192.168.1.0/24;
        deny all;
        proxy_cache_purge cache_one$host$1$is_args$args;
      }
 }

小結:

啟用壓縮模組可以節省一部分頻寬,會增加WEB端CPU處理,但在上圖網站架構中,WEB端啟用壓縮模組並沒有起到作用,因為傳輸到上層走的是區域網。對於直接面向使用者的架構還是要啟用的。WEB也不用啟用expires模組,因為有了反向代理伺服器和CDN,所以到不了使用者瀏覽器,開啟起不到作用。

如果反向代理使用nginx做代理,可開啟expires模組,將靜態檔案快取到使用者瀏覽器,瀏覽器發起請求時,先判斷本地快取是否有請求的資料,如果有再判斷是否過期,如果不過期就直接瀏覽快取資料,哪怕伺服器資源已經改變,所以要根據業務情況合理設定過期時間。

5. 利用PHP快取器提高程式碼執行效率

php程式在沒有使用快取器情況下,每次請求php頁面,php都會對此頁面進行程式碼編譯,這就意味著重複的編譯工作會增加伺服器負載。有了快取器就會把每次編譯後的資料快取到共享記憶體中,下次訪問直接使用緩衝區已編譯好的程式碼,從而避免重複的編譯過程,以加快其執行效率。因此PHP網站使用快取器是完全有必要的!主流的PHP快取器有:eAccelerator、XCache

第五層:動靜分離

動靜分離,顧名思義,是將動態頁面和靜態頁面分離到不同伺服器上處理,比如使用web是nginx,可以讓fastcgi部署到單獨一臺伺服器,專門解析php動態頁面,靜態頁面預設由nginx處理,並做好快取策略。再比如一個商城網站,會有大量的圖片,可以考慮增加檔案伺服器組,將請求圖片和上傳圖片的都交給檔案伺服器處理。檔案伺服器主流使用NFS,存在單點故障,可以DRBD+HeartBeat+NFS部署高可用,如果單臺壓力過大,考慮使用分散式檔案系統,如GlusterFS、MooseFS等。

《DRBD + Heratbeat + NFS 高可用檔案共享儲存》:http://blog.jobbole.com/94718/

第六層:資料庫快取

利用快取技術,把熱資料快取到記憶體中,如果請求的資料在快取中,就直接返回,否則去資料庫中取,並更新把拿的資料更新到快取系統,提高讀效能,降低資料庫壓力。快取實現有本地快取和分散式快取,本地快取是將資料快取到本地伺服器記憶體中或者檔案中。分散式快取是將資料快取到記憶體中,是分散式的,可以快取海量資料,擴充套件性好。主流的分散式快取系統有Memcached和Redis,Memcached效能穩定,速度很快,QPS可達8w左右。如果想資料持久化就選擇用Redis,效能不低於Memcached。

第七層:資料庫

這層在整個網站架構中起著主導型作用,直接決定使用者體驗,相對架構優化也比較複雜,具體請參考博文:《運維角度淺談 MySQL 資料庫優化

核心思路:減少請求層,儘可能讓前端層返回使用者請求的資料,減少後端伺服器訪問頻率,最重要是資料庫層。

相關文章