WEB服務器 - Apache、Nnginx、Lighttpd的比較和擇優

1. Apache服務器和nginx的優缺點: 
我們之前大量使用Apache來作爲HTTPServer。 Apache具有很優秀的性能,而且通過模塊可以提供各種豐富的功能。
1) 首先Apache對客戶端的響應是支持併發的 ,運行httpd這個daemon進程之後,它會同時產生多個孩子進程/線程,每個孩子進程/線程分別對客戶端的請求進行響應;
2) 另外,Apache可以提供靜態和動態的服務 ,例如對於PHP的解析不是通過性能較差的CGI實現的而是通過支持PHP的模塊來實現的(通常爲mod_php5,或者叫做apxs2)。
3) 缺點: 
因此通常稱爲Apache的這種Server爲process-based server ,也就是基於多進程的HTTPServer,因爲它需要對每個用戶請求創建一個孩子進程/線程進行響應;
這樣的缺點是,如果併發的請求非常多(這在大型門戶網站是很常見的)就會需要非常多的線程,從而佔用極多的系統資源CPU和內存。因此對於併發處理不是Apache的強項。 
4)解決方法:
 
目前來說出現了另一種WebServer,在並 發方面表現更加優越,叫做asynchronous servers異步服務器。最有名的爲Nginx和Lighttpd。 所謂的異步服務器是事件驅動程序模式的event-driven,除了用戶的併發請求通常只需要一個單一的或者幾個線程。因此佔用系統資源就非常少。這幾 種又被稱爲lightweight web server。
舉例,對於10,000的併發連接請求,nginx可能僅僅使用幾M的內存;而Apache可能需要使用幾百M的內存資源。


2. 實際中單一的使用: 
1)關於單一使用Apache來作爲HTTPServer的情況我們不用再多做介紹,非常常見的應用;
 
上面我們介紹到Apache對於PHP等服務器端腳本的支持是通過自己的模塊來實現的,而且性能優越。
2)我們同樣可以單單使用 nginx或者lighttpd來作爲HTTPServer來使用。 
nginx和lighttpd和Apache類似都通過各種模塊可以對服務器的功能進行豐富的擴展,同樣都是通過conf配置文件對各種選項進行配置。
對於PHP等,nginx和lighttpd都沒有內置的 模塊來對PHP進行支持,而是通過FastCGI來支持的。 
Lighttpd 通過模塊可以提供CGI, FastCGI和SCGI等服務,Lighttpd is capable of automatically spawning FastCGI backends as well as using externally spawned processes. 
nginx則沒有自己提供處理PHP的功能,需要通過第三方的模塊來提供對PHP進行FastCGI方式的集成。
nginx has module support for FastCGI via a built-in module, SCGI and WSGI via 3rd Party module. The user must be able to spawn the processes separately because nginx is not able to automatically spawn them [9]. nginx does not support normal CGI applications [10], which is actually a security benefit.

Lighttpd vs nginx :http://www.wikivs.com/wiki/Lighttpd_vs_nginx

3.反向代理Reverse Proxy: 
0) 代理服務器的概念proxy server: 

代理服務器
 的概念很容易理解,就是通常作爲兩臺機器中間的機器,需要提供的功能往往有:

緩 存caching,安全, 負載均衡load banlancing。

所謂的負載均衡就是,很多機器使用一個代理的時候,代理服務器需要對各個服務器進行均衡。
我們常見的代理是正向的代理,例如我們機房有20臺電腦要上網,現在只有一個電腦可以上網,那麼可以使用這臺電腦作爲代理服務器,所有通過網絡的數據傳輸 都要經過該代理服務器。

而反向代理,是和正向代理相反的 ,正向代理針對服務接收方用戶來說,反向代理或者叫做服務器端代理是針對服務器端的,意思是有多臺服務器,反向代理服務器對用戶的請求代理髮送給其中的一 臺服務器進行處理。

