游戏服务器架构简述

 

 任何服务器都是命令驱动的其行为不外乎，命令发起-〉交互确认-〉执行动作完毕，也有一些特殊的情况例如事件发起。同步方式下命令发起方会等待服务器的返回，而异步方式下客户端不会等待服务器的返回。同步方式下交互是按顺序的而异步方式下为了不让命令行为太怪异这个行为也是被队列化的。发送命令1，2，3，同样服务器会依次返回命令1，2，3，这个返回的次序错误一般可以认为出错了，当然哪些不需要返回的命令除外。这相当于在网络层面上添加的二个层面，数据操控层面和逻辑层面。命令的序列化和网络的连接归纳到基本的网络操作层。对数据集的操作归结到数据操控层面，逻辑层面负责用户命令的处理。一个逻辑行为会引发多个数据层面的操作。最终归结为一个或多个用户行为的反馈。前面说过用户的行为是不连贯的中间需要多次交互时也许我们应该引入另一概念行为。一个行为可以有一系列的命令和交互组成。因为这里有一些上下文的数据是要传递的，现说下lua这种语言的特性：Lua 并不帮你编写大量的代码的程序，相反的，Lua 仅让你用少量的代码解决关键问题。当用较少的语言尝试去解决关键的问题时带来一个问题就是上下文环境切换时参数传递的问题。两段完全不在同一个环境的命令如何串联起来又不把这些数据发送给客户端。因为命令之间是由客户端交互产生的但相关上下下文环境却不能保存在客户端。mudos里发起一个input_to是一个方便的解决方案但并不是最好的解决方案。当然也可以把这些数据用加密的方式发送给客户端并让客户端反弹回来，或者建立一个临时的数据块记录到用户数据上。这里也许遇到一个更困惑的问题的就是我们要为用户的行为生成好多的命令。使用哪一个方法并不能改变这种交互的形式。命令还是要运行在上下文无关的环境中。

  对数据层面有点复杂，这种复杂是因为每个游戏的数据并不一样，带来的问题是数据集的划分是很困难的。如果两个数据没有时间，次序的关系那么这两个数据在一个行为上就是无关的两个数据。这里有个悖论就是如果两个数据绝对的没有关系，那么这两个数据就不是一个世界的数据，如果不是一个世界的数据他们在行为上也就没有关系。服务上存放的数据就是所有玩家共同的数据是所有玩家交集部分，在某些条件的划分多个系统倒是更好的选择。有个简单的例子：如果非要在邮件系统加上等级的判断就不是一个很好的主意，比如判断在邮件发送的过程中用户的等级是否有变化来决定是否让用户收到邮件这样的游戏逻辑会把邮箱系统和整个游戏逻辑深深的联系在一起。更极端的例子是当某天游戏取消了等级这个概念时也许人们会忘记修改这个部分导致永远收不到邮件。划分不同的系统让每个系统独立的运作起来绝对是无论在哪个领域都是最好的选择。

  数据层面和逻辑层面的划分的基本依据就是数据层面的行为会反复的被逻辑层面调用，数据层面完成的是高效单一的行为，逻辑层完成是多个对数据层面的操作简单的判断。

  接下来说一点沟通的问题，在没有开始相互指责的前提下，时间进度等等，跨部门的沟通或叫相互制约当中。任何个人的表现都是很重要的，无论任何时候都要按照规章制度去走。发现对方的不对就要立刻指出。

  我经历过一件事，某部门提供需求不完整，前提条件缺乏。当时没有立刻指出了当然这也有可能是陷阱。安排进度的时候并没有考虑前提条件。当工作开始到某个阶段的时候发现前提条件不满足，这时对方下流的说法会是前提条件是你应当考虑的问题，时间进度等等的压力就下来。这个时候没有按行为规定的进行自测提交了有明显bug的产品导致另一个部门的不满。在这种情况下最容易导致的就是情绪上的失控。这种沟通上的行为是不能避免的甚至的公司内战争的导火索。