游戏服务器的设计是一项颇有挑战性的工作，游戏服务器的发展也由以前的单服结构转变为多服机构，甚至出现了bigworld引擎的分布式解决方案，最近了解到Unreal的服务器解决方案atlas也是基于集群的方式。
负载均衡是一个很复杂的课题，这里暂不谈bigworld和atlas的这类服务器的设计，更多的是基于功能和场景划分服务器结构。
首先说一下思路，服务器划分基于以下原则：
1：分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器
2：在同一服务器架构下的不同游戏，应尽可能的复用某些服务器（进程级别的复用）
3：以多线程并发的编程方式适应多核处理器。
4：宁可在服务器之间多复制数据，也要保持清晰的数据流向
5：主要按照场景划分进程，若需按功能划分，必须保持整个逻辑足够的简单，并满足以上1，2点
服务器结构图：
各个服务器的简要说明：
Gateway：应用网关，主要用于保持和client的连接，该服务器需要2种IO，对client采用高并发连接，低吞吐量的网络模型，如IOCP等，对服务器采用高吞吐量连接，如阻塞或异步IO。
网关主要有以下用途：
1：分担了网络IO资源
2：同时，也分担了网络消息包的加解密，压缩解压等cpu密集的操作。
3：隔离了client和内部服务器组，对client来说，它只需要知道网关的相关信息即可（ip和port）。
4：client由于一直和网关保持常连接，所以切换场景服务器等操作对client来说是透明的。
5：维护玩家登录状态
World Server 是一个控制中心，它负责把各种计算资源分布到各个服务器
它具有以下职责：
1：管理和维护多个Scene Server
2：管理和维护多个功能服务器，主要是同步数据到功能服务器
3：复杂转发其他服务器和Gateway之间的数据
4：实现其他需要跨场景的功能，如组队，聊天，帮派等
Phys Server 主要用于玩家移动，碰撞等检测
所有玩家的移动类操作都在该服务器上做检查，所以该服务器本身具备所有地图的地形等相关信息。具体检查过程是这样的：首先，Worldserver收到一个移动信息，WorldServer收到后向Phys Server请求检查，Phys Server检查成功后再返回给world Server，然后world server传递给相应的Scene Server.
Scene Server 场景服务器，按场景划分，每个服务器负责的场景应该是可以配置的。理想情况下是可以动态调节的。
ItemMgr Server 物品管理服务器，负责所有物品的生产过程。在该服务器上存储一个物品掉落数据库，服务器初始化的时候载入到内存。任何需要产生物品的服务器均与该服务器直接通信
AIServer 又一个功能服务器，负责管理所有NPC的AI。AI服务器通常有2个输入，一个是Scene Server发送过来的玩家相关操作信息，另一个时钟Timer驱动，在这个设计中，对其他服务器来说，AIServer就是一个拥有很多个NPC的客户端。AIserver需要同步所有与AI相关的数据，包括很多玩家数据。由于AIServer的Timer驱动特性，可在很大程度上使用TBB程序库来发挥多核的性能。
写的不错..
不过有几点值得商榷:
1.Phys Server 服务器的分离,这个会使逻辑变的复杂很多.比如技能的可见性判断等就会异步过程.
2.ItemMgr Server 这个觉得没必要,DB保持的负荷可以用专门的DB服务器来负责.
3.AIServer一般来说，都是服务器CPU负荷的大头,分离的想法不错，我们就是这么做的.效果很好.不过全定时器响应也是有效率和响应速度的瓶颈.部分采用事件响应，会使游戏表现好很多.
最后一点，服务器除了通讯底层外，逻辑层尽量别用多线程.
合理分布式的多进程设计即可解决问题.
