一般来说，apache的proxy有几个用途：
负载均衡：一台server撑不住，通过proxy把业务处理分流到其他server，让网站更强壮；
安全：前台用porxy或者squide挡一下，受到攻击或者黑客的时候让前端的proxy当靶子；
应用整合：让某些目录proxy到其他webserver的其他端口，不同的server整合到同一个域名下。
在最近的一个项目中，同一个网站应用要推送到不同的前端ip和域名上，而且将会分布在几十台物理服务器上，但流量并不高。惯性思维想到的方案是——发布，再发布，不管数据库还是代码，有更新就从新发布到各个服务器上。虽说我们做了很多自动化的脚本，但是这种方式还是会出现一些问题：
繁琐：每次更新完了beta还需要一个冗长的脚本执行过程，而且为了稳妥更新后的效果还需要去每个server上去人工查看；
数据库无法统一，一些应用不好实现：为了让服务更快，不得不在每台server都放上数据库，但是这样，一来，因为mysql遇到直接dump导入就不能用mysql的主从方式，推送大各个server同步时间较长，不稳定；二来，一些用户信息不方便在各个server之间做同步。
配置一台新的服务器需要时间。
在反复的纠结和测试之后，我采用apache的proxy实现了多前端单一后端的架构：
有应用A，B，C
有服务器：
P ->192.168.1.100
Q->192.168.1.101
R->192.168.1.102
S->192.168.1.103
T->192.168.1.104
给应用A分配的域名:
www.a1.com ->192.168.1.101 (Q)
www.a2.com ->192.168.1.101 (Q)
www.a3.com ->192.168.1.102 (R)
www.a4.com ->192.168.1.102 (R)
……
给应用B分配的域名:
www.b1.com ->192.168.1.101 (Q)
www.b2.com ->192.168.1.101 (Q)
www.b3.com ->192.168.1.102 (R)
www.b4.com ->192.168.1.102 (R)
……
以server P(192.168.1.100)为后端：
把A的后端放在P的81端口
把B的后端放在P的82端口
把C的后端放在P的83端口。
给Q，R，S，T的80配置好proxy和rewrite（具体的配置这里不复述，请百度上自己google一下）。
那么针对Q的80端口对应的目录下的.htaccess做如下配置：
RewriteEngine on
# A ——————–
# server Q (2 sites)
RewriteCond %{HTTP_HOST} ^www.a1.com* [OR]
RewriteCond %{HTTP_HOST} ^www.a2.com*
RewriteRule ^(.*)$ http://192.168.1.100:81/$1 [P,L]
# END A ——————–
# B ——————–
# server Q (2 sites)
RewriteCond %{HTTP_HOST} ^www.b1.com* [OR]
RewriteCond %{HTTP_HOST} ^www.b2.com*
RewriteRule ^(.*)$ http://192.168.1.100:82/$1 [P,L]
# END A ——————–
这样一来指向到serverQ的：
域名 www.a1.com [...]