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

不是说ebay是用的ejb么？

代价太大了，大的离谱。

WEB层为什么要和service进行远程调用？这个问题不解决，成本永远要多付出50%以上，保守估计


-------这些人好黑啊。。。。。

20cpulicens加上他们的service,support=500万RMB
4cpu + 8G 6台=60万
n*oracle10g=50万

。。。。

这个代价跟04年ebay中国的硬件代价差不多，当时的的PV可以达到2000万

网站类的运用，通常是并发大，交易少。大多数网站都是使用增多应用服务器，使用开源产品resin/tomcat来做的。
很少听说网站类的使用tomcat做前端。
楼上的8000说的对：weblogic永远是对于银行，证券，电信的行业所准备。比如我们现在用的系统，weblogic跑在32CPU的IBM小型机上。
至于ejb，可以很明确的说，那玩意降低性能，调试麻烦，没什么好处。
现在我们做的这个项目非常庞大，金额接近1亿，IBM做的架构，也抛弃ejb，使用spring+hibernate开源方案

如果LZ只是支持用户信息注册，充值这些简单业务的话，根本用不着这么兴师动众
原来的系统优化下完全可以的。。。
主要分离静态和动态的数据就好了（当然这种说法不准确，大致意思）想个人信息，充值信息，一个人3天难得动一回的，数据量再多一倍无所谓；如果提供了论坛等等一些更新比较快的服务的话，和其他数据分开就好了

并发不是简单的配置能说明的，还看你应用复杂读
不过，你们的配置如果U>=2的话，应用又比较简单的话，一定有问题
我以前测试过单U+1G和应用比较简单的状况下，Tomcat可以200多接近300的并发
其实这个问题很复杂。。需要具体的分析

经过今天修改tomcat的参数，修改如下：
    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="8080" enableLookups="false" redirectPort="8443"
               acceptCount="500" maxProcessors="500" minProcessors="500"
               maxSpareProcessors="200"
               connectionTimeout="20000"
               useURIValidationHack="false" disableUploadTimeout="true" />
经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。谢谢robbin的建议。
   由于本人使用的loadRunner 能支持的独立client数量在100个，所以没办法对ejb进行单独的压力测试。因为我在对前段应用调用ejb时，最多并发用户已经达到1000个，但是通过监控weblogic10中发布的ejb应用和连接池，发现ejb应用等待数量为0，但是连接池中最多有60个活动连接，有7个连接在等待，因为此时设置的weblogic连接池最大数量是60，后来对连接池数量进行增大到160个，再次进行测试，发现性能反而不如把连接池数量调为60个的时候。问起bea的人，他们也说不清楚原因。
   同时对他们所提供的一种更好的jvm进行测试，jvm的名字是 RealTime.发现性能并没有太大改善。
   我们现在的系统已经作了很多的缓存，有全局的，有局部的，都是放到内存中的HashMap，静态的页面都是放在apache上的，不过没有使用 apr， 接下来如果有时间，会测试一下这个咚咚，。
   che前面是F5负载均衡器，在apache后面是tomcat，tomcat在公网上，然后通过内网网卡访问weblogic，weblogic才能访问数据库，tomcat不能直接访问数据库的，由于以前的网络结构的原因，也有安全的原因，公司还有部分服务器在北京（无线事业部）和广州（老系统，以后会逐渐迁移到上海），虽然现在也有其他的安全方案可以把tomcat放在内网，去掉weblogic，但是这种改变是需要时间的，也要考虑平稳过渡，所以还请各位理解。至于购买weblogic，公司也是有自己的考虑的。因为以前就是运行在weblogic上的，如果现在不用了，如果出了问题，就很难办了。

既然你用tomcat4都可以达到并发600，那tomcat5.5在同样环境下经过调优完全可以达到1000，看来问题还是在于你们tomcat没有配置好。

ebay的CTO在QCon 2007上有份PPT，好像说ebay的主架构只用了J2EE最基本的功能，碰都没碰EJB这类高级货啊，当然在某些支线应用上可能会用了。



Realtime版只是把垃圾收集引起的暂停时间讲的更低而已（30ms以内，而且需要你配JVM参数才会有这个效果)，对吞吐量并没有帮助：）

江南白衣，讲的很对，RealTime是对垃圾回收做了优化，目标是使响应时间变短，但是要在长时间运行情况下才能体现它的性能，由于时间紧，昨天我们只运行了半个小时左右，所以并没有体现出他的优越性能。也是一种遗憾吧，我想既然bea敢拿出来买，她如果没有那金刚钻，也不敢拿出来招摇了。

是的，如果调整参数，可以达到并发人数达到1000以上，但是通过对比同样压力下的weblogic和tomcat，发现tomcat的响应时间都比weblogic长，并且tomcat的cpu的占用率达到45%-60%，而同样的压力下weblogic的cpu占用只有3%-5%。内存都是2G都用了97%，说明主要差别表现在cpu和相应时间上，我没有做tomcat 1000人并发测试，但是从以前600人并发的响应时间判断，我觉得响应时间可能会超过15秒。所以从综合各方面性能指标考虑，我觉得要找出一个响应时间，并发人数，完成交易数量3方面考虑折中，找出一个满足应用响应时间和并发用户的折中吧，如果是并发交易量比较大的应用，我想应该减少并发用户，提高单位时间内交易数量来满足应用需求吧。