大型Java Web项目的架构和部署问题Word文件下载.docx

大型Java Web项目的架构和部署问题Word文件下载.docx

《大型Java Web项目的架构和部署问题Word文件下载.docx》由会员分享，可在线阅读，更多相关《大型Java Web项目的架构和部署问题Word文件下载.docx（12页珍藏版）》请在冰点文库上搜索。

一台SQLSERVER数据库，是第三方的业务数据信息；

web层调用EJB远程接口来访问中间件层。

web层首先通过一个XML配置文件中配置的EJB接口信息来调用相应的EJB远程接口；

该系统中一次操作涉及到两个ORACLE库以及一个SQLSERVER库的访问和操作，即有三个数据库连接，在一个事务中完成。

这样的架构其实很多公司都在使用，因为Struts和Tomcat分别是最流行的JavaWebMVC框架和Servlet容器，而F5公司的负载均衡是横向扩展常见的解决方案（例如配置sessionsticky方案）。

由于这个系统中有跨数据源的事务，所以使用WeblogicServerEJB容器和支持两阶段提交的数据库驱动就可以保证跨数据源的事物完整性（当然，容器管理的分布式事务并非是唯一和最优的解决方案）。

但是随着RodJohnson重量级的著作《J2EEDevelopmentwithoutEJB》和其中的Spring框架的流行，轻量级框架和轻量级容器的概念已经深入人心。

所以对于jackson1225提出的这个场景，大多数网友都提出了置疑，认为这个系统滥用了技术，完全是在浪费钱。

网友们大都认为SLSB（无状态会话Bean）完全没有必要出现在这个场景中，认为SLSB通过远程接口访问本地资源会有很大的性能开销，这种观点也是Rodjohnson在withoutEJB中批判EJB2.x中的一大反模式。

由于JavaEE是一个以模式见长的解决方案，模式和架构在JavaEE中占有很重要的地位，所以很多业内专家也都警惕“反模式（Anti-patterns）”的出现。

对于上面所述的方案是否是反模式，jackson1225马上站出来申辩：

我们项目就是把EJB作为一个Facade，只是提供给WEB层调用的远程接口，而且只用了无状态会话Bean，所以性能上还可以的。

这个解释很快得到了一些网友的认可，但是大家很快意识到架构的好坏决定于是否能够满足用户的需求，davexin（可能是jackson1225的同事）描述了这个系统的用户和并发情况：

现在有用户4000万，马上要和另一个公司的会员系统合并，加起来一共有9000万用户。

数据量单表中有一亿条以上的数据。

这是基本的情况，其实我觉得现在的架构还是可以的，现在支持的并发大概5000并发用户左右，接下来会进行系统改造，目标支持1万个并发用户。

具体的并发量公布后又有网友置疑这个数据，认为这个系统的Servlet容器支持的并发数太小，怀疑是否配置不够优化。

davexin又补充了该项目的服务器配置：

系统前端tomcat都是用的刀片，配置在2G内存，cpu大概在2.0G，每台机器也就支持250-400个并发，再多的话，就会相应时间非常的常，超过20秒，失去了意义，所以我们才得出这样的结论的。

一位ID是cauherk的网友提出了比较中肯的意见，他没有从Web容器单纯的并发支持能力上提出改进方案，而是提出了对于类似的应用的一些通用的改进提示，这里摘要一下：

1.数据库压力问题

可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。

2.事务问题

要在两个数据库中操作，那么必须考虑到分布式事务。

你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。

推荐你采用延迟提交的策略（并不保证数据的完整），来避免分布式事务的问题，毕竟commit失败的几率很低。

3.web的优化

将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存，google很多就是这样干的。

对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存（多个可以采用负载均衡），减轻数据库的压力。

对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。

提高用户使用的感知。

4.网络问题

可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。

如果有足够的投资，可以采用CDN（内容分发网），减轻你的服务器压力。

