经典web架构经典we架构.docVIP

PAGE  PAGE 14 nginx作为最前端的web cache系统 这个结构的优点： 1、可以使用nginx前端进行诸多复杂的配置，这些配置从前在squid是没法做或者做起来比较麻烦的，比如针对目录的防盗链。 2、nginx前端可以直接转发部分不需要缓存的请求。 3、因为nginx效率高于squid，所以某些情况下可以利用nginx的缓存来减轻squid压力。 4、可以实现url hash等分配策略。 5、可以在最前端开启gzip压缩，这样后面的squid缓存的纯粹是无压缩文档，可以避免很多无谓的穿透。 6、因为nginx稳定性比较高，所以lvs不需要经常调整，通过nginx调整就可以。 7、squid的文件打开数按默认的1024就绰绰有余，不过处理的请求可一个都不会少。 8、可以启用nginx的日志功能取代squid，这样做实时点击量统计时可以精确定位到url，不必要再用低效率的grep来过滤。 9、因为nginx的负载能力高于squid，所以在用lvs分流时可以不必分得特别均衡，出现单点故障的几率比较低。 目前这个架构还需要更详尽的测试，当前是采用的这个架构搭建。 nginx和squid配合搭建的web服务器前端系统 [2010-04-13 11:10:14] 这个架构是目前我个人觉得比较稳妥并且最方便的架构，易于多数人接受： 前端的lvs和squid，按照安装方法，把epoll打开，配置文件照搬，基本上问题不多。 这个架构和app_squid架构的区别，也是关键点就是：加入了一级中层代理，中层代理的好处实在太多了： 1、gzip压缩 压缩可以通过nginx做，这样，后台应用服务器不管是apache、resin、lighttpd甚至iis或其他古怪服务器，都不用考虑压缩的功能问题。 2、负载均衡和故障屏蔽 nginx可以作为负载均衡代理使用，并有故障屏蔽功能，这样，根据目录甚至一个正则表达式来制定负载均衡策略变成了小case。 3、方便的运维管理，在各种情况下可以灵活制订方案。 例如，如果有人用轻量级的ddos穿透squid进行攻击，可???在中层代理想办法处理掉；访问量和后台负载突变时，可以随时把一个域名或一个目录的请求扔入二级cache服务器；可以很容易地控制no-cache和expires等header。等等功能。。。 4、权限清晰 这台机器就是不写程序的维护人员负责，程序员一般不需要管理这台机器，这样假如出现故障，很容易能找到正确的人。 对于应用服务器和数据库服务器，最好是从维护人员的视线中消失，我的目标是，这些服务只要能跑得起来就可以了，其它的事情全部可以在外部处理掉。 新型的大型bbs架构（squid+nginx） [2010-04-13 11:10:14] 这个架构基于squid、nginx和lvs等技术，从架构上对bbs进行全面优化和保护，有如下特点： 1、高性能：所有的点击基本上全部由前端缓存负责，提供最快速的处理。 2、高保障度：不需考虑应用程序稳定与否、程序语言是何种、数据库是何种，都能从架构上保证稳定。 3、高可用性：对应用程序的修改达到最简化：在程序的某些地方加入清缓存的语句即可，当然还需要做页面静态化的工作和统计工作。 首先看图，这个图比较大： 这个架构的特点和一些流程的说明： 1、主域名和图片域名分离 域名分离可以使流量分离，缓存策略分离等等，好处诸多。bbs初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器，域名也要先分开。另外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取cookie对图片服务器的压力，另一个是提高安全性，避免cookie泄露。 2、使用LVS作为前端、二级代理和数据库的访问入口 使用LVS作为入口，比其他任何一种方式都来得更优质。首先LVS的负载能力很强，因为它工作在网络协议的第4层，使用虚拟ip技术，所以它本身并不担负任何流量的处理，仅仅是一个封包转发的功能；第二，LVS的配置相对简单而且稳定，一般去调整的几率比较低，也减少了因人为等因素而出现故障；第三，LVS可以处理任何端口的负载均衡，所以它基本可以做所有服务的负载均衡和容错。在这个架构中，除了处理http的80端口之外，LVS也处理了数据库mysql的3306端口，在数据库这个应用中是采用的双机热备策略。 3、使用nginx+squid作为最前端的缓存组合 在这个架构中，是最能体现app_nginx_squid_nginx架构的优势的。在这个架构中的bbs运行在缓存上，用户每发布一张帖子，都需要使用purge指令清除该帖子的缓存，如果是squid在最前端，那么每次发布一张帖子，都需要在所有的squid中调用purge指令，这样在机器比较多的时候，purg