大型BBS架构.docVIP

这个架构基于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指令，这样在机器比较多的时候，purge将成为一个巨大的压力。所以在这里将nginx放在最前端并使用手工url_hash的方式分流，将经常需要purge的帖子页面和列表页面按一个url对应一台squid的策略，分布到各台squid上，并提供了一台或一组backup的squid，个别squid出现异常时将自动使用backup的机器继续提供一段时间的服务直到其正常。在这样的架构下，purge就不再是关键问题，因为一个url只会对应到一台机器上，所以purge的时候，后端app_server找到对应的机器就可以了。可以看到在前端中还有一台nginx(purge)的机器，这台机器是专用于purge的，只要发送purge指令和需要清除的url到这台机器，就可以找到相应的服务器并清除缓存了。另外，purge时还需要清理backup机器上的缓存，所以无论前端机器增加到多少，purge指令只会在2台机器上执行，如果backup机器使用到2-3台，purge指令就会在3-4台机器上执行，仍然在可接受范围之内。nginx作为前端，另有的好处：1/使用nginx的日志统计点击量非常方便2/nginx也可作为缓存，一般可以直接负责favicon.ico和logo等固定的小图片4、基于nginx的中层代理前端的lvs和squid，按照安装方法，把epoll打开，配置文件照搬，基本上问题不多。这个架构和app_squid架构的区别，也是关键点就是：加入了一级中层代理，中层代理的好处实在太多了：1、gzip压缩压缩可以通过nginx做，这样，后台应用服务器不管是apache、resin、lighttpd甚至iis或其他古怪服务器，都不用考虑压缩的功能问题。2、负载均衡和故障屏蔽nginx可以作为负载均衡代理使用，并有故障屏蔽功能，这样，根据目录甚至一个正则表达式来制定负载均衡策略变成了小case。3、方便的运维管理，在各种情况下可以灵活制订方案。例如，如果有人用轻量级的ddos穿透squid进行攻击，可以在中层代理想办法处理掉；访问量和后台负载突变时，可以随时把一个域名或一个目录的请求扔入二级cache服务器；可以很容易地控制no-cache和expires等header。等等功能。。。4、权限清晰这台机器就是不写程序的维护人员负责，程序员一般不需要管理这台机器，这样假如出现故障，很容易能找到正确的人。对于应用服务器和数据库服务器，最好是从维护人员的视线中消失，我的目标是，这些服务只要能跑得起来就可以了，其它的事情全部可以在外部处理掉。在这个架构中，假如后端的app_server上把帖子页和列表页直接生成了静态页面，那么使用中层代理再做一次url_hash，将可以解决后端app_serve