书接上回<高性能MMORPG通用服务端引擎设计之->基本概念篇>
上回说道我们将服务器组的职责划分为了，前端服务器，场景服务器，登录服务器，数据服务器...etc.
如图：
Logic-Service Logic-Service DB-Service
| | |
-----------------------------------
|
Scene Manager
|
-------------------------------------
| | |
Front Server Front Server Login Server
| |
Client Client
不过经过思考后发现这个结构有点问题。
问题何在呢？我们来好好分析一下游戏的逻辑后会发现，整个MMORPG的服务端逻辑，其实是对服务端事件的响应，这里有两种事件，一种是对自身属性的改变（比如切换技能，向腰带放入药瓶之类的），一种是改变其他玩家属性，或者是需要通知其他玩家知道的自身属性改变（比如，攻击对方，自己回血，换装，移动等），也就是前文中我们分析发生在场景中的事件，第二种事件远远超过第一种事件，而且大部分的业务逻辑也发生在这些事件中，所以这类事件的处理需要消耗更多的CPU。这样就带来问题了，前端服务器的压力主要在IO，而场景服务器的压力主要在CPU，那么如果分开在不同的机器上部署，那么这两边服务器的压力就不均衡了，前端服务器的CPU剩余很多，场景服务器的CPU又不够用。所以我决定将这两个部分再次合并起来，合成Logic服务，然后多个Logic服务并行运行。
所有的游戏逻辑都在逻辑服务中运算，但是按照MMORPG的业务，所有的逻辑基本都是按照场景来分布的，所以这个时候我门又面临2难的选择题了。第一种方案是，我们可以按照场景来组织逻辑，比如服务器A负责1，3，5，7场景，服务器B负责2，4，6场景，因为场景之间的人数不平均，有的场景人多（比如某某城内，正在被大批人追杀的BOSS所在地），有的场景人少（比如运行一段时间后的新手村），而且游戏中的热点场景是动态变化的，随着游戏进程的发展会有变化。所以这个情况下我们需要一个场景管理服务，这个服务用于监控每个逻辑服务，将热点场景所在的服务里的其他场景迁移到空闲逻辑服务器。这个逻辑需要客户端提供支持，要实现服务器的软切换。还有一种方式是将场景的逻辑随机分布到所有逻辑服务器上，场景间的联系通过消息来传递，由一个消息服务器来为所有场景提供广播组来分发消息。这样就会多个消息服务器出来。这两个方案中第一个对单个玩家来说延迟最小，但是如果场景管理做得不好就会造成CPU资源分布不均匀，还有就是场景容量受到单个进程处理能力极限的局限。第二种方案延迟肯定大过第一种，但是场景的容量不受单个进程计算能力的影响，扩展性更好一点。
最后我决定用Python来实现这个想法，一，有丰富的基础框架可以选择，比如用高性能的Gevnet或者Eruasia来作为TCP Server的基础。二是Python本来就是动态的，所以不需要再嵌入另一个动态语言来适应多变的业务逻辑了。其三是Python是动态类型的，在实现消息服务的时候更方便。本来打算用erlang的，不过暂时对OTP还不是很熟悉所以暂时作罢，不过如果采用第二种方式的话我可能会用Erlang来实现消息服务器。
下一章直接进入实现阶段，并且无论如何我都会把这个玩意儿弄出来，如果没有公司愿意花钱让我弄，我就业余时间自己弄出来开源，哼哼