大型JavaWeb系统服务器选型问题探讨

大型 Java Web 系统服务器选型问题探讨 一位网友在 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 失败的几率很低 webweb 的优化的优化 将静态 图片独立使用不同的服务器 对于常态的静态文件 采用 E TAG 或者客户端缓存 google 很多 就是这样干的 对于热点的功能 考虑使用完全装载到内存 保证绝对的响应速度 对于需要频繁访问的 热点数据 采用集中缓存 多个可以采用负载均衡 减轻数据库的压力 对于几乎除二进制文件 都应该在 L4 上配置基于硬件的压缩方案 减少网络的流量 提高用户使用的感 知 网络问题网络问题 可以考虑采用镜像 多路网络接入 基于 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 1 基础配置优化基础配置优化 tomcat 6 tomcat 参数调优 JRockit JVM JVM 参数调优 Apache Squid 处理静态内容 2 2 业务层优化业务层优化 部分功能本地化 而不调 remote session bean 异步提交操作 JMS cache 热点数据 3 3 展示层优化展示层优化 动态页面发布为静态页面 Cache 部分动态页面内容 davexin 在调整了 Tomcat 配置后应验了 robbin 对 tomcat 配置问题的质疑 davexin 这样描述经过配置优 化以后的测试结果 经过测试 并发人数是可以达到像 robbin 所说的一样 能够在 600 人左右 如果压到并发 700 人 就有 15 左右的失败 虽然在调整上面参数之后 并发人数上去了 但是在同样的时间内所完成的事务数量下 降了 10 左右 并且响应时间延迟了