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

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

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

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

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

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

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

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

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

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

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