【.com独家特辑】期间公司web架构需要升级，考虑负载均衡；初期准备用LVS+Keepalived，比较有信心。这个是在局域网中实现的，所以直接把脚本搬过去了；然而悲剧开始了，发现LVS无法实现两个后端web的转发。后来我就这个问题请教了天一弟兄。他怀疑我们的网络环境太复杂了，因为涉及到内网和外网的问题。我们每台机器上都有5条静态路由和2个网关，直接导致LVS失效。不成功;尝试和网络工程师沟通，结果是网络根本改不了，测试了两天无果。后来换成Nginx负载均衡，5分钟就解决了问题。真正体会到Nginx对网络的依赖更少了。理论上只要ping通，网页访问正常，就可以连接nginx。为了以防万一，我采用了Nginx+keepalived的高可用架构。在这里，我不是神话Nginx，我只是说这是一种解决问题的方法。LVS也很适合的场合。稳定性是众所周知的，所以说到web层的负载均衡，我就想到了LVS，但是LVS不只是；如果网络环境比较复杂的朋友，不妨换个思路解决问题。当然，使用了Nginx之后，暂时没有什么大问题；小问题来了，首先是SSL，目前支持的比较好，在负载均衡器上开启ssl功能，监听443端口，把证书放在Nginx代理上，不要放在后面的web服务器上，轻结构解决问题看下面的http.conf配置文件server{listen443;server_namewww.cn7788.com;sslon;ssl_certificate/usr/local/nginx/keys/www.cn7788.com。阴极射线管；ssl_certificate_key/usr/local/nginx/keys/www.cn7788.com.key；ssl_protocolsSSLv3TLSv1；ssl_ciphersALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP;但是问题又来了。这是一个问题。后面apache上运行的应用获取到的IP是Nginx所在服务器的IP，或者本机的127.0.0.1。最明显的是查看apache访问日志。您将看到来自Intranet的IP进出；虽然可以通过Nginx日志来判断客户端的client，但是一些没有考虑周全的应用，比如Tattertools（一个博客程序），会出错，后台的访问日志会显示生死。访客数为1，ip来自127.0.0.1。这个时候，我们就必须想办法对付它。可以修改nginxproxy的参数，让后端应用获取到Nginx发送的获取外网IP地址的请求报文。proxy_set_headerHost$主机；proxy_set_headerX-真实IP$remote_addr；proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;这个只是让Nginx获取外网IP，Apache可能不买，就是Aapche这边也需要设置，搜索了一下发现Apache是??第三方的mod，是搭配Nginx代理使用的。说明：http://stderr.net/apache/rpaf/下载：http://stderr.net/apache/rpaf/download/最新版本是mod_rpaf-0.6.tar.gz安装也很简单。#tarzxvfmod_rpaf-0.6.tar.gz下载并解压#cdmod_rpaf-0.6Apache目录根据自己的环境，选择对应的安装方式：#/usr/local/apache/bin/apxs-i-c-nmod_rpaf-2.0.somod_rpaf-2.0.c完成后会在http.conf的LoadModule区域为你多加一行。LoadModulemod_rpaf-2.0.so_modulemodules/mod_rpaf-2.0.so经过apache2.2.6的实验，使用这一行启动apache会报错。所以改成：LoadModulerpaf_modulemodules/mod_rpaf-2.0.so添加RPAFenableOnRPAFsethostnameOnRPAFproxy_ips127.0.0.1192.168.1.101192.168.102#填写Nginx所在的内网IP，Nginx的内网地址一定要写，否则会失败。测试这个问题花了好几个小时；如果有几个代理服务器IP，写几个代理服务器的IPRPAF头X-Forwarded-For，保存退出，重启apache，再看apache的日志内容？不再是那几个来来去去的IP了，呵呵。另外，这里有个小插曲。我做的一个小项目，最初是基于Nginx的1+3架构。突然需要加一台windows2003系统的机器，专门用来存放图片和PDF的。nginx背后的三个网站都有显示图片和下载pdf的需求；我当时一头雾水，因为程序用的是ZendFramwork，所以跳转一直用正则表达式；后来想通了，IE程序是先加载到nginx上的，应用是在balancer上提交的，所以nginx.conf是为了分发，而不是常规的重定向。此时前端nginx既是负载均衡器又是反向代理。理解这一点要容易得多。语法如下；另外，注意location/StockInfo和location~^/StockInfo的区别，Nginx默认是regex优先，顺便说一句，proxy_pass支持直接写IP的方式。upstreammysrv{ip_hash;服务器192.168.110.62；服务器192.168.110.63；}upstreammyjpg{server192.168.110.3:88;}服务器{listen80;server_nameweb.tfzq.com;proxy_redirectoff；位置~^/StockInfohttp://proxy_pmyjpg;}先说说Nginx下的并发，这是一个容易被误解的概念。现在Nginx的文章满天飞。看来只要涉及到web并发，就要用nginx替换apache了。事实上，完全没有必要；在内存充足的情况下，Apache的抗并发能力也很强。玩nginx好几年了，遇到最大的并发也是北京维护的CDN的广告网站，3000-5000左右（本例推荐Nginx），一般资料金融网站100多，电商网站1100左右，web层并发压力没有想象中那么大；反而感觉文件和数据层的压力越来越大，单台NFS服务器越来越难受，所以打算后面部署moosefs；至于mysql数据库，我一般都是主从复制，压力不小。目前我只从两个方面解决这个问题：1、使用公司最好的服务器作为数据库服务器；2.尽量优化，如果压力继续增长的话，后面会考虑从架构层面优化。对于一个网站，建议从架构的角度来看待问题和解决问题。今天一直在Linux/unix下使用httping工具测试网站的响应时间。今天同事帮我找了一个专业的网站，觉得很有用。特地拿出来分享给大家。http://tools.pingdom.com，可以测试几十次再取平均值，这样结果更准确；系统运维工作是一项精细的工作，有时仅仅几行代码，调试起来可能需要几天时间；而且有时候维护的服务器日志，动辄十几万行，看得眼花缭乱……痛并快乐着，这也是现在工作的心态。【.com独家专题文章，未经授权禁止转载，合作媒体转载请注明原文出处和作者！】