Proxy server :http://en.wikipedia.org/wiki/Proxy_server

1) 實際中對於一個大型網站,我們通常使用很多臺sever來構成一個cluster來對用戶的各種請求進行響應。
因此通常需要一臺或者多臺反向代理服務器來對多臺Server進行服務。 
這個反向代理服務器需要提供的功能一般都包括:
    安全方面;緩存壓縮功能;負載均衡 功能;

Reverse proxy :http://en.wikipedia.org/wiki/Reverse_proxy

(需要注意反向代理服務器和防火牆優點類似,但是防火牆一般只有安全方面的考慮,沒有緩存和負載均衡方面的功能。)

3) 綜上,實際中Web服務器端的架構 
通常是多臺Web服務器運行並行地提 供服務;同時還需要在Web服務器前段部署一臺或者多臺反向代理服務器,一方面緩存一些靜態數據,或者將Web服務器動態產生的一些內容緩存,另一方面通 過負載均衡功能,可以均勻地將用戶的併發請求傳遞給多臺Web服務器進行處理。 
這樣一方面可以大大降低後面每臺Web服務器的負擔;另一方 面可以實現多臺服務器的負載均衡。 

4. 實際中使用nginx或者lighttpd當做反向代理服務器,後臺佈置多臺ApacheHTTPServer: 
1)上面說到,nginx和lighttpd的優點在於速度快,輕量級,在處理多用戶併發方面要大大優於Apache服務器。
 
因此我們通常可以把他們作爲反向代理服務器放置到多臺的Apache Web服務器前段,來一方面緩存數據,另一方面實現多臺服務器的負載均衡。
2) 當然了Apache本身通過mod_proxy和mod_cache也可以實現反向代理和緩存功能 ,但是在處理高併發方面還是無法與nginx和lighttpd這種輕量的異步模式的服務器來比較。
3)另外,利用nginx和lighttpd的反響代理功 能,我們可以通過設置其configuration文件,當客戶端請求的是靜態內容(例如一些圖片,js,html文件等)的話,直接由nginx或者 lighttpd進行響應; 
如果需要訪問動態內容(通常需要實時從數據庫中讀取)的話, 則通過反向代理,nginx等可以將請求發送給後臺等待的Apache進行響應,然後Apache將相應的結果返回給nginx,後者再響應用戶的時候還 可以進行緩存。 
4)有時候還可以使用一些緩存的工具,例如Squid。 
另外nginx也提供了對一些緩存功能的支持,例如memcache 等。

5)因此如果從圖形來分析的話,通常的架構如下:

nginx作爲最前端的web cache系統


這個結構的優點:

1、可以使用nginx前端進行諸多複雜的配置,這些配置從前在squid是沒法做或者做起來比較麻煩的,比如針對目錄的防盜鏈。

2、nginx前端可以直接轉發部分不需要緩存的請求。

3、因爲nginx效率高於squid,所以某些情況下可以利用nginx的緩存來減輕squid壓力。

4、可以實現url hash等分配策略。

5、可以在最前端開啓gzip壓縮,這樣後面的squid緩存的純粹是無壓縮文檔,可以避免很多無謂的穿透。

6、因爲nginx穩定性比較高,所以lvs不需要經常調整,通過nginx調整就可以。

7、squid的文件打開數按默認的1024就綽綽有餘,不過處理的請求可一個都不會少。

8、可以啓用nginx的日誌功能取代squid,這樣做實時點擊量統計時可以精確定位到url,不必要再用低效率的grep來過濾。

9、因爲nginx的負載能力高於squid,所以在用lvs分流時可以不必分得特別均衡,出現單點故障的機率比較低。

nginx和squid配合搭建的web服務器前端系統


前端的lvs和squid,按照安裝方法,把epoll打開,配置文件照搬,基本上問題不多。

這個架構和app_squid架構的區別,也是關鍵點就是:加入了一級中層代理,中層代理的好處實在太多了:

