游戏服务器框架概括分析
Posted VindyLeong 一个略神经病的程
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了游戏服务器框架概括分析相关的知识，希望对你有一定的参考价值。
这篇blog题目涉及的范围真大！以至于在这里需要先写一篇前言把范围缩小。选择写这样一个系列的文章，主要是想给工作了两年的自己一个交代，或者说是一个阶段性的总结。两年时间里，房价依然再涨，工资依然跑不赢CPI，某人依然在仰望星空。期间很多梦碎了，很多还在坚持着，生活过得波澜不惊。而我也从刚毕业是的青涩逐步蜕变为“老油条”。不知道是一种悲哀、还是一种悲哀、还是一种悲哀....... 庆幸的是梦还在继续，一颗倔强的心还在坚持。希望明天的明天被束缚的心能回到梦开始的地方！
==========================我只是条分割线========================
作为本系列blog的开篇前言，本文主要明确网络游戏服务器构架的设计目标，并作出一些限定。因为本系列所讨论的服务器端构架只适用于部分网游，并不是一个通用的网游服务器构架。
设计目标:
- 支持的游戏类型：大型MMORPG游戏，类似魔兽世界（有大世界，不是开房间式）。
- 连接方式：以TCP长连接为主。动作类游戏并不在本文讨论范围内（因为本人并没有参与开发过动作类游戏），如果有时间可以研究一下龙之谷（部分使用UDP传输）、天下贰（全部使用UDP传输），类似的逆向工程网上已经有人做了。
- 在线人数：保证最大1w人左右在线还能比较流畅的运行。如果在线人数大于1w对客户端的同学和策划的同学都是很大的挑战。
- 服务器可以以多进程的形式布置在不同的物理主机上，也可以布置在同一主机上，考虑效率的同时兼顾可扩展性。
- 能在普通配置的服务器上流程运行，物理主机配置：按照DELL 1950、DELL R610上32G内存的标准来部署主机，一般公司是用不起WOW的小霸王的.......
- 内存不用过多的考虑，因为现在服务器的内存已经很大了。减少内存使用会放到模块设计、详细设计里。不在构架分析的讨论范围内。
- 偏格斗的游戏会对CPU和带宽要求比较高，设计时需要进行讨论。
设计目标就这些多说无益，核心就是设计出能够支持类似魔兽世界的大型MMORPG游戏的网游服务器端。具体的设计以及设计时的取舍、需要解决的问题等，会在后续的文章进行详细的介绍。
网络游戏服务器构架设计（二）：刀剑Online - 连接负载服务器CLS
本文并没有涉及什么逆向工程，只是拜读刀剑Online服务器端主程的文章后[1]，想结合自己的经验谈一谈。
PS：由于题目范围太大，本系列的前言做了一些限制。
一、网络游戏服务器
要想设计好网络游戏服务器的构架，首先需要知道网络游戏服务器在玩家游戏过程中发挥什么作用。就我个人的理解：网游服务器在玩家游戏过程中扮演上帝的角色。玩家在服务器制定的规则下进行游戏，服务器负责同步在线玩家之间的属性、操作、状态等等，最终在多个不同的客户端呈现一个“统一”的游戏世界。
所谓的服务器构架在本系列blog中，主要是指如何将服务器各部分合理的安排，以实现最初的功能需求。好的结构不是一蹴而就的，是通过需求的推动一步步的完善。而且每个设计者心中的标准不尽相同，所以我认为并没有绝对优秀服务器构架。本系列文章中所谓的优秀构架是指各方面达到一种平衡（包括成本等的非技术因素）。
下面先介绍刀剑Online的服务器构架（后续还可能有WOW、天龙等）：
二、刀剑Online
图1 刀剑Online服务器构架
看了像素的技术总监魏华的文章[1]，感觉有点意思。文章中所介绍的服务器构架并不复杂，但满足一般MMORPG网游要求应该是绰绰有余了。按照魏华自己的话，这样的服务器构架主要满足能够接受以下几条限制的网络游戏：
- 游戏同时在线人数在1w人以下。
- 服务器为多进程程序，可部署在一台或者多台机器上。
- 服务器内存足够大，一般一个进程1~2G的内存需求还是应该满足的，64位系统能支持更大的内存需求。内存这块主要看游戏的设计需求。
- 刀剑属于格斗性质的网游，对CPU和带宽有一定的要求。（这篇文章写于2005年，当时刀剑可能是按照256k、512k或1M ADSL的网速进行设计的。现在已经开始普及10M网，带宽和网速应该可以满足），网络延迟的问题本文后面再做展开。对CPU的要求主要影响可承载人数。
- 地图采用独立小场景的管理模式，各个场景之间通过传送点来连接。每个场景服务器程序分管一部分地图。
服务器包括游戏中和游戏外两大部分，这里主要讨论游戏中的服务器构架，类似客户端自动更新等的游戏外服务器不在本文的讨论范围。
接下来对刀剑Online的服务器构架的各个部分进行详细的分析，其中包含很多我自己的想法，很多内容都是我猜测的，因此不能“信以为真”。
2.1 连接负载服务器（Connection Load Server，CLS）
游戏客户端在游戏过程中实际上是和连接负载服务器（简称CLS）进行连接并做数据交互的。如文中[1]所诉，CLS主要的作用是：
- 把网络连接和真正的游戏逻辑隔离开，降低游戏逻辑服务器处理网络交互的负担，同时提高游戏的安全性。有了CLS，刀剑Online的服务器对于玩家来说就是一个黑盒，如下图：
图2
- 使场景服务器（Zone Server）更为独立——客户端连接CLS而不是直接连接Zone Server的好处是：用户切换场景服务器时，并不会导致原来的TCP连接断开，从而使设计更为简单和独立。
- 提高发送广播消息的效率，比如需要全服广播时，游戏逻辑服务器只需要对CLS发送一条广播指令，而向每个用户的广播工作由CLS完成。
- 完成客户端数据交互的加密解密过程。
连接服务器的主要工作正如上述魏华谈到的，但有几点并没有做出强调，下面本人结合平时的实际工作给出一些补充（不一定正确）：
根据经验：
CLS作为与client建立连接、进行数据交互的“Gate”，从程序角度来看CLS的代码应该是最简洁高效的。因为CLS主要负责与客户端交互数据是的加密解密、以及数据搬运。而使用流加密算法RC4对整个数据流进行加密解密是很耗CPU的，因此代码的高效在这个模块是十分的重要。
为了提高程序的运行效率，CLS程序往往会使用-O3的选项进行编译，这无形中又对代码的编写有更高的要求。CLS一般会有自己的打包机制（控制发送频率），因此常会使用TCP_NODELAY选项禁用Nagle算法。
CLS常会被分配到不同的物理机器上，因为操作系统在处理TCP包时，需要通过软中断来通知进程或者唤醒system call，在服务器十分繁忙的时候CPU可能处理不过来。解决办法是：使用多核的服务器，然后把TCP的软中断平均分配到多个CPU。（一些操作系统默认只使用0号CPU来处理，Fedora Core release 2默认就是只使用0号CPU，较新的版本我没有做研究）
CLS在做数据流的解密后，往往需要把数据包构造成内部服务器进程间通讯使用的protocol，这种protocol模块要独立，序列化和反序列化的接口要稳定，这样以后需要更换协议模块也不至于伤筋动骨。可以使用像google的protobuf这样的开源协议，减少开发难度。
CLS负责建立和client的连接，多会使用多个CLS进程才能支撑1w的在线人数，因此在CLS前端一般会有负载均衡的程序，负责把建立连接的请求均匀的提交到各个CLS。
有一个需要讨论的问题：作为服务器端的“Gate”，只负责数据转发的CLS是否需要对client发过来的数据进行完全的解密？或者只解密包头，知道转发的目的地即可？（RC4并没有增加流的长度，因此可以只做部分解密）
CLS只做部分解密：
好处：将耗费CPU资源的解密功能分摊到别的进程；各进程各服务可以在解密后用不同的方案来构造自己的protocol。
CLS做完全解密：
好处：可以提前过滤部分无效的消息，只做部分解密也可以做提前过滤，但是这样太过于依赖协议的设计；在CLS处做完全解密，则往后服务器端的之间的消息传递都是明文，利于抓包查错；由于CLS的功能比较简单，很容易通过加机器来进行扩展，因此计算放在CLS上是比较明智的选择。
总结：
CLS是一个功能相对简单但要求代码简洁高效的程序，在设计实现的时应该注重效率及代码编写规范。经过对比在CLS程序对数据流进行完全解密是利大于弊的，推荐使用这种方案。
网络游戏服务器构架设计（三）：刀剑Online - 总控服务器、场景服务器
上一篇《网络游戏服务器构架设计（二）》介绍了刀剑Online的连接负载服务器CLS，博友提出质疑“说得不够详细，比如你怎么，场景服务器怎么才算一个场景服务器，场景服务器切换怎么处理不断线后连接另一个场景的，还有很多细节问题没有说到”，本篇就来介绍游戏服务器最为核心的部分：游戏逻辑服务器，同时也回答了这位博友的问题。
PS：本篇的文章结构主要分两个部分，前半部分（2.2节）介绍刀剑Online如何实现游戏逻辑服务器，后半部分（2.3节）为本人结合实际工作对这套服务器构架做出的一些展开解释及补充，主要对设计思想进行分析。精彩在后面哦！
-------------------------------------------我只是条分割线--------------------------------------------
先来回顾一下刀剑Online的总体构架图：
2.2 游戏逻辑服务器
顾名思义，就是和游戏具体逻辑相关的服务器（这应是一个统称）。这块是网游服务器端的核心部分，不同的游戏差别会很大。在刀剑中，游戏逻辑服务器分为两部分：总控服务器和场景服务器。
2.2.1 总控服务器（Master Server，MS）
关于总控服务器的作用，刀剑Online的主程是这么解释的：
总控服务器（以下简称MS）的作用之一是负责玩家在具体游戏内容之外的操作（即.玩家进入场景服务器之前地操作）。如：登录、注销、各种角色操作（创建、删除、选择）等等。
MS和所有地场景服务器都保持连接，这样它就成为各个场景服务器间的枢纽，当需要一些跨场景服务器的操作或者需要访问别的场景服务器数据的时候，指令都先发给MS，然后MS根据需要再转发给相应地场景服务器或者直接发给相应的用户，并进行后续地协调工作。
比如：在场景服务器1上的用户A希望向游戏中的用户B发出一条添加好友的请求，则场景服务器1向MS发送添加好友指令并附带了用户B的名字，MS查找发现有B这样的用户，则直接把指令发给CLS，然后由CLS转发给B用户；如果没有发现B用户则直接通知A未发现B。
又比如：在场景服务器1上的用户A点中了传送点，将要传到场景X，场景服务器1发现X场景并不在自己的管辖范围内，于是发送转移指令给MS，MS查找发现场景X在场景服务器2上，于是先发送用户A的离开指令给场景服务器1，让用户退回到MS上，然后再发送用户A的进入指令给场景服务器2，并说明用户将要进入的场景为X，这样一次跨服务器的场景转移就完成了。[1]
2.2.2 场景服务器（Zone Server，ZS）
关于场景服务器的作用，刀剑Online的主程是这么解释的：
场景服务器（以下简称ZS）就是具体负责游戏场景的服务器。玩家选择人物开始游戏之后就进入了这种服务器（即开始游戏之后CLS把所有玩家的操作指令都转给ZS）。
玩家的各种操作的逻辑都是由ZS完成的，同时，ZS也要负责各个场景以及场景中的NPC和场景中各个物品的逻辑运行。
每款游戏的真正游戏性的核心就是这些ZS。它的具体细节我就不过多的讲述了，各个游戏的具体内容应该都不相同。不过有几个原则是共同的：
一、是要高效。如果ZS对游戏逻辑的处理效率低，会直接影响玩家同时在线的数量，并导致游戏中的玩家感觉很“卡”，这是除了网络延时之外第二个会造成游戏 “卡”的地方。提高效率的方法除了对代码进行优化外，就是要使用高效的脚本系统，直接把脚本转化为程序代码编译到程序中去也不失为一个办法。
二、是要有灾难恢复机制，就是当ZS发生非法操作时（只要不停电）能够恢复出非法操作时各个用户的数据。这个在游戏运营初期服务器尚不稳定的时候非常重要。虽然我们也可以通过加快用户存盘间隔的方式（比如把每10分钟存一次盘改为每1分钟存一次盘），但是这会成倍加重数据库负担，同时也不能避免由于用户刚好在存盘间隔的时候获得了重要的金钱或道具而导致丢失的情况。刀剑采取的方法是在申请用户关键数据对象的时候通过包装的函数从共享内存中申请，这样即便ZS非法操作了，共享内存并不会消失，在重新启动的时候就可以从共享内存中恢复出程序非法时的用户数据。当然恢复的时候也需要对用户数据进行一些校验，以免把已经被破坏的数据存入数据库。[1]
2.3 设计思想分析
游戏逻辑服务器主要负责汇总所有在线的client发来的各种操作、状态等数据包，经过一系列的处理后有选择的广播给需要的client，从而给所有在线的玩家呈现一个“统一”的世界。
优秀的逻辑服务器架构需要优秀的设计思想，而优秀的设计思想又源于对游戏虚拟世界的适度抽象。抽象可以看作一个工程问题，同时也可以看作一个哲学问题，这正是游戏开发的魅力所在。本系列blog将围绕这种抽象一步步展开，结合不同的项目来诠释网络游戏服务器端的设计思想（希望能做到....）。
站在服务器端的角度对游戏虚拟世界进行抽象，首先要弄清楚构造虚拟世界需要些什么？让我们来想象一下吧（以下内容参照了《盗梦空间》-“Inception”），先来看一段视频：
Inception是我非常喜欢的影片，第一次看到这一段的时候，就感觉非常像游戏设计。今天能把它写下来也算没浪费几十块的电影票钱。
影片中饰演the architect（造梦师）的艾伦·佩姬(女)，正在接受莱昂纳多（饰演the extractor-盗梦者）的训练。莱昂纳多说道：“Remember you are the dreamer you built this world。”，“I\'m the subject my mind populates it”。值得关注的两个名词：world，subject。这就是我们要讨论的主题。那么构造网络游戏的虚拟世界需要些什么呢？其实莱昂纳多已经替我回答了这个问题：“We create and perceive out world simultaneously. You create the world of the dream, We bring the subject into that dream, and they fill it with their subconscious.”。world就相当于游戏里的场景，而subject就是一个个在线的玩家（player）。
游戏世界（world，这里的world泛指游戏世界及地图，见2.3.2）及游戏对象（object，包括player）是构造网络游戏服务器端时，需要关注的两个重点。如何处理好world和object的关系和地位直接影响到服务器端的构架。
2.3.1 游戏对象（object）
先来看游戏里一般会有那些object，以Mangos为例：
图2 mangos游戏对象的class diagram[2]
对于上面的类层次结构图这里不做展开（留到本系列后面的文章中展开），这里引用mangos的游戏对象是想给读者一个直观的印象，游戏中的object在服务器端是个什么摸样。类的层次是对游戏世界中的对象抽象后得到的结果，抽象需要“适度”：如果类的层次过深，维护起来困难，而且后期往往会导致基类过于臃肿、不堪重负；如果类的层次过浅，一些object的共性不能体现，很多代码会重复出现在各个子类里，复用性差。
2.3.2 游戏世界（world）
游戏世界在本文是泛指游戏对象所在的场景，以及附加在场景之上的地图管理和对象管理，这里统称游戏世界管理。
如何进行游戏世界的管理是一个复杂的工程问题，网络游戏常常会把整个游戏世界分为若干张地图，每张地图又会分为若干个区域进行管理。这若干张地图能无缝的过渡就称为无缝大地图模式（类似WOW），如果像刀剑Online那样只能通过传送服务在两张不同地图之间穿梭的，称为有缝地图。而相对来说服务器端会比客户端简单一些，例：如果在客户端看到的场景是下面这个样子：
服务器端根据划分区域的不同可能看到的地图是这个样子：
这里服务器端用到了tile-based的方式来管理地图，这种tile的方式在2d游戏中十分的常见（打格子），而很多3d网游的服务器端为了减少运算量也采用这种tile模式划分区域进行管理。如果对地图管理有兴趣请阅读云风的blog《用四叉树管理散布在平面上的对象》、《碰撞检测》，本文先不做详细的展开。
2.3.3 游戏对象和游戏世界的关系
如何处理游戏对象和游戏世界的关系和地位，是影响服务器端架构的最直接因素。为了体会到这点，下面将以刀剑Online为例，分析玩家对象（player，游戏对象中最为重要的部分）和游戏世界的关系对整个服务器构架设计的影响。
1. 玩家对象player的构建
刀剑Online把游戏逻辑服务器分为总控服务器（Master Server，MS）和场景服务器（Zone Server，ZS，本文提到的游戏世界多指ZS），那么在client成功登陆server后，服务器端应该在哪构建player对象呢？在MS上？还是在ZS上？这是个工程问题，同时也是个哲学问题.......
- 如果把player（以及其他的游戏对象）放在Master Server上：也就是说所有登陆的玩家的数据都会在MS的内存中有一份映像，MS将保存着player最新的数据。这么做的好处是player的数据统一，从而使同服玩家的一些交互变得十分方便，比如同服玩家组队、交友等不需要知道玩家在那个ZS里。切换场景服务器时也不需要把player数据从一个ZS拷贝到另一个ZS，只需要把player身上记的ZS信息修改一下；player在MS上构建的缺点也是显而易见的，所有中心节点式的系统都会遇到单点不可靠的问题，player的信息都保存在MS上，假如有1w人在线，内存占用就是一个很大的问题（毕竟单个进程的内存使用还是有限制的，实际开发中曾经遇到占用十几G内存的进程......相当可怕），而如果一个player借住外挂发送一些非法消息给MS，错误处理不当时很有可能会core进程，这样一来整个服务器的玩家都会掉线。还有一些和地图相关的逻辑会很难操作，比如player与场景中怪物进行PK时，由于player的数据保存在MS，因此ZS需要做一个Attach操作告知MS某个player和某个monster进行战斗，MS进行完伤害计算后发AttachResult给ZS，最后由ZS再广播给相关的客户端，如图：
如图中标注的（1）~（4）的步骤，展示了这个过程，编程操作起来还是挺麻烦的。 - 如果把player放在Zone Server上：这是一种比较常见的方式，player和其他游戏对象在场景服务器中构造，隶属于Zone S
以上是关于游戏服务器框架概括分析的主要内容，如果未能解决你的问题，请参考以下文章
