负载均衡的“伤风感冒”如何医？

这段时间，公司的web架构要升级，考虑用负载均衡;初期准备采用LVS+Keepalived，我比较有自信，刚刚在一个客户的局域网里实现了这个，所以直接把脚本移过来了;然而，杯具开始了，发现LVS怎么也实现不了后端二台web的转发。

后来关于此问题我请教了田逸兄，他怀疑我们的网络环境太复杂了，因为牵涉到内外网的问题，我们的每台机器上有5条静态路由，2个gateway，直接导致了LVS的不成功;我们试图跟network Engeneer沟通，结果是网络不能做一丝一毫改动，所以白白测试了二天。

后来改用了Nginx负载均衡器，5分钟就解决了问题，真真切切的体会到了Nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通。为了以防万一，我采用的是Nginx+keepalived高可用架构。

在这里，我不是神话Nginx，只是说这是一种解决问题的方法而矣，LVS也有适用的场合，稳定性方面是众所周知的，所以只要提到web层的负载均衡，我就想到LVS，但LVS不仅仅是;如果网络环境比较复杂的朋友们，不妨换种思路解决问题。

当然用了Nginx后，大问题暂时没有;小问题就都来了，首先是SSL，这个目前支持得算是比较好的，在负载均衡器上开启ssl功能，监听443端口，将证书放在Nginx代理上，非后面的web服务器,轻构解决掉问题，详细见以下http.conf配置文件

server { listen 443; server_name www.cn7788.com; ssl on; ssl_certificate /usr/local/nginx/keys/www.cn7788.com.crt; ssl_certificate_key /usr/local/nginx/keys/www.cn7788.com.key; ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP; }

但问题又来了，这么有个问题，跑在后方 apache 上的应用获取到的IP都是Nginx所在服务器的IP ，或者是本机 127.0.0.1 。最明显就是查看 apache 的访问日志。就会见到来来去去都是内网的IP;虽然可以通过Nginx日志来判断客户的client,但有些考虑不周全的应用，例如 Tattertools (一个博客程序) 就会犯误,后台的访问日志死活显示访客数 1，ip来自 127.0.0.1。这时候就要想办法来处理了。你可以通过修改 nginx proxy 的参数令后端应用获取到Nginx 发来的请求报文获取到外网的IP。

proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

这仅仅只是让Nginx获到到外网IP，Apache未必买帐呢，即Aapche端也需要设置，搜寻了一下，发现了apache这一个来自第三方的mod 配合Nginx proxy 使用。

说明：http://stderr.net/apache/rpaf/

下载：http://stderr.net/apache/rpaf/download/

最新版本是 mod_rpaf-0.6.tar.gz

安装也相当简单。

# tar zxvf mod_rpaf-0.6.tar.gz 下载后解压# cd mod_rpaf-0.6

Apache 的目录按自己的环境修改，并选择相应的安装方式：

#/usr/local/apache/bin/apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c

完成后会在 http.conf 的 LoadModule 区域为你多加了一行。

LoadModule mod_rpaf-2.0.so_module modules/mod_rpaf-2.0.so 经 apache 2.2.6 的实验，使用这一行启动 apache 的时候会报错的。

所以改为：

LoadModule rpaf_module modules/mod_rpaf-2.0.so

并在下方添加

RPAFenable On RPAFsethostname On RPAFproxy_ips 127.0.0.1 192.168.1.101 192.168.102

#填写Nginx所在的内网IP，Nginx的内网地址必写，不然一样失败的，这问题花了几个小时测试;有几个代理服务器的IP就写几个代理服务器的IP

RPAFheader X-Forwarded-For

保存退出后重启apache，再看看 apache 的日志内容?不再是来来去去的那几个IP了吧，呵呵。

另外这里来个小插曲，我做的某个小项目本为是基于Nginx的1+3架构，突然要加一台机器是windows2003系统，专门作存放图片及 PDF等，但项目的要求是能在nginx后的三台web上有显示图片及pdf下载的需求;当时迷糊了下，因为程序是用到的Zend Framwork，所以一直用正则作跳转;后来才想明白，IE程序是先在nginx负载均衡器上提申请，所以nginx.conf是做分发而非正则跳转，此时最前端的nginx，既是负载匀衡器也是反向代理，明白这个就好做多了，语法如下;另外注意location /StockInfo与location ~^/StockInfo的差异性，Nginx默认的是正则优先的，by the way,proxy_pass支持直接写IP的方式。

upstream mysrv { ip_hash; server 192.168.110.62; server 192.168.110.63; } upstream myjpg { server 192.168.110.3:88; } server { listen 80; server_name web.tfzq.com; proxy_redirect off; location ~ ^/StockInfo{ proxy_pass http://myjpg; }

再说下Nginx下的并发，这是个容易让人误会的概念。现在Nginx的文章满天飞，好像只要一涉及到web并发，就非将Apache换成nginx不可，其实完全没这必要;在内存足够的情况，Apache的抗并发能力也是很强的。玩了几年nginx了，遇到的最大并发也是以前在北京维护的CDN之广告网站，大约在3000-5000之间(这种情况建议用Nginx)，一般的资讯类金融网站也就100多，电子商务网站1100左右，web层的并发压力并没有想象中的大;相反，我感觉文件和数据层的压力越来越大，单个NFS服务器越来越难受了，所以我后期准备布署moosefs;而mysql数据库我一般用的是主从复制，压力也不小，目前只是从二方面来解决此问题：一、用公司最好的服务器来作数据库服务器;二、尽可能的优化，如果压力持续增长的话，后期我考虑从架构级方面优化了。对于一个网站而言，建议多从架构极的观念来看问题和解决问题。

今天一直测试网站的响应时间是用Linux/unix下工具httping,今天同事找了个专业网站给我，发现很好用，特的拿出来与大家共享http://tools.pingdom.com,可以测试个几十次然后取平均值，这样得出的结果较为精准;系统运维工作本来就是一个细腻活，有时短短几行代码，说不定就要调试几天;而有时维护的服务器日志，经常是十几万行，看得人心花缭乱...痛并快乐着，这也是算是目前工作的心态吧。