无缝世界网游服务器架构的设计思路（一）（转）
过去一年中，花了很多时间在考虑服务器架构设计方面的问题。看了大量文章、也研究了不少开源项目，眼界倒是开阔了不少，不过回过头来看，对网游架构设计方面的帮助却是不多。老外还是玩儿console game的多，MMO Games方面涉及的还是不如国内广泛。看看 Massively Multiplayer Games Development 1 & 2 这两本书吧，质量说实话很一般，帮助自然也很有限。当然这也是好事，对国内的研发公司/团队来说，在网游服务器技术方面当然就存在超越老外的可能性，而且在这方面技术超越的机会更大，当然前提是要有积累、要舍得投入，研发人员更要耐得住寂寞、经得起诱惑，在平均每天收到超过3个猎头电话的时候——依然不动心。
上面有点儿扯远了，下面聊聊无缝世界架构（Seamless world server architecture）设计方面的一点儿看法。
先说架构设计的目标——我的看法，服务器组架构设计的目标就是确定各服务器拓补关系和主要的业务逻辑处理方法。主要要解决的问题就是在满足游戏内容设计需要的前提下，如何提高带负载能力的问题。
最简单的架构就是基本的C/S架构，一台Server直接构成一个Cluster，所有Client直接连接这个Server，这个Server完成所有逻辑和数据处理。这架构其实很好，最大的好处就是它架构上的 Simplicity ，Cluster内部的跨进程交互完全被排除，复杂度立刻就降下来了，而且——完全可以实现一个无缝（Seamless world）的游戏世界。但是即使我不说，大家也知道这种单Server架构会有什么问题。不过我们不妨以另外一个角度来看这个Server——一个黑盒子。从系统外部的角度来看，什么样的系统都可以看成一个整体、一个黑盒，而不管系统内部的拓补关系和实现复杂度方面的问题。在不考虑这个系统的实现的前提下，理论上Cluster的处理能力就是由硬件的数量和能力决定的，也就是说一个Server Cluster内包含越多的服务器、服务器越‘快’，那么这个Cluster的处理能力越好、带负载能力越好。那么我们要面对的带负载能力的问题，就是如何高效的利用这些Server的问题，基本上也可以理解为如何提高玩家请求的并发处理能力的问题。
CPU厂商在很久以前就在考虑这方面的问题了，CPU其实也可以看成个黑盒。看看他们用过的技术——流水线（pipeline）技术、多CPU/多核（multicore）技术，以及这些技术的衍生技术。我想了很久让 Server Cluster 内部处理并行的方法、并且有了比较清晰的思路之后，才发现其实早就可以参照CPU厂商的方法。流水线的方法就是把一个指令处理拆分成很多个步骤，这样指令的处理被分解之后就可以部分重叠（相当于变成并发的了）执行。我们的Server Cluster一样可以用这种方法来拆分，我想了个名字——
Services-based Architecture——基于服务的架构。在这种架构内部，我们根据处理数据、逻辑的相关性来划分组内各个服务器的工作任务。例如：位置服务提供物体可见性信息、物品服务处理所有物品相关的逻辑、社会关系服务提供行会家族等等方面的逻辑、战斗服务器只处理战斗相关的逻辑，等等。这样划分的话、逻辑处理的并发就有了可能性。举例来说：A砍B一刀这件事情与C从奸商手里买到一件武器这个事情是完全不相干的，而且这2个请求本来就在不同的服务器上被处理，他们是被不同的Service Server并发处理的。这就是 Services-based Architecture 的并发方法。
基本上，把游戏逻辑的处理拆分成一个个的service，就和设计cpu的时候把机器指令的具体处理拆分，然后设计出一个个流水线单元是一个道理。
Cells-based Architecture——基于cell的架构。每个cell都在不同的物理server上面运行着完全一样的应用程序服务器，但是他们负责承载不同的游戏场景区域的游戏逻辑。和 services-based arch. 明显不同的就是，每个cell都是个‘在逻辑上完整的’服务器。它得处理物品操作、人物移动、战斗计算等等几乎所有的游戏逻辑。尽管这么做会带来一些（可能是很复杂）的问题，但是它完全是可行的。举例来说：在吴国A砍B一刀显然地和千里之外在越国的C砍D一刀不搭界，他们完全可以被不同的Cell并发地处理。
基本上，这就相当于一个主板上面插多个CPU或者一个CPU但是有多个内核，每个CPU能做的事情都是一样的，而且能一起做。
关于这两种 seamless world 架构的基本分析和需要解决的一些主要问题，下次再写。
上面有点儿扯远了，下面聊聊无缝世界架构（Seamless world server architecture）设计方面的一点儿看法。
先说架构设计的目标——我的看法，服务器组架构设计的目标就是确定各服务器拓补关系和主要的业务逻辑处理方法。主要要解决的问题就是在满足游戏内容设计需要的前提下，如何提高带负载能力的问题。
最简单的架构就是基本的C/S架构，一台Server直接构成一个Cluster，所有Client直接连接这个Server，这个Server完成所有逻辑和数据处理。这架构其实很好，最大的好处就是它架构上的 Simplicity ，Cluster内部的跨进程交互完全被排除，复杂度立刻就降下来了，而且——完全可以实现一个无缝（Seamless world）的游戏世界。但是即使我不说，大家也知道这种单Server架构会有什么问题。不过我们不妨以另外一个角度来看这个Server——一个黑盒子。从系统外部的角度来看，什么样的系统都可以看成一个整体、一个黑盒，而不管系统内部的拓补关系和实现复杂度方面的问题。在不考虑这个系统的实现的前提下，理论上Cluster的处理能力就是由硬件的数量和能力决定的，也就是说一个Server Cluster内包含越多的服务器、服务器越‘快’，那么这个Cluster的处理能力越好、带负载能力越好。那么我们要面对的带负载能力的问题，就是如何高效的利用这些Server的问题，基本上也可以理解为如何提高玩家请求的并发处理能力的问题。
CPU厂商在很久以前就在考虑这方面的问题了，CPU其实也可以看成个黑盒。看看他们用过的技术——流水线（pipeline）技术、多CPU/多核（multicore）技术，以及这些技术的衍生技术。我想了很久让 Server Cluster 内部处理并行的方法、并且有了比较清晰的思路之后，才发现其实早就可以参照CPU厂商的方法。流水线的方法就是把一个指令处理拆分成很多个步骤，这样指令的处理被分解之后就可以部分重叠（相当于变成并发的了）执行。我们的Server Cluster一样可以用这种方法来拆分，我想了个名字——
Services-based Architecture——基于服务的架构。在这种架构内部，我们根据处理数据、逻辑的相关性来划分组内各个服务器的工作任务。例如：位置服务提供物体可见性信息、物品服务处理所有物品相关的逻辑、社会关系服务提供行会家族等等方面的逻辑、战斗服务器只处理战斗相关的逻辑，等等。这样划分的话、逻辑处理的并发就有了可能性。举例来说：A砍B一刀这件事情与C从奸商手里买到一件武器这个事情是完全不相干的，而且这2个请求本来就在不同的服务器上被处理，他们是被不同的Service Server并发处理的。这就是 Services-based Architecture 的并发方法。
基本上，把游戏逻辑的处理拆分成一个个的service，就和设计cpu的时候把机器指令的具体处理拆分，然后设计出一个个流水线单元是一个道理。
Cells-based Architecture——基于cell的架构。每个cell都在不同的物理server上面运行着完全一样的应用程序服务器，但是他们负责承载不同的游戏场景区域的游戏逻辑。和 services-based arch. 明显不同的就是，每个cell都是个‘在逻辑上完整的’服务器。它得处理物品操作、人物移动、战斗计算等等几乎所有的游戏逻辑。尽管这么做会带来一些（可能是很复杂）的问题，但是它完全是可行的。举例来说：在吴国A砍B一刀显然地和千里之外在越国的C砍D一刀不搭界，他们完全可以被不同的Cell并发地处理。
基本上，这就相当于一个主板上面插多个CPU或者一个CPU但是有多个内核，每个CPU能做的事情都是一样的，而且能一起做。
关于这两种 seamless world 架构的基本分析和需要解决的一些主要问题，下次再写。
