隨着網站業務的不斷發展,用戶的規模越來越大;介於中國無比蹩腳復雜的網路環境;南電信;北聯通;中間竟然只用一條鏈路進行互聯通信!有研究表明,網站訪問延遲和用戶流失率正相關,網站訪問速度越慢,用戶越容易失去耐心而離開。為了提高更好的用戶體驗,留住用戶,網站需要加速網站訪問速度。如今主要的手段只有使用CDN和反向代理了;此時網站的架構應該是這樣的:

1、使用CDN和緩存服務器;CDN和反向代理的基本原理都是緩存數據,區別就在於CDN部署在網絡提供商的機房,使用戶在請求網站服務時,可以從距離自己最近的網絡提供商機房獲取數據;CDN的網絡環境很復雜;所謂的多重負載均衡架構模型;不過它們一般會使用DNS作為全局負載均衡器;高效,並且能夠根據客戶端的源IP地址,來判斷客戶端的來源地區;將客戶端的請求分配制本地負載均衡器;CDN架構圖如下:從下圖中可以看到,第一層GSLB和第二層GSLB都有各自的域組,第一層GSLB通過區域設置,將整個服務池分為電信的服務池和聯通的服務池,第二層GSLB通過區域設置,將電信的服務池分為各省的服務池。這里的服務池就是提供相同業務的所有POP節點的組合,各省的服務池包含兩個POP節點,POP節點也是GSLB在調度配置中所認識到的虛擬服務器.GSLB通過負載均很策略最終返回一個POP節點地址,用戶直接訪問POP節點來獲取網站緩存內容。

而反向代理則部署在網站的中心機房中,當用戶請求到達中心機房中后,首先訪問的服務器就是反向代理服務器,如果反向代理服務器ui中緩存着用戶請求的資源,就將其直接返回給用戶。使用CDN和反向代理的目的都是盡早返回數據給用戶,一方面加快用戶的訪問速度,另一方面也減輕了后端服務器的負載壓力;
2、分布式數據庫;分布式數據庫是網站數據拆分的最后手段,只有在表單數據規模非常龐大的時候才使用;
3、服務器推送;將應用程序服務器;以及緩存服務器全部推送到運營商機房中;
4、NoSQL以及搜索引擎的引入;隨着網站的業務越來越復雜,對數據的存儲和檢索需求也越來越復雜,這時網站就必須得引入一些非關系型數據庫技術如NoSQL(MongoDB,對於大數據量、髙並發、弱事務的互聯網應用, MongoDB則是一個如瑞士軍刀般的利器。盡管我不認同MongoDB會在所有場合完全取代MySQL,但我相信它完全可以滿足Web 2.0和移動互聯網應用的數據存儲需求。MongoDB內置的水平擴展機制提供了從百萬到十億級別的數據量處理能力,其開箱即用的特性也大大降低了中小網站的運維成本),以及非數據庫查詢技術如搜索引擎;NoSQL和搜索引擎對可伸縮的分布式特性具有更好的支持。因此,此時的架構模型就如下圖所示: 喜歡的話就點個贊唄;

Nginx 反向代理配置:
user nobody nobody; worker_processes 4; worker_rlimit_nofile 51200; error_log logs/error.log notice; pid /var/run/nginx.pid; events { use epoll; worker_connections 51200; } http { server_tokens off; include mime.types; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 20m; client_body_buffer_size 256k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 128k; proxy_buffers 4 64k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 128k; default_type application/octet-stream; charset utf-8; client_body_temp_path /var/tmp/client_body_temp 1 2; proxy_temp_path /var/tmp/proxy_temp 1 2; fastcgi_temp_path /var/tmp/fastcgi_temp 1 2; uwsgi_temp_path /var/tmp/uwsgi_temp 1 2; scgi_temp_path /var/tmp/scgi_temp 1 2; ignore_invalid_headers on; server_names_hash_max_size 256; server_names_hash_bucket_size 64; client_header_buffer_size 8k; large_client_header_buffers 4 32k; connection_pool_size 256; request_pool_size 64k; output_buffers 2 128k; postpone_output 1460; client_header_timeout 1m; client_body_timeout 3m; send_timeout 3m; log_format main '$server_addr $remote_addr [$time_local] $msec+$connection ' '"$request" $status $connection $request_time $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; open_log_file_cache max=1000 inactive=20s min_uses=1 valid=1m; access_log logs/access.log main; log_not_found on; sendfile on; tcp_nodelay on; tcp_nopush off; reset_timedout_connection on; keepalive_timeout 10 5; keepalive_requests 100; gzip on; gzip_http_version 1.1; gzip_vary on; gzip_proxied any; gzip_min_length 1024; gzip_comp_level 6; gzip_buffers 16 8k; gzip_proxied expired no-cache no-store private auth no_last_modified no_etag; gzip_types text/plain application/x-javascript text/css application/xml application/json; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; upstream varnish 81 { least_conn server 172.16.100.103:81 weight=1 max_fails=2; server 172.16.100.104:81 weight=1 max_fails=2; server 172.16.100.105:81 weight=1 max_fails=2;
} server { listen 80; server_name www.firefox.com; # config_apps_begin root /data/webapps/htdocs; access_log /var/logs/webapp.access.log main; error_log /var/logs/webapp.error.log notice; location / { location ~* ^.*/favicon.ico$ { root /data/webapps; expires 180d; break; } if ( !-f $request_filename ) { proxy_pass http://varnish 81; break; } } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } server { listen 8088; server_name nginx_status; location / { access_log off; deny all; return 503; } location /status { stub_status on; access_log off; allow 127.0.0.1; allow 172.16.100.71; deny all; } } }
