Yahle的blog:

http://www.cnblogs.com/yahle/category/122544.html

在yahle的blog看到其对webgame架构的一个构想，假设这个构想要用java来实现的话，有几个方面想请教下大家


以下是yahle的原文：
=========================================================================================
1 体系结构
1.1 传统的网站的架构
传统的网站一般都是以N层结构一般N为3，就是我们常说的三层架构。
3层架构分为数据层、业务逻辑层、页面显示层。
1.2 WebGame的架构
WebGame可以看作是网站和游戏的结合体，因此它具备了这两类系统的特性。我们不但可以把WebGame看作是一个网站，也可以把它看作是一个网络游戏。
的网站是B/S结构，网络游戏则是C/S结构，WebGame则是这两者的结合我们暂且称之为B/C/S结构。既在用户眼里，它是一个通过浏览器范围的网站。在服务器系统里，它又是一个传统的C/S结构的网络游戏。

从上图分析，用户通过浏览器访问服务器的时候，首先是访问网页服务器，如windows平台下的IIS,linux下的Apache。在通过网页服务器，以某种特殊的方式（分布式访问，如.net下的remoting）去访问游戏服务器，通知游戏逻辑服务器执行玩家操作，并从游戏逻辑服务器里获得游戏相关的信息，或者直接通过访问数据库而获得游戏数据。

1.2.1 为什么要将服务器分为游戏服务器和网页服务器
网页服务器的特点是触发执行，及当有用户访问网页的时候，才会执行该网页的程序代码。而我们常见的WebGame（Ogame,Travian)这些游戏实际上是需要24小时不间断执行的，因此网页服务器的执行方式并不适合与游戏。因此我们另外需要一个应用程序来执行这些24小时不间断要做的事情。这也就是我们需要增加一个游戏服务器的原因。
Webgame现在已经开始需要进入大统一服务器时代，每个游戏区域容纳的玩家数量将从现在的几万人发展到几十万人，因此在新的背景下，webgame如何处理大量用户的请求将成为问题。目前一台asp.net做的weggame服务器每秒能处理500~1000个页面请求，按照每个玩家每隔3~5秒做一次页面操作（页面请求），一台服务器能承受2k~4k的玩家在线，对于一个只有几万人的策略游戏来说，已经是足够了。但对于一个未来将承载几十万人的游戏来说远远不够。

通过分析，玩家在游戏过程中，有80%以上的访问仅仅只是查看玩家在游戏里的状态，实际上真正会对游戏运行状态及数据修改的的页面请求不足20%。因此，我们可以将呈现页面和处理游戏逻辑的功能拆分为2组服务器：页面服务器和逻辑服务器。两者之间可以通过remoting的方式进行数据通讯。将服务器分离后，随着页面服务器的增加，页面访问能力能应该能提升4~6倍。在往上逻辑服务器就会出现访问瓶颈。解决方法可以让页面服务器在读取玩家数据时直接访问数据库或者增加一个对象缓存服务器。页面服务器只有在必要的时候（需要进行逻辑运算时）才访问逻辑服务器，而逻辑服务器在玩家数据发生改变后更新对象缓存服务器和数据库。这样就可以大大降低逻辑服务器的访问次数，使页面访问能力进一步提升，轻松突破万人在线。如果访问量还需要继续扩大，可以用httpd做前台负责相应图片以及css等静态文件。


========================================================================================

1， 这里游戏逻辑服务器，是否有存在的必要？还是说和其他web结构一样，在tomcat实例上面部署一个完整的分层结构？
2， Webserver和 逻辑服务器之间，使用remoting来通信是否会成为高并发时的一个瓶颈？内网之间的服务器，能否通过一个其他的高效方式来连接？
3， 如果要用java开发这个游戏逻辑服务器，可否用spring 搭建一个socket server来实现？有什么好的实现方式？

4，假设采用flash作为客户端，纯粹基于http的话，flash可以通过xmlhttp和webserver的jsp进行通信。不要求纯粹的http的话，也可以用sokcet和webserver进行通信，不过这样的话不如直接和gameServer进行通信，而且socket相对http端口问题还是存在。如果该webgame主要框架就是大型聊天室的话，不知道采用哪种方式好点？基于纯http的话，就会产生大量的轮询请求，这种构架是否真能做到所谓万人同时在线呢？