1、gzip壓縮

壓縮可以通過nginx做,這樣,後臺應用服務器不管是apache、resin、lighttpd甚至iis或其他古怪服務器,都不用考慮壓縮的功能問 題。

2、負載均衡和故障屏蔽

nginx可以作爲負載均衡代理使用,並有故障屏蔽功能,這樣,根據目錄甚至一個正則表達式來制定負載均衡策略變成了小case。

3、方便的運維管理,在各種情況下可以靈活制訂方案。

例如,如果有人用輕量級的ddos穿透squid進行攻擊,可以在中層代理想辦法處理掉;訪問量和後臺負載突變時,可以隨時把一個域名或一個目錄的請求扔 入二級cache服務器;可以很容易地控制no-cache和expires等header。等等功能。。。

4、權限清晰

這臺機器就是不寫程序的維護人員負責,程序員一般不需要管理這臺機器,這樣假如出現故障,很容易能找到正確的人。

對於應用服務器和數據庫服務器,最好是從維護人員的視線中消失,我的目標是,這些服務只要能跑得起來就可以了,其它的事情全部可以在外部處理掉。

General Architecture of LVS Clusters

For transparency, scalability, availability and manageability of the whole system, we usually adopt three-tie architecture in LVS clusters illustrated in the following figure.


The three-tie architecture consists of

  • Load Balancer , which is the front-end machine of the whole cluster systems, and balances requests from clients among a set of servers, so that the clients consider that all the services is from a single IP address.
  • Server Cluster , which is a set of servers running actual network services, such as Web, Mail, FTP, DNS and Media service.
  • Shared Storage , which provides a shared storage space for the servers, so that it is easy for the servers to have the same contents and provide the same services.

Load balancer is the single entry-point of server cluster systems, it can run IPVS that implements IP load balancing techniques inside the Linux kernel, or KTCPVS that implements application-level load balancing inside the Linux kernel. When IPVS is used, all the servers are required to provide the same services and contents, the load balancer forward a new client request to a server according to the specified scheduling algorithms and the load of each server. No matter which server is selected, the client should get the same result. When KTCPVS is used, servers can have different contents, the load balancer can forward a request to a different server according to the content of request. Since KTCPVS is implemented inside the Linux kernel, the overhead of relaying data is minimal, so that it can still have high throughput.

The node number of server cluster can be changed according to the load that system receives. When all the servers are overloaded, more new servers can be added to handle increasing workload. For most Internet services such as web, the requests are usually not highly related, and can be run parallely on different servers. Therefore, as the node number of server cluster increases, the performance of the whole can almost be scaled up linearly.

Shared storage can be database systems, network file systems, or distributed file systems. The data that server nodes need to update dynamically should be stored in data based systems, when server nodes read or write data in database systems parallely, database systems can guarantee the consistency of concurrent data access. The static data is usually kept in network file systems such as NFS and CIFS, so that data can be shared by all the server nodes. However, the scalability of single network file system is limited, for example, a single NFS/CIFS can only support data access from 4 to 8 servers. For large-scale cluster systems, distributed/cluster file systems can be used for shared storage, such as GPFS, Coda and GFS, then shared storage can be scaled up according to system requirement too.

Load balancer, server cluster and shared storage are usually connected by high-speed networks, such as 100Mbps Ethernet network and Gigabit Ethernet network, so that the network will not become the bottleneck of system when the system grows up.

來源:

生產環境中的一些web server(主要是三巨頭apache, nginx, lighttpd):http://hudeyong926.javaeye.com/blog/813141
nginx作爲最前端的web cache系統:http://sudone.com/archie/app-nginx-squid-nginx.html 
nginx和squid配合搭建的web服務器前端系統:http://sudone.com/archie/app_nginx_squid.html
General Architecture of LVS Clusters:http://www.linuxvirtualserver.org/architecture.html 
 

作者: Sjolzy

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章