论坛首页 Java企业应用论坛

请教大型WEB系统的架构设计和技术选型

浏览 118895 次
精华帖 (1) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (1)
作者 正文
   发表时间:2007-09-04  
EJB并非不能用,而是看你怎么用,那本without EJB的书已经就这个问题讲得很明白了。楼主的技术构架总体来看没太大问题,细节方面还得在实际运行的时候再优化调整。想想看每秒30万的点击,那一秒钟该有多少是重复的数据呀,如果能把缓存做好,减少动态查询,相信20台web承受五万个并发都没问题。
1 请登录后投票
   发表时间:2007-09-04  
cauherk 写道
建议一下:
1、数据库压力问题
所有的压力最终都会反映到数据库方面,一定要对数据库有一个整体的规划。
可以按照业务、区域等等特性对数据库进行配置,可以考虑分库、使用rac、分区、分表等等策略,确保数据库能正常的进行交易。
2、事务问题
你采用了两种类型数据库,一个SQL Server、一个oracle,如果一个交易需要在两个数据库中操作,那么必须考虑到分布式事务,你应该仔细的设计你的系统,来避免使用分布式事务,以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整),来避免分布式事务的问题,毕竟commit失败的几率很低。(某个超大型系统,有3套数据库,也是采用的延迟提交策略,避免分布式事务带来的对数据库过大的压力)。
看到了你在应用前端(weblogic EJB)采用了F5,我个人不是很赞同这个方案,虽然F5是一个好的L4产品,也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB,如果采用了这种方案,把不需要使用分布式事务的交易变成了分布式交易,试想,一个web如果在一个请求中,访问了后端两个EJB,那么L4就会有可能把请求分发到不同的服务器上,没有对事务维持在一个服务器中,就不能使用本地事务。同样,一个web,访问后端一个请求,这个请求中需要3个EJB,那么极有可能把这3个请求分发到不同的服务器,又造成了分布式事务。weblogic是一个好的J2EE产品,对这种有事务关联的负载均衡,它会优先考虑采用一个服务器里面的应用,这样就采用了本地事务,提高了响应速度,减小了分布式事务对应用和数据库的压力。
3、web的优化
我个人认为,一个商业的应用,硬件的投资可能不是主要的瓶颈,往往可维护性,可扩展性是最主要的问题。
没有必要采用不成熟的方案,要更多的使用成熟的方案,将静态、图片独立使用不同的服务器,对于常态的静态文件,采用E-TAG或者客户端缓存,google很多就是这样干的。对于热点的功能,考虑使用完全装载到内存,保证绝对的响应速度,对于需要频繁访问的热点数据,采用集中缓存(多个可以采用负载均衡),减轻数据库的压力,比如:很多配置信息,操作员信息等等。
对了,对于几乎除二进制文件,都应该在L4上配置基于硬件的压缩方案,减少网络的流量。提高用户使用的感知。
4、网络问题
你不可能要求所有的使用人员,都和你的服务器在一个运营商的网络内,可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资,可以采用CDN(内容分发网),减轻你的服务器压力。


做好cache应该就行了,楼主的业务比较简单,热点的业务数据应该也不多,可以考虑在web前面加上squid做cache,然后在应用层做点数据库的cache,问题应该不大。

对于CDN,我们用过;并没有想象中的那么好,cache的效果非常有限,延迟也比较大,而且CDN同步更新时对web服务器的压力非常大,我们web服务器就被个搞死过。如果不是为了南北铁通XXXX互联互通,建议有那个钱不如自己加几台服务器。






0 请登录后投票
   发表时间:2007-09-04  
without ejb吧
0 请登录后投票
   发表时间:2007-09-04  
cauherk 写道
建议一下:
1、数据库压力问题
所有的压力最终都会反映到数据库方面,一定要对数据库有一个整体的规划。
可以按照业务、区域等等特性对数据库进行配置,可以考虑分库、使用rac、分区、分表等等策略,确保数据库能正常的进行交易。
2、事务问题
你采用了两种类型数据库,一个SQL Server、一个oracle,如果一个交易需要在两个数据库中操作,那么必须考虑到分布式事务,你应该仔细的设计你的系统,来避免使用分布式事务,以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整),来避免分布式事务的问题,毕竟commit失败的几率很低。(某个超大型系统,有3套数据库,也是采用的延迟提交策略,避免分布式事务带来的对数据库过大的压力)。
看到了你在应用前端(weblogic EJB)采用了F5,我个人不是很赞同这个方案,虽然F5是一个好的L4产品,也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB,如果采用了这种方案,把不需要使用分布式事务的交易变成了分布式交易,试想,一个web如果在一个请求中,访问了后端两个EJB,那么L4就会有可能把请求分发到不同的服务器上,没有对事务维持在一个服务器中,就不能使用本地事务。同样,一个web,访问后端一个请求,这个请求中需要3个EJB,那么极有可能把这3个请求分发到不同的服务器,又造成了分布式事务。weblogic是一个好的J2EE产品,对这种有事务关联的负载均衡,它会优先考虑采用一个服务器里面的应用,这样就采用了本地事务,提高了响应速度,减小了分布式事务对应用和数据库的压力。
3、web的优化
我个人认为,一个商业的应用,硬件的投资可能不是主要的瓶颈,往往可维护性,可扩展性是最主要的问题。
没有必要采用不成熟的方案,要更多的使用成熟的方案,将静态、图片独立使用不同的服务器,对于常态的静态文件,采用E-TAG或者客户端缓存,google很多就是这样干的。对于热点的功能,考虑使用完全装载到内存,保证绝对的响应速度,对于需要频繁访问的热点数据,采用集中缓存(多个可以采用负载均衡),减轻数据库的压力,比如:很多配置信息,操作员信息等等。
对了,对于几乎除二进制文件,都应该在L4上配置基于硬件的压缩方案,减少网络的流量。提高用户使用的感知。
4、网络问题
你不可能要求所有的使用人员,都和你的服务器在一个运营商的网络内,可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资,可以采用CDN(内容分发网),减轻你的服务器压力。



