以上網(wǎng)站架構(gòu)在北京大中型網(wǎng)站建設中得到廣泛應用。本文分析了架構(gòu)各層所采用的主流技術和解決方案，有助于剛接觸網(wǎng)站運維的朋友進一步了解網(wǎng)站架構(gòu)，形成一套架構(gòu)概念。第一層：CDN

國內(nèi)網(wǎng)絡分布主要以華南電信和華北聯(lián)通為主，跨區(qū)域訪問時延問題較大。對于有一定流量的網(wǎng)站，加入CDN（Content Delivery Network）層可以有效改善這種現(xiàn)象，也是網(wǎng)站加速的最佳選擇。 CDN將網(wǎng)站頁面緩存在分布在全國各地的節(jié)點上，用戶訪問時就近機房獲取數(shù)據(jù)，大大減少了網(wǎng)絡訪問的路徑。如果要自己搭建CDN，不推薦，因為什么？其實說白了就是不堵運維。 CDN架構(gòu)的部署并不復雜，但是影響效果的因素很多，后期的管理維護也比較復雜。要達到預期的效果并不容易。這是一份吃力不討好的工作。結(jié)果老板還是覺得你能力不夠。建議找一家專門做CDN的公司，費用不貴，有抗流量攻擊的能力，效果也很好，運維也少了很多麻煩，何樂而不為呢！第二層：反向代理（網(wǎng)頁緩存）

如果CDN沒有緩存要請求的數(shù)據(jù)，就會向這一層發(fā)起請求，在代理服務器上配置緩存功能（本地），代理服務器會檢查本地緩存是否有CDN請求的數(shù)據(jù)，如果有則直接返回給CDN，如果沒有則request 后端負載均衡器再轉(zhuǎn)發(fā)給WEB服務器返回數(shù)據(jù)給代理服務器，代理服務器再將結(jié)果發(fā)送給CDN。代理服務器一般會緩存不經(jīng)常變化的靜態(tài)頁面，如image、js、css、html等，主流的緩存軟件有Squid、Varnish、Nginx等。第三層：負載均衡

訪問量大的網(wǎng)站會使用負載均衡，因為這是解決單臺服務器性能瓶頸的最好辦法。反向代理將請求轉(zhuǎn)發(fā)給負載均衡器，負載均衡器根據(jù)算法（輪訓、負載條件選擇等）傳遞給后端WEB服務進行處理，并將數(shù)據(jù)直接返回給反向代理服務器WEB服務處理完成后。負載均衡將請求合理分配到多個后端WEB服務器，減少單臺服務器的并發(fā)負載，保證服務的可用性。主流的負載均衡軟件有LVS、HAProxy、Nginx。第四層：WEB服務

WEB服務用于處理用戶請求，WEB服務的處理效率直接影響訪問速度。為避免此因素造成訪問速度變慢，應進行調(diào)優(yōu)，使WEB服務發(fā)揮最佳性能。常見的Web 服務包括Apache 和Nginx。Apache優(yōu)化：

1).mod_deflate壓縮模塊

檢查是否加載：

#apachectl M | grep放氣

如果沒有安裝，用apxs編譯：

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

放氣配置參數(shù)：

DeflateCompressionLevel6 #壓縮級別（1-9），數(shù)值越大，效率越高，CPU消耗也越高

SetOutputFilterDEFLATE #啟用壓縮

AddOutputFilterByTypeDEFLATE text/html text/plain text/xml #壓縮類型

AddOutputFilterByTypeDEFLATE css js html htm xml php

2).mod_expires緩存模塊

檢查是否加載：

#apachectl M | grep 過期

如果沒有安裝，用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).工作模式選擇及優(yōu)化

apache有兩種常見工作模式，worker和prefork，默認是worker，是混合型的MPM（多路處理模塊），支持多進程和多線程，由線程來處理請求，所以可以處理更多請求，提高并發(fā)能力，系統(tǒng)資源開銷也小于基于進程的MPM，由于線程使用進程內(nèi)存空間，進程崩潰會導致其下線程崩潰。而prefork是非線程型MPM，進程占用系統(tǒng)資源也比worker多，由于進程處理連接，在工作效率上也比worker更穩(wěn)定?？赏ㄟ^apache2 l查看當前工作模式，在編譯時使用—with-mpm參數(shù)指定工作模式。根據(jù)自己業(yè)務需求選擇不同工作模式，再適當增加工作模式相關參數(shù)，可提高處理能力。

Nginx優(yōu)化：

1).gzip壓縮模塊

http {
……
gzip on;
gzip_min_length 1k; #允許壓縮的頁面最小字節(jié)數(shù)，默認是0，多大都壓縮，小于1k的可能適得其反
gzip_buffers 4 16k; #gzip申請內(nèi)存的大小，按數(shù)據(jù)大小的4倍去申請內(nèi)存
gzip_http_version 1.0; #識別http協(xié)議版本
gzip_comp_level 2; #壓縮級別，1壓縮比最小，處理速度最快，9壓縮比最大，處理速度最慢
gzip_types text/plainapplication/x-javascripttext/css application/xml image/jpg; #壓縮數(shù)據(jù)類型
gzip_vary on; #根據(jù)客戶端的http頭來判斷，是否需要壓縮
}

2).expires緩存模塊

server {
location ~ .*.(gif|jpg|png|bmp|swf)$ #緩存數(shù)據(jù)后綴類型
{
expires 30d; #使用expires緩存模塊，緩存到客戶端30天
}
location ~ .*.( jsp|js|css)?$
{
expires 1d;
}
}

3).fastcgi優(yōu)化

