《关于个大型web系统架构设计和技术选型的讨论摘录》由会员分享，可在线阅读，更多相关《关于个大型web系统架构设计和技术选型的讨论摘录（6页珍藏版）》请在金锄头文库上搜索。
1、关于一个大型 web 系统架构设计和技术选型的讨论摘录2007 年 09 月 13 日 星期四 上午 09:36一、1、数据库压力问题 所有的压力最终都会反映到数据库方面，一定要对数据库有一个整体的规划。 可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用 rac、分区、分表等等策略，确保数据库能正常的进行交易。 2、事务问题 你采用了两种类型数据库，一个 SQL Server、一个 oracle，如果一个交易需要在两个数据库中操作，那么必须考虑到分布式事务，你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并
2、不保证数据的完整)，来避免分布式事务的问题，毕竟 commit 失败的几率很低。（某个超大型系统，有 3 套数据库，也是采用的延迟提交策略，避免分布式事务带来的对数据库过大的压力）。 看到了你在应用前端(weblogic EJB)采用了 F5，我个人不是很赞同这个方案，虽然 F5 是一个好的 L4 产品，也能基于第 7 层做负载均衡和容灾。但是一个有事务交易的 EJB，如果采用了这种方案，把不需要使用分布式事务的交易变成了分布式交易，试想，一个 web 如果在一个请求中，访问了后端两个 EJB，那么 L4 就会有可能把请求分发到不同的服务器上，没有对事务维持在一个服务器中，就不能使用本地事务。
3、同样，一个 web，访问后端一个请求，这个请求中需要 3 个 EJB，那么极有可能把这 3 个请求分发到不同的服务器，又造成了分布式事务。weblogic 是一个好的 J2EE 产品，对这种有事务关联的负载均衡，它会优先考虑采用一个服务器里面的应用，这样就采用了本地事务，提高了响应速度，减小了分布式事务对应用和数据库的压力。 3、web 的优化 我个人认为，一个商业的应用，硬件的投资可能不是主要的瓶颈，往往可维护性，可扩展性是最主要的问题。 没有必要采用不成熟的方案，要更多的使用成熟的方案，将静态、图片独立使用不同的服务器，对于常态的静态文件，采用 E-TAG 或者客户端缓存，google 很
4、多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。 对了，对于几乎除二进制文件，都应该在 L4 上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。 4、网络问题 你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，可以考虑采用镜像、多路网络接入、基于 DNS 的负载均衡。如果有足够的投资，可以采用 CDN(内容分发网)，减轻你的服务器压力。二、F5 的负载均衡 是必不可少的，他的每秒点击量能达到将近 30 万，并且它有会话的
5、粘性，只要是同一个 ip 发过来的请求，它就会把它分到同一台机器的，不用 担心分发错误的。现在的问题是 apache 和tomcat 的能力不平衡，动态的内容压力太大，不是数据库的压力，我们的数据库 oracle 是 RAC 群集。性能很好三、tomcat 为什么死掉？当时 CPU 或者内存的占用率是多少？看看其中 JVM 占用了多少？有没有 OOM的错误？不可能 20 台 tomcat 只能支撑 5000 的并发。以前做过单台的 resin 峰值到 3K 都是绰绰有余的。把缓存做好，减少动态查询四、1、F5 的使用 F5 不光可以做 web 的负载均衡，也可以做基于第 4 层的负载均衡。 比
6、如：银行接口，大部分基于 socket 通讯的，就可以在前面架设一套 F5 设备，将请求分发到不同的服务器上。 大部分使用 F5 都是在 web 层次上，如果使用基于源 IP 地址的策略，有很多客户端都是基于代理服务器，这个时候源 IP 地址是一样的，其实并没有把这些用户给分发到不同的服务器上，建议采用基于 cookie insert 的方式，采用 cookie 的会话保持策略，loadbalance 的算法，需要仔细的结合自己的应用的实际情况来设置。2、大并发的问题 现在你得到了一个大概的系统能承受的并发，但是还达不到系统的设计目标。 应该从应用的角度去分析这个问题，web 方面，通过工具(
7、httplook)，检查一下客户端发起的请求都是什么响应状态，如果看到很多 304 请求状态，你需要优化你的 url 缓存，看一下每个 url 的耗费时间，仔细针对比较慢的进行调优；对于 tomcat 或者 weblogic，在高并发的情况下，用 kill -3 ，获得ThreadDump(HeapDump 需要特殊的设置)，看一下在高并发下，jvm 的线程到底在干什么，仔细的分析可能对你有帮助。 如果在这些还没有改善的情况下，应当去想一想，硬件是否足够、配置是否合理等等系统级别的问题。五、似乎在说瓶颈在于 tomcat 并发承载能力不够，但为什么 tomcat 只能承担单机 200 个并发？
8、当并发急剧上升的时候，tomcat 在执行动态请求的时候，瓶颈在哪里？是哪部分程序，或者哪个环节首先导致tomcat 失去响应的？在 davexin 描述的刀片硬件上面，tomcat 上面如果跑的仅仅是最简单的 jsp 页面，在采用 BEA JRockit JVM 的情况下，500 个并发也可以达到。我的推测是瓶颈还是出在 EJB 远程方法调用上！tomcat 上面的 java 应用要通过 EJB 远程方法调用，来访问 weblogic 上面的无状态 SessionBean，这样的远程方法调用一般都在 100ms500ms 级别，或者更多。而如果没有远程方法调用，即使大量采用spring 的动
9、态反射，一次完整的 web 请求处理在本地 JVM 内部的完成时间一般也不过 20ms 而已。一次 web 请求需要过长的执行时间，就会导致 servlet 线程被占用更多的时间，从而无法及时响应更多的后续请求。如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。weblogic 也可以全部撤掉，业务层使用 spring 取代 EJB，不要搞分布式架构，在每个 tomcat 实例上面部署一个完整的分层结构。另外在高并发情况下，apache 处理静态资源也很耗内存和 CPU，可以考虑用轻量级 web server 如lighttpd/litespeed/ngi
10、nx 取代之。六、tomcat 之所以并发低很可能是由于 remote session bean 造成的，remote session bean 又一次被滥用了，在楼主的这种业务情况下，web 层和 service 层根本不需要分开，象楼主这样分开带来就是一访问业务层就带来长时间的远程请求，确实导致 tomcat 上 servlet 资源释放的问题。那么 remote session bean 应该被用在什么地方呢，without ejb 上有写到金融系统常用 ejb。我把他的这句话延伸一下，也就是说当业务的运行时间远超过远程调用的时间时，我们就可以用 remote session bean
11、来把这个业务分离出去。而楼主的系统中没有这种业务情况。所以使用 remote session bean 应该来说是一个错误的选择，不过这个错误的选择带来的危害被大量的硬件所掩盖，带来的是成本的提高。而性能上还不如 slsb。所以我觉得如果要改架构最便捷的方法是使用 slsb，把 remote session bean 去掉。这样改造的成本比较低，如果换成 spring+hibernate 成本就高得多了。也就是说可以 struts+Bean+DAO+helper，然后把 weblogic 作 cluster，任意一个 node 上都部署相同的应用。也就是水平扩展，理论上来讲当性能不满足要求时添
12、加 node 就行了，如果能做成农场就更加方便了。当然即使非农场也没有关系，可以用现在在使用的 stick 分发。这样的改造之所以方便是因为把 remote session bean 改成 slsb 是很容易的，而且团队里的人估计对 ejb 都更加熟悉一点，成本会比较低一点七、近段时间正在做购买新硬件和新软件的预算，公司高层准备买 weblogic10 和 oracle 10g，所以请了bea 公司的人员和我一块做测试，经过近几天的测试，测试一下新的系统指标 1 万个并发，需要多少软件和多少硬件能够支撑，已经测试了不同的组合方式，有了不同的结果，分别如下：1。1 台 weblogic10 能支
13、持 900 个用户并发（没有用 ejb），平均响应时间 10 秒。2。1 台 weblogic10 Express（相当于 1 台 tomcat，用于发布 jsp 应用）加 1 台 weblogic10（发布ejb 应用），能支持 1000 个并发用户，平均响应时间 9 秒，由于本人使用的 loadRunner 最多支持1000 个 web 并发，虽然此时 weblogic 没有任何错误，但是没办法再向上压用户，所以不知道最高能支撑多少个并发用户，很遗憾。3。1 台 weblogic8， 能支持 900 个用户并发（没有用 ejb），平均响应时间 11 秒。但是没有weblogic10 在同样
14、时间内处理的交易数量多。可以判定性能不能 weblogic10。4。1 台 tomcat4.1 加 1 台 weblogic8，只能支持 350 个并发用户，tomcat 就连结超时，说明此种结构瓶颈在 tomcat。5。1 台 tomcat6.14 加 1 台 weblogic8，还不如方案 4，tomcat 结超时更多，说明此种结构瓶颈在tomcat。由于还没有看 tomcat6.14 的调优资料。所以还请高手给建议。6。1 台 tomcat4.1 加 1 台 weblogic10，性能同样不佳，问题出现在 tomcat 性能跟不上。7。1 台 tomcat6.14 加 1 台 weblo
15、gic10，性能同样不佳，问题出现在 tomcat 性能跟不上。明天还要做一个 weblogic10 cluster 测试，等有了测试结果，再根大家交流。以上测试机器都为 linux as4 操作系统，2cpu + 2G 内存，发现 cpu 利用率最高占 45%，一般就在10%左右，内存可以用到 1.5G。 loadRunner 机器为 2cpu + 2G 内存，window server 2003 操作系统。有以上的结果，bea 公司人员建议购买 16-20cpu 的 licens。机器购买 4cpu + 8G 内存机器 4-6 台。前端 tomcat 增加到 50 台。由于根据以前的宕机记
16、录，主要表现在 tomcat 层，个别高峰时候也出现在 F5。故不敢轻易的舍弃无状态session bean。由于 tomcat 做了大部分的业务，只有需要数据库的时候才调用 weblogic 中间件，由于weblogic 的价格还是比较昂贵的，公司以前购买的 weblogic licens 数量限制。所以还不能把所有的tomcat 换成 weblogic。如果有 20 台 weblogic 的 licens，我也就不担心 1 万个并发了。八、坦白说我还从来没有听说过大规模互联网应用使用 EJB 的先例。为什么大规模互联网应用不能用 EJB，其实就是因为 EJB 性能太差，用了 EJB 几乎必然出现性能障碍。阿里巴巴和淘宝网那是每天多少亿 PV 的电子商务网站了，其实也就是用 JBoss 而已，而且也只是用其 web 容器(JBoss 的 web 容器就是 tomcat)，所以本质上还是在用 tomcat。今年年初，RedHat 在深圳的 HW 大客户在内部做过性能对比评测，JBoss4 vs WebLogic 9，在 web容器一项的评测当中，JBoss4 胜出。这个结果并
