布猫

一般来说，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 www.a2.com 的所有请求通过反向代理转发到了 serverP的81端口
域名 www.b1.com www.b2.com 的所有请求通过反向代理转发到了 serverP的82端口

以此类推，不管前端有多少台服务器，我们只要搭建好了apache(proxy&rewrite)，只需要通过ftp来维护.htaccess就能灵活设置多前端单一后端的proxy了。

PS：一般来说通过ftp软件是无法看到.htaccess文件的，每个ftp软件都有自己一套设置支持浏览这类文件，这里推荐一下filezilla这个免费ftp工具，只需把菜单中“服务器”->“强制显示隐藏文件”开启就可以正常显示隐藏文件了。