背景

最近一直在做公司的应用软件服务架构的升级工作，里面涉及使用mod_proxy替换先前的mod_ajp，因为我们要用jetty7。

同时万恶的jetty 7对ajp协议支持不是很好， 具体可见我的另一篇博文：　纠结的mod_jk与jetty的组合。　在线下测试少量的请求没啥问题，一到线上跑个几分钟就开始抛异常了，查了jetty的mail list，也有人报类似的bug。

所以后续的工作重心还是回到mod_proxy_http上来，今天在调试mod_proxy配置时，出了一些小插曲，记录分享一下给大家，免得大家再走歧路。

配置需求

大致url类型介绍：

     目前公司的url基本是按模块进行划分，比如 http://域名/module/xxxx.html，　域名后多了一个module路径，用于区分不通的业务，比如home , admin , product等。

对mod_proxy的使用需求：　

1. 启用长连接。不能每次proxy转发一下，就新建一个socket，性能吃不消
2. 连接池只有一个。尽量公用连接池，目前各module之间的压力分布不均，需要合并所有module的proxy连接池，避免出现多个ProxyPass的worker连接池

Apache mod_proxy模块介绍

主要的资料还是来自于官方文档：http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

涉及的主要配置原语：

• ProxyPass 
• ProxyPassMatch　区别于ProxyPass就只是匹配方式是通过regex，其他类似
• ProxyRequests 正向代理开关
• ProxyPassReverse 反向代理，修改返回的http header信息
• ProxyPreserveHost 反向代理，是否修改请求的header信息

其他具体配置含义不多做介绍，大家可以看官方文档。

实施过程 

1.  考虑mod_proxy需求1，保持长链接

这个mod_proxy本身就支持worker池的概念，不过需要配置一下几个参数：　

最后的配置：

min=5 smax=16 ttl=600 timeout=20

说明：

• 不指定max，保持和ThreadPerChild一致
• timeout，不用设置太大，保持和原先mod_jk一致，使用20秒。如果是下载服务，可适当调大该值
• ttl空闲连接，可适当设置大一些，tomcat默认的是20秒。切忌：　需要保证 ttl <= 后端应用空闲连接的管理时间，不然会出现半开链接。

2. 共享连接池配置

思路一： 坏人匹配策略

• 先整理出应用中不需要应用进行处理的url列表，比如原先的Url Rewrite，apache下的静态资源文件
• 对不需要处理的url，逐一配置过滤 
  

  ProxyPass /image/ ! ProxyPass /ok.html !

     
• 最后对应用根目录进行proxy配置(只有这么一个公用连接池)
  

  ProxyPass / http://localhost:7001/

    

　mod_proxy进行proxy匹配时，是按照配置文件的顺序进行查找匹配，具体可见官方文档描述，直接贴英文。

The configured ProxyPass and ProxyPassMatch rules are checked in the order of configuration. The first rule that matches wins. 
So usually you should sort conflicting ProxyPass rules starting with the longest URLs first.
Otherwise later rules for longer URLS will be hidden by any earlier rule which uses a leading substring of the URL. 
Note that there is some relation with worker sharing.

For the same reasons exclusions must come before the general ProxyPass directives

说明：

• 因为考虑直接放开所有/目录的请求，风险比较大。特别是在应用有变化时，过滤url列表比如有遗漏，可能就会引发系统安全问题，比如一些jmx,web-console的后台url就会被打开。
• 原先应用使用mod_jk，采取的都是配置需要转发的请求列表，所以在列出所有过滤列表时，可能会存在遗漏的，所以最终放弃了该方案

思路二：好人匹配策略

• 先整理所有的好人列表，这个挺好整理，把公司的几个module列一下即可，同时加上一些监控的url
• 通过ProxyPassMatch原语，整理出正则匹配url，只有这里一个公用连接池
   

  ProxyPassMatch ^/(home|admin|product|monitor)/(.*)$ 　http://localhost:7001

   
• 最后可以加上拦截/目录请求，也可以不做(因为mod_proxy如果找不到匹配的ProxyPass，自然就不会处理该请求了)
  

  ProxyPass /  ! 

小插曲：在实施ProxyPassMatch配置时，真正的被apache官方文档误导了一把，万恶的主啊。花费了我近一天的时间排查问题。希望大家可以引起重视

官方文档针对ProxyPassMatch有这么一个例子：

 

ProxyPassMatch ^(home|admin|product|monitor)/(.*)$  http://localhost:7001/$1/$2 

./ab -k -c 15 -n 50000 http://10.20.156.49:2100/member/signin.htm 

-k 指定保持keepalive 
-c 并发数 
-n 请求数

tcpdump -s 0 -i lo port 2200 -nn

说明：port 2200为后端应用服务端口，-i　必须指定为loopback网络接口，因为apache和后端应用之间走的是loopback网络接口

ProxyPassMatch creates a worker like ProxyPass does,but it uses regex URI for a worker name. 
For example, your httpd.conf: 

ProxyPassMatch ^/test/(\d+)/foo.jpg http://backend.example.com/$1/foo.jpg 

then worker name is "http://backend.example.com/$1/foo.jpg", so URL never matches and the worker is no longer used. 

[Tue Nov 09 22:12:06 2010] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 0 in child 7897 for worker http://localhost:2200/$1/$2 
[Tue Nov 09 22:12:06 2010] [debug] proxy_util.c(1837): proxy: worker http://localhost:2200/$1/$2 already initialized

ProxyPassMatch ^/(home|admin|product|monitor)/(.*)$ 　http://localhost:7001