大型Java Web系统选型问题探讨_Java_田乐

如何用AI技术降噪？ QCon 广州“音视频架构实践”专场给你答案！了解详情 



 写点什么

一位 ID 是 jackson1225 的网友在 JavaEye 询问了一个大型 Web 系统的架构和部署选型问题，希望能提高现有的基于 Java 的 Web 应用的服务能力。由于架构模式和部署调优一直是 Java 社区的热门话题，这个问题引发了很多热心网友的讨论，其中一些意见对其它大型 Web 项目也有很好的指导意义。在讨论之初 jackson1225 这样描述了当前的应用的架构和部署方案：

目前系统架构如下:

web 层采用 struts+tomcat 实现，整个系统采用 20 多台 web 服务器，其负载均衡采用硬件 F5 来实现；

中间层采用无状态会话 Bean+DAO+helper 类来实现，共 3 台 weblogic 服务器，部署有多个 EJB，其负载均衡也采用 F5 来实现；

数据库层的操作是自己写的通用类实现的，两台 ORACLE 数据库服务器，分别存放用户信息和业务数据；一台 SQL SERVER 数据库，是第三方的业务数据信息；

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

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

这样的架构其实很多公司都在使用，因为 Struts 和 Tomcat 分别是最流行的 Java Web MVC 框架和 Servlet 容器，而 F5 公司的负载均衡是横向扩展常见的解决方案（例如配置 session sticky 方案）。由于这个系统中有跨数据源的事务，所以使用 Weblogic Server EJB 容器和支持两阶段提交的数据库驱动就可以保证跨数据源的事物完整性（当然，容器管理的分布式事务并非是唯一和最优的解决方案）。

但是随着 Rod Johnson 重量级的著作《J2EE Development without EJB》和其中的 Spring 框架的流行，轻量级框架和轻量级容器的概念已经深入人心。所以对于 jackson1225 提出的这个场景，大多数网友都提出了置疑，认为这个系统滥用了技术，完全是在浪费钱。网友们大都认为 SLSB（无状态会话 Bean）完全没有必要出现在这个场景中，认为 SLSB 通过远程接口访问本地资源会有很大的性能开销，这种观点也是 Rod johnson 在 without EJB 中批判 EJB 2.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 容器单纯的并发支持能力上提出改进方案，而是提出了对于类似的应用的一些通用的改进提示，这里摘要一下：

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

事务问题要在两个数据库中操作，那么必须考虑到分布式事务。你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略 (并不保证数据的完整)，来避免分布式事务的问题，毕竟 commit 失败的几率很低。

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 发表了自己的意见，将话题引回了这个项目的架构本身：

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

我的推测是瓶颈还是出在 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 取代之。

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

坦白说我还从来没有听说过大规模互联网应用使用 EJB 的先例。为什么大规模互联网应用不能用 EJB，其实就是因为 EJB 性能太差，用了 EJB 几乎必然出现性能障碍。

web 容器的性能说到底无非就是 Servlet 线程调度能力而已，Tomcat 不像 WebLogic 那样附加 n 多管理功能，跑得快很正常。对比测试一下 WebLogic 的数据库连接池和 C3P0 连接池的性能也会发现类似的结论，C3P0 可要比 WebLogic 的连接池快好几倍了。这不是说 WebLogic 性能不好，只不过 weblogic 要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。

以我的经验来判断，使用 tomcat5.5 以上的版本，配置 apr 支持，进行必要的 tuning，使用 BEA JRockit JVM 的话，在你们目前的刀片上面，支撑 500 个并发完全是可以做到的。结合你们目前 20 个刀片的硬件，那么达到 1 万并发是没问题的。当然这样做的前提是必须扔掉 EJB，并置 web 层和业务层在同一个 JVM 内部。

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

引用： > 2。1 台 weblogic10 Express（相当于 1 台 tomcat，用于发布 jsp 应用）加 1 台 weblogic10（发布 ejb 应用），能支持 1000 个并发用户…

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

这说明瓶颈还不在 EJB 远程调用上，但是问题已经逐渐清楚了。为什么 weblogic 充当 web 容器发起远程 EJB 调用的时候可以支撑 1000 个并发，但是 tomcat 只能到 350 个？只有两个可能的原因：

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

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

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

1. 基础配置优化

tomcat 6？ tomcat 参数调优?
JRockit JVM? JVM 参数调优？
Apache+Squid 处理静态内容？

2. 业务层优化

部分功能本地化，而不调 remote session bean?
异步提交操作,JMS？
cache 热点数据？

3. 展示层优化

动态页面发布为静态页面？
Cache 部分动态页面内容？

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

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

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

在讨论中还有一些小插曲，如 davexin 和江南白衣讨论了 JRocket 的实时（Realtime）版本是否可以提升 Servlet 容器的相应能力，答案是不可以。还有 ID 为 mfc42d 的网友从 Servlet 容器的并发支持能力引申到了 Java 的线程调度能力和 NIO 对 Servelet 容器的意义，他推荐了自己的两篇不错的 blog“ java 的线程实现”和“ java 进程使用的最大内存的数值”，blog 文章里面从 JVM 源码级别分析了 Java 的线程支持能力，面临 JVM 性能调优问题的网友可以认真阅读一下。