cauherk的这个分析比较到位，其中ETags的方案是最近的一个热点，InfoQ的“使用ETags减少Web应用带宽和负载”里面对这种方案有很详细的介绍。

一般以数据库为中心的Web应用的性能瓶颈都在数据库上，所以cauherk把数据库和事务问题放到了前两位来讨论。

但是davexin解释在所讨论的这个项目中数据库并非瓶颈：

我们的压力不在数据库层，在web层和F5。

当高峰的时候，F5也被点死了，就是每秒点击超过30万，web动态部分根本承受不了。

根据我们程序记录，20台web最多承受5000个并发，如果再多，tomcat就不响应了。

就像死了一样。

这个回复让接下来的讨论都集中于Web容器的性能优化，但是JavaEye站长robbin发表了自己的意见，将话题引回了这个项目的架构本身：

performancetuning最重要的就是定位瓶颈在哪里，以及瓶颈是怎么产生的。

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

tomcat上面的java应用要通过EJB远程方法调用，来访问weblogic上面的无状态SessionBean，这样的远程方法调用一般都在100ms~500ms级别，或者更多。

而如果没有远程方法调用，即使大量采用spring的动态反射，一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。

一次web请求需要过长的执行时间，就会导致servlet线程被占用更多的时间，从而无法及时响应更多的后续请求。

如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。

weblogic也可以全部撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面部署一个完整的分层结构。

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

robbin的推断得到了网友们的支持，davexin也认同robbin的看法，但是他解释说公司认为放弃SLSB存在风险，所以公司倾向于通过将Tomcat替换为WeblogicServer10来提升系统的用户支撑能力。

robbin则马上批评了这种做法：

坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。

为什么大规模互联网应用不能用EJB，其实就是因为EJB性能太差，用了EJB几乎必然出现性能障碍。

web容器的性能说到底无非就是Servlet线程调度能力而已，Tomcat不像WebLogic那样附加n多管理功能，跑得快很正常。

对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论，C3P0可要比WebLogic的连接池快好几倍了。

这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。

以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEAJRockitJVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。

结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。

当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。

接下来robbin还针对davexin对话题中的应用分别在tomcat和weblogic上的测试数据进行了分析：

引用：

2。

1台weblogic10Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户......

......

4。

1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。

这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。

为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？

只有两个可能的原因：

1.你的tomcat没有配置好，严重影响了性能表现

2.tomcat和weblogic之间的接口出了问题

接着springside项目发起者江南白衣也提出了一个总体的优化指导：

1.基础配置优化

tomcat6？

tomcat参数调优?

JRockitJVM?

JVM参数调优？

Apache+Squid处理静态内容？

2.业务层优化

部分功能本地化，而不调remotesessionbean?

异步提交操作,JMS？

cache热点数据？

3.展示层优化

动态页面发布为静态页面？

Cache部分动态页面内容？

davexin在调整了Tomcat配置后应验了robbin对tomcat配置问题的质疑，davexin这样描述经过配置优化以后的测试结果：

经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。

至此这个话题有了一个比较好的结果。

这个话题并非完全针对一个具体的项目才有意义，更重要的是在分析和讨论问题的过程中网友们解决问题的思路，尤其是cauherk、robbin、江南白衣等几位网友提出的意见可以让广大JavaWeb项目开发者了解到中、大型项目所需要考虑的架构和部署所需要考虑的关键问题，也消除了很多人对轻量Servlet容器与EJB容器性能的一些误解。

在讨论中还有一些小插曲，如davexin和江南白衣讨论了JRocket的实时（Realtime）版本是否可以提升Servlet容器的相应能力，答案是不可以。

还有ID为mfc42d的网友从Servlet容器的并发支持能力引申到了Java的线程调度能力和NIO对Servelet容器的意义，他推荐了自己的两篇不错的blog“java的线程实现”和“java进程使用的最大内存的数值”，blog文章里面从JVM源码级别分析了Java的线程支持能力，面临JVM性能调优问题的网友可以认真阅读一下。

的343243243243243242222222222