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

是指每秒的并发

不会采用 hibernate的，最多考虑一下spring，ejb还是不会抛弃的，因为我们的数据库对数据库要求非常高的，机会每个sql语句都经过优化的，况且，hibernate我们也不能保证使用之后会比现在的更好。改造系统的原因，是因为业务的增加，用户的增加，还有公司高层对现有的系统 提出更高要求和目标，就是并发达到1万/秒

建议一下：
1、数据库压力问题
所有的压力最终都会反映到数据库方面，一定要对数据库有一个整体的规划。
可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。
2、事务问题
你采用了两种类型数据库，一个SQL Server、一个oracle，如果一个交易需要在两个数据库中操作，那么必须考虑到分布式事务，你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。（某个超大型系统，有3套数据库，也是采用的延迟提交策略，避免分布式事务带来的对数据库过大的压力）。
看到了你在应用前端(weblogic EJB)采用了F5，我个人不是很赞同这个方案，虽然F5是一个好的L4产品，也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB，如果采用了这种方案，把不需要使用分布式事务的交易变成了分布式交易，试想，一个web如果在一个请求中，访问了后端两个EJB，那么L4就会有可能把请求分发到不同的服务器上，没有对事务维持在一个服务器中，就不能使用本地事务。同样，一个web，访问后端一个请求，这个请求中需要3个EJB，那么极有可能把这3个请求分发到不同的服务器，又造成了分布式事务。weblogic是一个好的J2EE产品，对这种有事务关联的负载均衡，它会优先考虑采用一个服务器里面的应用，这样就采用了本地事务，提高了响应速度，减小了分布式事务对应用和数据库的压力。
3、web的优化
我个人认为，一个商业的应用，硬件的投资可能不是主要的瓶颈，往往可维护性，可扩展性是最主要的问题。
没有必要采用不成熟的方案，要更多的使用成熟的方案，将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存，google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。
对了，对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。
4、网络问题
你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。

搂主把这些一次发出来多好。。看得真累
当然，如果数据库版本，操作系统版本，硬件具体情况都发出来可以参考的东西就更多了，也就会有更好的
方案。



从业务分析，网游代理，那么用户玩游戏的时候和你们的服务没有关系把？应该直接与游戏服务器交互了。
冲值，激活显然可以避开分布式事务这个问题，为什么不采用延迟处理呢？ 如果都是oracle可以用oracle的job
如果不是，可以编写一个传输数据的程序，定时(n分钟or n秒)运行一次。我想1分钟的延迟，用户应该几乎感受不到。
避开分布式事务可以提高很多性能。遇到项目，确实需要问自己，真的需要分布式么？有些看似分布式的项目，其实
都可以避开的。我们的业务就是看似分布式，结果我们没有用分布式事务就处理了。
我感觉搞出分布式数据库主要还是为了买中间件产品。除非对时间要求真的很高！

你的数据库结构可能有问题，如果9000万用户数据，那么应该考虑分区、移出非活动数据等方式减小表的数据，
这样才能提高性能。大部分系统性能瓶颈都在数据库上，这个地方需要好好优化。

刀片机 2G内存支持 250-400个并发应该差不多了，再多要排队的。Weblogic跑的是什么机器？如果Weblogic机器够
强，完全可以把web应用放在weblogic上，weblogic作集群。

还是从业务上来考虑，这1万人并发究竟在干啥？ 1万人每秒都在注册？都在对数据库操作？不会把？因此，把业务
分离：静态页面访问类业务，数据库操作类业务分离，我想不要20台服务器就能解决了。

[cauherk的回复就很好]

很多朋友都提到了延迟提交处理,这确实是个不错的建议!



当有一款新游戏上线时,确实会出现一秒有几千人并发访问的情况.

为什么这么多人反对这样做呢？
这样做哪里不好啊．
反对的人你自己给个好架构来.

只是搂住没有把这个架构描述好而已，难道这就是你们反对这个架构的理由！！

说明一下：现在的压力不在数据库层，数据库是2种，oracle和sql server，我们也没有采用分布式的事务，因为也是发现分布式会对数据库造成很大的压力，包括我们银行接口部分，都是有特殊的处理方案，根据不同的业务有不同的处理方法，这点大家不用担心。
还有就是F5的负载均衡 是必不可少的，他的每秒点击量能达到将近30万，并且它有会话的 粘性，只要是同一个ip发过来的请求，它就会把它分到同一台机器的，不用 担心分发错误的。

不过也谢谢你的建议，分析的很到位。

我们现在的问题是apache和tomcat的能力不平衡，动态的内容压力太大，不是数据库的压力，我们的数据库
oracle是RAC群集。性能很好，不用担心。

我们的压力不在数据库层，在web层和F5。 当高峰的时候 ，F5也被点死了，就是每秒点击超过30万，web动态部分根本承受不了。根据我们程序记录，20台web最多承受5000个并发，如果再多，tomcat就不响应了。就像死了一样。

几千人访问都需要更新数据库么？ LZ说压力不在数据库上，那么几千人访问的压力就在web层了？
是这样么？不知道理解得对不对。

tomcat为什么死掉？当时CPU或者内存的占用率是多少？看看其中JVM占用了多少？有没有OOM的错误？不可能20台tomcat只能支撑5000的并发。。。以前做过单台的resin峰值到3K都是绰绰有余的。。。

BTW：国内还有这么火的游戏运营商么？我觉得只有WEB游戏才会达到楼主所描述的峰值访问，火一点的网游很难到达这种情况，总不会是网易吧，但是网易用了100多台服务器……