原理很簡單，apache直接響應靜態資源請求，動態請求丟給tomcat。

線上環境使用apache+tomcat的形式部署應用程序，前端使用apache監聽80端口，后端使用tomcat部署應用。tomcat的靜態資源響應能力和并發處理能力均不如apache，經測試，apache響應靜態資源的速度比tomcat快10%左右。

因此，有必要減輕一下tomcat的負載，獲得更高的性能。基本思路就是將靜態資源交給apache響應，動態資源交給tomcat，下面貼出配置以及解說。

配置總覽

<LocationMatch "/app/(static/)?(css|flash|images|img|js)">
    ProxyPassMatch !
    <IFModule mod_headers.c>
        Header set Cache-Control "max-age=604800"
    </IFModule>
</LocationMatch>

FileEtag None
Alias /app/static /var/lib/tomcat7/webapps/app
Alias /app /var/lib/tomcat7/webapps/app
<Directory "/var/lib/tomcat7/webapps">
    AllowOverride None
    Require all granted                                #apache2.4的配置，注意2.2可能不識別這個，需要改為

                                                            #Order Allow,Deny
                                                            #Allow From All

</Directory>
ProxyRequests off                                      #開啟反向代理
ProxyPass /app ajp://127.0.0.1:8009/app    #訪問ajp協議時無需ProxyPassReverse</pre> 
  
Apache和Tomcat的配置及說明

需要說明的是，這個反向代理使用了apache的模塊proxy_ajp，并沒有使用http反向代理。開啟這個模塊需要在apache的配置文件中加上
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
 
  
ubuntu下安裝的apache直接使用命令a2enmod proxy_ajp即可

使用ajp做反向代理的原因主要有兩個，一個是proxy_ajp是apache的內置模塊，使用配置方便，而且性能穩定，無需安裝第三方模塊。第二個是apache和tomcat都是自家產品，整合起來方便，穩定性高，而且tomcat的文檔中也是推薦使用ajp協議反向代理的。
在tomcat中需要開啟ajp端口，找到tomcat的server.xml中的AJP關鍵字，修改配置如下：
<Connector address="127.0.0.1" port="8009" URIEncoding="UTF-8" protocol="AJP/1.3" />
 
  
打開AJP端口，如果無需對外可以只監聽127.0.0.1. 這樣apache就可以通過ProxyPass訪問到ajp://127.0.0.1:8009。

tomcat存放靜態資源的目錄一般固定，所以反向代理配置還是很容易的，使用LocationMatch用正則同時匹配多個靜態資源的目錄即可，使用Alias定義路徑別名，別忘了使用Directory配置段讓apache具有對目錄的訪問權限。
apache對靜態資源處理很強大，可以稍微改一下靜態資源的響應，讓訪問性能提升。修改響應headers需要加載headers模塊。
LoadModule headers_module modules/mod_headers.so
 
  
ubuntu下安裝的apache使用命令a2enmod headers即可。

讓瀏覽器緩存靜態資源，對靜態資源加上Cache-Control "max-age=604800"，告訴瀏覽器將靜態資源在本地緩存一周。
FileEtag None告訴apache關閉Etag，apache會默認對靜態資源加上Etag頭，但是這個頭通常是不推薦使用的，我記得以前在哪本資料上看到過，說是雅虎的前端工程師們一致認為不使用ETag比較好，雖然ETag計算文件的變化更準確一些，但是會有一些問題，因為ETag是文件修改時間以及inode號之類的參數計算得到，會帶來額外的負載。而且在CDN加速時，由于CDN上的inode和服務器不一致，導致CDN上ETag和服務器不同而緩存失效。所以通常情況下是不推薦使用ETag的，精確到秒級別的Last-Modified一般足夠使用了，一秒內多次修改靜態資源的幾率并不高。
最終結果測試
最后，重啟apache生效，看一下最終結果：
直接訪問，可以看到靜態資源都是(from cache) 

 
F5刷新，可以看到靜態資源都是304 

 
CTRL+F5強制刷新，看一下靜態資源的響應頭 

 
修改響應頭信息有效，帶上了Cache-Control，同時apache也自動為靜態資源加上了Last-Modified，同時刪掉了ETag，靜態資源緩存成功。
再看一下tomcat的accesslog
192.168.1.45 - - [27/Oct/2014:09:56:55 +0800] "GET /app/customer/list HTTP/1.1" 200 29733
192.168.1.45 - - [27/Oct/2014:10:05:26 +0800] "GET /app/user/preChangePwd HTTP/1.1" 200 17140
192.168.1.45 - - [27/Oct/2014:10:05:29 +0800] "GET /app/user/showOrgInfo HTTP/1.1" 200 14318
192.168.1.45 - - [27/Oct/2014:10:05:32 +0800] "GET /app/customer/list HTTP/1.1" 200 29733
192.168.1.56 - - [27/Oct/2014:10:09:50 +0800] "GET /app/configuration/showConfigHistory HTTP/1.1" 200 17279
192.168.1.17 - - [27/Oct/2014:10:10:14 +0800] "GET /app/desktop HTTP/1.1" 302 -
192.168.1.17 - - [27/Oct/2014:10:10:14 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
192.168.1.34 - - [27/Oct/2014:10:10:54 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
192.168.1.34 - - [27/Oct/2014:10:10:59 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
192.168.1.34 - - [27/Oct/2014:10:20:44 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
192.168.1.34 - - [27/Oct/2014:10:20:46 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
192.168.1.34 - - [27/Oct/2014:10:20:51 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
192.168.1.34 - - [27/Oct/2014:10:21:04 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
192.168.1.34 - - [27/Oct/2014:10:22:57 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
192.168.1.34 - - [27/Oct/2014:10:23:50 +0800] "GET /app/auth/login HTTP/1.1" 200 11187
 
  
可以看到已經沒有靜態資源的請求信息了，動靜分離成功！

 

 來自：http://my.oschina.net/abcfy2/blog/337619