以你的投资,别说5000并发,500万并发都不是问题

1.首先为什么要分布WEB层,Service层?
2.为什么需要分布式事务?
0 请登录后投票
   发表时间:2007-09-04  
EBAY 一台SUN V440,weblogic能做到500WAN Page view
0 请登录后投票
   发表时间:2007-09-04  
对于你你们舍得投入巨资买weblogic,买oracle,买几十台HP OR ibm服务器的项目,最好的办法是拨打范凯先生的电话,告诉他们你们需要咨询,几个月后你总共加起来买2台服务器就可以搞定。

这可能是最最捷径的办法,真的!
9 请登录后投票
   发表时间:2007-09-04  
夸张的软硬件条件
0 请登录后投票
   发表时间:2007-09-04  
这个帖子是技术贴,所以仅仅讨论技术问题。

1、F5的使用
F5不光可以做web的负载均衡,也可以做基于第4层的负载均衡。
比如:银行接口,大部分基于socket通讯的,就可以在前面架设一套F5设备,将请求分发到不同的服务器上。
大部分使用F5都是在web层次上,如果使用基于源IP地址的策略,有很多客户端都是基于代理服务器,这个时候源IP地址是一样的,其实并没有把这些用户给分发到不同的服务器上,建议采用基于cookie insert的方式,采用cookie的会话保持策略,loadbalance的算法,需要仔细的结合自己的应用的实际情况来设置。

2、大并发的问题
现在你得到了一个大概的系统能承受的并发,但是还达不到系统的设计目标。
应该从应用的角度去分析这个问题,web方面,通过工具(httplook),检查一下客户端发起的请求都是什么响应状态,如果看到很多304请求状态,你需要优化你的url缓存,看一下每个url的耗费时间,仔细针对比较慢的进行调优;对于tomcat或者weblogic,在高并发的情况下,用kill -3 <PID>,获得ThreadDump(HeapDump需要特殊的设置),看一下在高并发下,jvm的线程到底在干什么,仔细的分析可能对你有帮助。
如果在这些还没有改善的情况下,应当去想一想,硬件是否足够、配置是否合理等等系统级别的问题。
0 请登录后投票
   发表时间:2007-09-04  
performance tuning最重要的就是定位瓶颈在哪里,以及瓶颈是怎么产生的。从上面这么多讨论当中,还不能很清晰的看出来这一点。从davexin某贴的内容:

引用
我们现在的问题是apache和tomcat的能力不平衡,动态的内容压力太大,不是数据库的压力,我们的数据库oracle是RAC群集。性能很好,不用担心。


来看,似乎在说瓶颈在于tomcat并发承载能力不够,但为什么tomcat只能承担单机200个并发?当并发急剧上升的时候,tomcat在执行动态请求的时候,瓶颈在哪里?是哪部分程序,或者哪个环节首先导致tomcat失去响应的?在davexin描述的刀片硬件上面,tomcat上面如果跑的仅仅是最简单的jsp页面,在采用BEA JRockit JVM的情况下,500个并发也可以达到。

我的推测是瓶颈还是出在EJB远程方法调用上!

tomcat上面的java应用要通过EJB远程方法调用,来访问weblogic上面的无状态SessionBean,这样的远程方法调用一般都在100ms~500ms级别,或者更多。而如果没有远程方法调用,即使大量采用spring的动态反射,一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间,就会导致servlet线程被占用更多的时间,从而无法及时响应更多的后续请求。

如果这个推测是成立的话,那么我的建议就是既然你没有用到分布式事务,那么就干脆去掉EJB。weblogic也可以全部撤掉,业务层使用spring取代EJB,不要搞分布式架构,在每个tomcat实例上面部署一个完整的分层结构。

另外在高并发情况下,apache处理静态资源也很耗内存和CPU,可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。





0 请登录后投票
   发表时间:2007-09-04  
分布式并不可怕
对于读远大于写的应用,web端的缓存非常重要
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics