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

目前系统架构如下:
  1.web层采用struts+tomcat实现,整个系统采用20多台web服务器,其负载均衡采用硬件F5来实现;
  2.中间层采用无状态会话Bean+DAO+helper类来实现,共3台weblogic服务器,部署有多个EJB,其负载均衡也采用F5来实现;
  3.数据库层的操作是自己写的通用类实现的,两台ORACLE数据库服务器，分别存放用户信息和业务数据;一台SQL SERVER数据库,是第三方的业务数据信息;
  web层调用EJB远程接口来访问中间件层.web层首先通过一个XML配置文件中配置的EJB接口信息来调用相应的EJB远程接口;
  该系统中一次操作涉及到两个ORACLE库以及一个SQL SERVER库的访问和操作,即有三个数据库连接,在一个事务中完成.

  以上的描述不知道是不是足够清楚,目前想采用业界流行的一些框架来重新架构整个系统,请各位高手分析一下,这样的系统能不能采用struts+spring+hibernate框架来实现,如果可以的话，其中的多个数据库的连接、事务控制、负载均衡都如何实现，或者有其他更好的技术来架构系统？谢谢！

评论

36 楼 welllove53 2007-09-03  

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

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

35 楼 jackson1225 2007-09-03  

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

引用

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

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

34 楼 tobato 2007-09-03  

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

引用

我们的项目确实需要分布式的.行业是网游代理，一旦有新游戏上线后，
就会有数千万级的用户访问量,目前的系统在这种情况运行就很慢了.
系统需要在 ORACLE数据库中写入业务数据后，还需要在游戏数据库里写入数据,
而游戏数据库一般都是SQL SERVER,所有的操作都需要在一个事务中完成.


具体业务:网游代理业务,系统要为玩家提供会员注册,游戏激活,充值等功能;
这些操作都是首先要记录玩家的注册,激活以及充值记录,然后要在游戏数据库中加入相应的信息.
如充值,首先记录充值日志,然后在游戏数据库中加入充值的游戏点.涉及到一次操作有多个数据库连接的事务控制问题.
访问量:一旦新游戏上线,应该在数千万级的用户量;平时没什么问题的.
人力:开发人员8人左右.

我替上面的兄弟回答一下具体的用户量和数据量吧，现在有用户4000万，马上要和另一个公司的会员系统合并，
加起来一共有9000万用户。数据量单表中有一亿条以上的数据。
这是基本的情况，其实我觉得现在的架构还是可以的，现在支持 的并发大概5000并发用户左右，
接下来会进行系统改造，目标支持1万个并发用户。准备采用 sna的设计方式。


你去测试一下吧，我们系统前端tomcat都是用的刀片，配置在2G内存，cpu大概在2.0G，每台机器也就支持
250-400个并发，再多的话，就会相应时间非常的常，超过20秒，
失去了意义 ，所以我们才得出这样的结论的。测试时使用的loadRunner8.0,不信的话，请你自己去测试一下吧，
不知道你的并发量4000是怎么得到的？还请解释一下。

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

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

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

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

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

[cauherk的回复就很好]

33 楼 cauherk 2007-09-02  

建议一下：
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(内容分发网)，减轻你的服务器压力。

32 楼 rockwang 2007-09-02  

投资人真有钱呀

31 楼 davexin 2007-09-02  

taelons 写道

为什么要"采用业界流行的一些框架来重新架构整个系统"?目前的已经很好,再用spring+hibernate纯属多余

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

30 楼 davexin 2007-09-02  

xzcgeorge 写道

rich 写道

不明白，区区5000-10000并发用户，为何要20台web server？
按道理一台web server怎么也可以支持2000并发用户吧？
LZ的 web应用有什么特别之处吗？以至于一台web server只能支持250并发用户

能否给个并发的定义呀?
5000-1000并发用户是指每秒钟,还是第分钟呀?

是指每秒的并发

29 楼 davexin 2007-09-02  

rich 写道

不明白，区区5000-10000并发用户，为何要20台web server？
按道理一台web server怎么也可以支持2000并发用户吧？
LZ的 web应用有什么特别之处吗？以至于一台web server只能支持250并发用户

不知道你的并发量2000是怎么得到的？还请解释一下。

28 楼 davexin 2007-09-02  

rich 写道

不明白，区区5000-10000并发用户，为何要20台web server？
按道理一台web server怎么也可以支持2000并发用户吧？
LZ的 web应用有什么特别之处吗？以至于一台web server只能支持250并发用户

你去测试一下吧，我们系统前端tomcat都是用的刀片，配置在2G内存，cpu大概在2.0G，每台机器也就支持
250-400个并发，再多的话，就会相应时间非常的常，超过20秒，失去了意义 ，所以我们才得出这样的结论的。测试时使用的loadRunner8.0,不信的话，请你自己去测试一下吧，不知道你的并发量4000是怎么得到的？还请解释一下。

27 楼 rich 2007-09-01  

不明白，区区5000-10000并发用户，为何要20台web server？
按道理一台web server怎么也可以支持2000并发用户吧？
LZ的 web应用有什么特别之处吗？以至于一台web server只能支持250并发用户

26 楼 taelons 2007-09-01  

为什么要"采用业界流行的一些框架来重新架构整个系统"?目前的已经很好,再用spring+hibernate纯属多余

25 楼 chenqj 2007-09-01  

9000万用户只产生1亿条数据，似乎活跃用户不多啊

24 楼 davexin 2007-09-01  

我替上面的兄弟回答一下具体的用户量和数据量吧，现在有用户4000万，马上要和另一个公司的会员系统合并，加起来一共有9000万用户。数据量单表中有 一亿条以上的数据。这是基本的情况，其实我觉得现在的架构还是可以的，现在支持 的 并发大概5000并发用户左右，接下来会进行系统改造，目标支持1万个并发用户。准备采用 sna的设计方式。

23 楼 chenqj 2007-08-31  

我觉得楼主的架构挺好的，水平的集群和垂直的分布相结合lo

22 楼 rtdb 2007-08-31  

业务简单，虽说并发高，但业务间没有交叉关系，
多上几个服务器就是了。

21 楼 jackson1225 2007-08-30  

引用

Robbin又不是神，他说的只是一种大趋势和较先进的设计方法。问题是你们的具体业务，访问量，甚至人力等等才是决定架构的关键。这些说出来才容易分析。

具体业务:网游代理业务,系统要为玩家提供会员注册,游戏激活,充值等功能;这些操作都是首先要记录玩家的注册,激活以及充值记录,然后要在游戏数据库中加入相应的信息.如充值,首先记录充值日志,然后在游戏数据库中加入充值的游戏点.涉及到一次操作有多个数据库连接的事务控制问题.
访问量:一旦新游戏上线,应该在数千万级的用户量;平时没什么问题的.
人力:开发人员8人左右.

20 楼 myreligion 2007-08-30  

Robbin又不是神，他说的只是一种大趋势和较先进的设计方法。问题是你们的具体业务，访问量，甚至人力等等才是决定架构的关键。这些说出来才容易分析。

19 楼 jackson1225 2007-08-30  

我只是想让大家讨论一下这种大访问量WEB系统中需要用到的集群,事务控制,缓存等关键技术以及比较好的架构,对于目前的项目公司肯定不会让我练手了啊!

前几天看到Robbin提到过大访问量的网站尽量采用SNA架构,不知各位用到过该架构没有，本人只是查看了一下,略有了解,既然Robbin大师都说了，应该是不错的吧

18 楼 jackson1225 2007-08-30  

引用

呵呵，干脆找我跟你们做就好了，这么好的资源就这样被浪费了，太可惜了

能谈谈你的架构吗?

17 楼 jackson1225 2007-08-30  

tobato写道

   
rtdb 写道
没有用户量，数据量等基本信息，谈什么架构设计和技术选型 ?
 



严重同意！还有应用行业。



现在看LZ的描述好像是N年前中了EJB毒的"严格"分层架构。需要使用分布式计算的系统好像不多.

我们的项目确实需要分布式的.行业是网游代理，一旦有新游戏上线后，就会有数千万级的用户访问量,目前的系统在这种情况运行就很慢了.系统需要在ORACLE数据库中写入业务数据后，还需要在游戏数据库里写入数据,而游戏数据库一般都是SQL SERVER,所有的操作都需要在一个事务中完成.