nginx不支持直接調(diào)用或者解析動態(tài)程序（php），必須通過fastcgi（通用網(wǎng)關接口）來啟動php-fpm進程來解析php腳本。也就是說用戶請求先到nginx，nginx再將動態(tài)解析交給fastcgi，fastcgi啟動php-fpm解析php腳本。所以我們有必要對fastcgi和php-fpm進行適當?shù)膮?shù)優(yōu)化。

http {
……
fastcgi_cache_path/usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;
# FastCGI緩存指定一個文件路徑、目錄結(jié)構(gòu)等級、關鍵字區(qū)域存儲時間和非活動刪除時間
fastcgi_connect_timeout 300; #指定連接到后端FastCGI的超時時間
fastcgi_send_timeout 300; #指定向FastCGI傳送請求的超時時間
fastcgi_read_timeout 300; #指定接收FastCGI應答的超時時間
fastcgi_buffer_size 64k; #指定讀取FastCGI應答第一部分需要多大的緩沖區(qū)
fastcgi_buffers 4 64k; #指定本地需要用多少盒多大的緩沖區(qū)來緩沖FastCGI的應答請求
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k; #表示在寫入緩存文件時使用多大的數(shù)據(jù)塊，默認值是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配置參數(shù)：

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

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存儲元數(shù)據(jù)，并分配10M內(nèi)存空間。inctive表示1天沒有被訪問的緩存就刪除，默認10分鐘。max_size是最大分配磁盤空間
server {
listen 80;
server_name 192.168.1.10;
location / {
proxy_cache one; #調(diào)用緩存區(qū)
#proxy_cache_valid 200 304 12h; #可根據(jù)HTTP狀態(tài)碼設置不同的緩存時間
proxy_cache_valid any 10m; #緩存有效期為10分鐘
}
#清除URL緩存，允許來自哪個網(wǎng)段的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;
}
}

營銷型網(wǎng)站建設推來客總結(jié)：

啟用壓縮模塊可以節(jié)省一部分帶寬，會增加WEB端CPU處理，但在上圖網(wǎng)站架構(gòu)中，WEB端啟用壓縮模塊并沒有起到作用，因為傳輸?shù)缴蠈幼叩氖蔷钟蚓W(wǎng)。對于直接面向用戶的架構(gòu)還是要啟用的。WEB也不用啟用expires模塊，因為有了反向代理服務器和CDN，所以到不了用戶瀏覽器，開啟起不到作用。

如果反向代理使用nginx做代理，可開啟expires模塊，將靜態(tài)文件緩存到用戶瀏覽器，瀏覽器發(fā)起請求時，先判斷本地緩存是否有請求的數(shù)據(jù)，如果有再判斷是否過期，如果不過期就直接瀏覽緩存數(shù)據(jù)，哪怕服務器資源已經(jīng)改變，所以要根據(jù)業(yè)務情況合理設置過期時間。

5. 利用PHP緩存器提高代碼執(zhí)行效率

php程序在沒有使用緩存器情況下，每次請求php頁面，php都會對此頁面進行代碼編譯，這就意味著重復的編譯工作會增加服務器負載。有了緩存器就會把每次編譯后的數(shù)據(jù)緩存到共享內(nèi)存中，下次訪問直接使用緩沖區(qū)已編譯好的代碼，從而避免重復的編譯過程，以加快其執(zhí)行效率。因此PHP網(wǎng)站使用緩存器是完全有必要的！主流的PHP緩存器有：eAccelerator、XCache

第五層：動靜分離

動靜分離，顧名思義，是將動態(tài)頁面和靜態(tài)頁面分離到不同服務器上處理，比如使用web是nginx，可以讓fastcgi部署到單獨一臺服務器，專門解析php動態(tài)頁面，靜態(tài)頁面默認由nginx處理，并做好緩存策略。再比如一個商城網(wǎng)站，會有大量的圖片，可以考慮增加文件服務器組，將請求圖片和上傳圖片的都交給文件服務器處理。文件服務器主流使用NFS，存在單點故障，可以DRBD+HeartBeat+NFS部署高可用，如果單臺壓力過大，考慮使用分布式文件系統(tǒng)，如GlusterFS、MooseFS等。

第六層：數(shù)據(jù)庫緩存



利用緩存技術，把熱數(shù)據(jù)緩存到內(nèi)存中，如果請求的數(shù)據(jù)在緩存中，就直接返回，否則去數(shù)據(jù)庫中取，并更新把拿的數(shù)據(jù)更新到緩存系統(tǒng)，提高讀性能，降低數(shù)據(jù)庫壓力。緩存實現(xiàn)有本地緩存和分布式緩存，本地緩存是將數(shù)據(jù)緩存到本地服務器內(nèi)存中或者文件中。分布式緩存是將數(shù)據(jù)緩存到內(nèi)存中，是分布式的，可以緩存海量數(shù)據(jù)，擴展性好。主流的分布式緩存系統(tǒng)有Memcached和Redis，Memcached性能穩(wěn)定，速度很快，QPS可達8w左右。如果想數(shù)據(jù)持久化就選擇用Redis，性能不低于Memcached。

第七層：數(shù)據(jù)庫



這層在整個網(wǎng)站架構(gòu)中起著主導型作用，直接決定用戶體驗，相對架構(gòu)優(yōu)化也比較復雜。

核心思路：減少請求層，盡可能讓前端層返回用戶請求的數(shù)據(jù)，減少后端服務器訪問頻率，最重要是數(shù)據(jù)庫層。

我們專注高端建站，小程序開發(fā)、軟件系統(tǒng)定制開發(fā)、BUG修復、物聯(lián)網(wǎng)開發(fā)、各類API接口對接開發(fā)等。十余年開發(fā)經(jīng)驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！