1s | haokiu

10 十万在线的WebGame的数据库设计思路

10 十万在线的WebGame的数据库设计思路服务器数量预估在线人数预估：在项目设计之前，需要先对运营后的服务器人数做一下预估，预计激活人数300w，活跃人数40w，同时在线10w。而服务器的设计极限则在激活人数500w，活跃人数60w，最高同时在线15w。数据参考：这里之所以预计这么低的激活人数，是从整个服务器考虑的。《热血三国》是将不同的用户放在不同的服务器里，所以单一服务器的激活人数不会对服务器压力产生太大影响。而如果将所有玩家统一到一组服务器里，则会导致用户表访问压力过大。偏低的激活人数靠定期清理不活跃账户来实现。数据库服务器数量估计：服务器在搭配上，一般分为db服务器和web服务器。在这之前的运营中，通常按照1:1的方式来配置数据库和web服务器，而实际情况可以使1:2的配置比例。不过在单一世界的设计里，单台db服务器肯定无法满足需求。之前设计过一款策略类webgame，在运营时，每秒sql数为在线人数的1~1.5倍。不过这个测试数据，是在没有钱全面应用缓存的情况的数据，在新系统里，如果全面应用缓存，并采用类似于Memcache的软件提供数据缓存，这样数据库的访问压力将可以得到极大的缓解，因此我们暂定吧每秒sql数暂定为在线人数的1倍。正常情况下数据库的访问压力应该为 10w sql/秒极限数据应该为15w sql/秒。数据库使用ms sqlserver 2008，在这之前的一个策略类webgame项目，对一台CPU为 E5520核的服务器上做压力测试，得到的数据如下： Sql数 5k CPU 50% 硬盘IO 0.5M(突发3M）网卡流量 30Mbit/s(100M网卡）按照上面的分析，在正常情况下，我们需要为整个系统提供20台db。Web服务端按照1:1和db做搭配，也将安排20台，预计3个机柜的服务器。数据库表结构划分数据库表设计：因为要把这么多访问量分担到不同的服务器里，原先的数据库表设计肯定不会合适。初步的想法是根据游戏的逻辑模块，将不同模块的数据库表拆分到各个服务器里，如果按照上面的服务器预估得到的结论是4~6组服务器，实际上这个方案还是可行的。但如果是20组服务器的话，除非是一台服务器一张数据库表，但这的设计会造成数据表太分散，在处理事务的时候，会跨多个数据库策略类webgame一般的主要模块为：建筑物和资源、军事、英雄、物品、帮会、交易、地图。根据这些模块的应用场景，可以将数据库表分为2种类型，一种是属于玩家的数据，另外一种是公共数据。属于玩家的数据是指玩家个人说拥有的基地、资源、军事单位、物品等数据，它们都是围绕着玩家而产生的。公共数据则是指由多位玩家共同组合而产生的数据，例如：账户信息、帮会、地图等。这里划分两种数据的目的是在于他们的数据库表的划分。对于公共数据，则采用单一服务器，单一数据库表处理的方式来处理。例如帮会模块和地图模块就准备分别用3台服务器来存储各自对应的数据库表。而对于玩家的数据，则根据用户ID采用一定的划分方式，将玩家数据打散到各个服务器里（http://blog.zhaojie.me/2010/03/sharding-by-id-characteristic.html）。（数据表的结构划分）用户表和其单表的设计思路：这里所说的单表是指在逻辑上部队数据库表做拆分，程序在访问时只访问一个数据库。当然这只是逻辑上的单一，根据实际上的访问压力，可以将数据库文件作水平切割分布在不同的文件分区和服务器里。这部分的数据库表设计继续沿用之前的设计方案就可以了。对于用户信息，帮会信息等数据，实际上插入和更新的频率不会太高，更多的是在查询上，因此这部分的设计重点应该是在缓存上。从以前的资料里得知Memcache服务器每秒可以响应4w次的读请求，用一台Memcache就能处理好用户和帮会信息的缓存处理。地图模块设计思路地图模块：地图在传统策略类webgame里都是以平面的方式展示和存储的。地图的移动都是在这个平面上实现。但一般来说，平面地图的设计容量都会有一个上限，一般来地图多为400*400，他的人数上限就是16w，实际上服务器容纳3~5w人后，整张地图就会显得很拥挤了。如果要想容纳几百万人在线，平面地图的尺寸就需要扩容得相当大了，这样玩家从地图中间移动到边缘的时间会相当恐怖，因此平面地图在这里不是很合适。因此，地图不能用平面来构造，必须是立体的方法构造。在这里我设计了两组方案：立体平面空间：如上图所描述的，立体平面空间，就是把多块地图一层层叠加在一起，形成一个立体的空间。这样如果用户不够，再增加一个新的平面就行。游戏的背景可以根据需要做调整（例如整个世界是被大海隔开的5片大陆组成，在这5片大陆之外，还有其它的超位面空间，这些空间自身是互不相连的，但是可以通过传送阵进行位面传送）。这样做的好处是，用户容易理解，以往用户的操作习惯不用改变，毕竟都是在平面地图上战斗。只不过要做跨位面的战斗的移动计算上会存在问题（逻辑上的问题：是否允许跨大陆的远征军）用户坐标的表示方法：地图层次、x坐标、y坐标数据库设计方案：采用了层次结构，只需要增加一个地图层次的字段，这个地图表就能沿用。（参考字段：ID、地图层次、X坐标、y坐标、地图类型、玩家ID、城池ID）虽然说，加入了一个地图层次的字段能解决地图的表示问题，不过，因为整个游戏世界是单一世界的服务器，当所用地图信息存储到一张表的时候，这数据量就不容小视。在这之前做webgame项目的时候，整张地图是预先生成好数据库记录的，当有玩家加入游戏的时候，就去修改表里的玩家ID和城池ID。同时因为地图大小只有400400，整张表也就16w条记录。但如果是要做一个承载500w人的服务器，那地图的尺寸最好是要800800，并且地图的层次为 15~20层，就算最小的15层，按照原先的设计思路，至少需要预先插入960w条记录。数据量看上去比较夸张，不过对于SqlServer来说也不是处理不了，并且我们还将计划把地图表单独用一台服务器来处理，其压力远小很多。不过也不能不考虑当发生性能瓶颈时的优化处理。优化的方法有两个：拆分：按照地图层次，把这张表拆分成15~20张表，或者拆分到15~20个数据库里用疏矩阵存储：地图不预先生成用户的地图信息，而是有玩家加入时才插入数据。这个方案在服务器早期人数比较少时会得到良好的性能效果，但当用户人数达到一定量时，还是避免不了因为记录函数过多而导致而外的开销。全立体空间：全立体空间就是取消了平面的坐标显示，用户都是在一个三维的立体地图里战斗。好处是地图不用那么分散，在移动计算让很好处理，存在的问题就是游戏在显示的时候，如何表现地图的三维效果会比较困难。用户坐标的表示方式：x坐标 y坐标 z坐标数据库存储方案：三维空间的数据库表设计结构可以和上面的表一样，而且也只能采用疏矩阵的方式存储，因为做成三维空间后，可表示的位置的记录数更多了。可移动基地在全立体空间的设想：早在两年前，看过《超时空要塞F》的时候，就产生了一个想法，就是玩家的基地是可以移动的。玩家的母舰在游戏的过程中，已一定的速度在整个世界里移动。可以移动体系的设计要点：用户的基地可移动用户基地只能拥有一个（武林三国、travian都能建立多个）空间坐标由x坐标 y坐标 z坐标组成，并且坐标的值应为小数同一个坐标里运行多个玩家存在，玩家的航线交叉并不会造成影响（只是为了方便计算减少判断过程）移动的数据通过后台定时刷新 a)每个短周期(1~60s)在内存里更新坐标 b)每个长周期（10~100个短周期时间）将坐标的数据更新的数据库攻击舰队移动的时间是按照2个阶段来进行的 a)第一个阶段是从母舰移动到目标坐标的时间 b)第二个阶段，在快到达时（前60分钟），做一个判断，判断攻击舰队的雷达能否搜索到目标的母舰坐标，能则做攻击坐标的新修正，如果不能则继续按照原先的坐标点移动。以上判断将每隔1分钟做一次，直到到达目标坐标点。如果到达目标坐标点仍然无法视为攻击失败，舰队返回舰队的移动距离和舰队所携带的能量有关，超过移动范围的坐标，舰队是无法出发的。部队和母舰应该是可以进行空间跳跃实现长距离的移动，不过空间跳跃需要在制定地点消耗大量的能量才能实现。默认情况下，母舰移动速度为1格（x、y、z坐标）/天。默认舰队的雷达查询范围为1格默认母舰的雷达查询范围为3格玩家数据的数据库设计数据库的划分: 在游戏里数据交互最频繁的还是玩家的数据，他的访问量是一台服务器所不能解决的，因此我们考虑将这部分数据分担到多台服务器里。分担的方法还是做水平切割，但这次不使用数据库自身的切割功能，而是在应用逻辑层上对数据库进行切割。根据用户的ID取模后写入对应的服务器里。服务器1 用户ID % 服务器数量 = 0 服务器2 用户ID % 服务器数量 = 1 …… 预计每台服务器能提供6k~8k的在线用户访问，预计一共需要16台服务器。考虑到服务器的进一步扩容问题，在初期规划时，建议规划为32个数据库，每台服务器可以先放3~5个数据库，等服务器用户人数上来后，再将数据库拆分到不同的服务器里。...

10 开放一个TeamTalk测试服务器地址和几个测试账号

10 开放一个TeamTalk测试服务器地址和几个测试账号由于TeamTalk是用于企业内部的即时通讯软件，一般客户端并不提供账号注册功能。如果你仅对TeamTalk的客户端感兴趣，你可以仅仅研究pc端和移动端代码。官方的测试服务器地址已经失效，所以我已经部署了一套TeamTalk服务器，并建立了几个测试账户可以供你使用： tangseng sunwukong zhubajie shaseng ================== xiaowang xiaoming xiaozhao xiaoli ================== 以上是账户名，密码随意。我改了下服务器端的代码，密码不进行校验的。你可以填写任意密码。 pc端设置方式：安卓端设置方式：关于ios端，目前由于服务器端的push_server没有部署，暂且就不提供了。我专门把pc端代码和安卓端代码提取出来供大家下载： pc端：下载地址：http://download.csdn.net/detail/analogous_love/9851833 开发工具：VS2013 安卓端：下载地址：http://download.csdn.net/detail/analogous_love/9851845 IDE使用Android-studio java 1.7 gradle 2.2.1 如果测试服务器连接不上，请通过微信 easy_coder 与我联系。

11 pc客户端源码分析

11 pc客户端源码分析 ——写在前面的话在要不要写这篇文章的纠结中挣扎了好久，就我个人而已，我接触windows编程，已经六七个年头了，尤其是在我读研的三年内，基本心思都是花在学习和研究windows程序上了。我很庆幸我当初学习windows程序走了一条正确的路线：先是学习常用的windows程序原理和基本API，再学习的mfc、wtl等一些常用的框架和类库，同时看了大量windows项目的源码，如金山卫士的开源代码、filezilla、电驴源码等等。个人觉得，基础真的很重要，拿windows开发来说，当你掌握了windows的程序的基本原理，我列一下大致范围： windows消息机制（消息如何产生、如何发送、如何处理，常见的消息有哪些、消息的优先级、如何自定义消息、窗体消息、常用控件消息） gdi原理（要熟悉gdi的各种对象，如画笔、画刷、字体、区域、裁剪、位图等，熟悉它们的API，熟悉各种gdi绘图API、当然最好也要熟悉一整套的gdi+的类，gdi与gdi+的区别） windows进程与线程的概念（进程的概念、如何创建、如何结束、跨进程如何通信；线程的创建与销毁、线程间的同步与资源保护，熟悉windows常用的线程同步对象：临界区、事件、互斥体、信号量等） windows内存管理（清晰地掌握一个进程地址空间的内存分布、windows堆的创建与管理等） dll技术（dll的生成、变量的导出、函数的导出、类的导出、如何查看dll导出哪些函数、隐式dll的加载、显示dll的加载、远程dll注入技术等） PE文件（一个PE文件的结构、有哪些节、如何修改、分别映射到进程地址空间的什么位置等） windows SEH（结构化异常处理） windows socket编程 windows读写文件技术（像CreateFile、WriteFile、GetFileSize等这些API应该熟练掌握、内存映射技术）当然很多必备的技术也不好归类到windows技术下面，比如socket编程，这涉及到很多网络的知识，比如tcp的三次握手，数据的收发等，还有就是各种字符编码的知识、以及之间的相互转换，又比如一系列的CRT函数及其对应的宽字符版本。当然如果你搞windows开发，一定要熟悉开发工具Visual Studio，熟悉其工程项目的大多数属性配置，而且要做到知其然也知其所以然。如果不是不能跨平台，我敢说VS是史上最好最强大的开发工具，没有之一！我已经有好几年年不做windows开发了，目前主要从事linux开发，但windows的很多设计思想真的很好，非常值得借鉴，而且从编码风格来说，虽然看起来有点怪异，但是非常规范和易懂。有了基础知识，你可以轻松地对工作中的一些问题给出解决方案，也能轻松阅读和使用市面上的那些库，比如，如果你深刻理解windows GDI，你不会在一个群里大喊，duilib某个属性为什么不起作用，你可以直接去阅读它的画法代码，如果是bug你可以改bug，如果只是你使用错误，你可以了解到正确的使用方法。所以基础这个东西，在短时间内，可能让你看不出与其他人的差别，但是从长远来看，它决定着你在技术上走的高度与深度。套用侯捷先生的一句话：勿在浮沙筑高台。 —— 正题上面简单地介绍了下，我个人学习windows程序设计的一些心得吧。扯的有点远了，让我们回到正题上来，来分析TeamTalk的源码吧。当然这篇文章与前面介绍的不一样，我们不仅介绍程序的正题设计思路，还会介绍一些有意义的细节，比如一些windows开发中常用的一些细节。一、程序功能我们来先看下TeamTalk pc客户端包括哪些功能：TeamTalk因为开发的初衷是用于企业内部的即时通讯软件，所以，不提供对外注册的功能，一个员工的加入一般是人事部门在后台管理系统来新增该员工信息。其功能包括登录、聊天、群聊和建讨论组，当然聊天过程中可以发文字、表情、图片和文件，还包括查看聊天记录和简单地查看某个员工的个人信息，业务功能其实不多的。下面是一些功能截图：二、编译方法与项目工程文件介绍 TeamTalk的pc客户端的下载地址是：https://github.com/baloonwj/TeamTalk 代码包括服务器端代码、pc端、mac端、安卓和IOS端，还有web端所有代码。 pc客户端代码的编译方法很简单：用VS2013打开win-client\solution目录下的teamtalk.sln，编译即可。你的VS版本至少要是VS2013，因为代码中大量使用了C++11的东西，VS2013以下版本是不支持C++11的语法的。当然，如果你是VS2015的话，可以参考这篇文章来进行修改和编译：http://www.07net01.com/linux/2017/01/1795569.html 打开teamtalk.sln之后，总共有10个解决方法，如下图所示：其中teamtalk是主工程，你应该将它设置成启动工程，编译完成之后就可以调试了。你可以自己配置服务器来连接进行调试，我也可以连接我的测试服务器，具体参见《TeamTalk源码分析（十） —— 开放一个TeamTalk测试服务器地址和几个测试账号》。下面先大致介绍一个各个工程的作用： Duilib是teamtalk使用的一款开源界面库，该界面库模仿web开发中的布局技术，使用xml文件来布局windows界面，并且在主窗口上绘制所有子控件，也就是所谓的directUI技术； GifSmiley是程序中用来解析和显示gif格式的图片的库，以支持gif图片的动画效果； httpclient功能是程序中使用的http请求库，登录前程序会先连接服务器的login_server以获得后续需要登录的msg_server的ip地址和端口号等信息，这里就是使用的http协议，同时聊天过程中收发的聊天图片与图片服务器msfs也使用http协议来收发这些图片； libogg是一个语音库，用来解析声音文件的，因为pc客户端可能会收到移动端的语音聊天，相比较传统的*.wav、.mp3、.wma，*.ogg格式的不仅音质高，而且音频文件的体积小，腾讯的QQ游戏英雄杀中的语音也是使用这个格式的。 libspeex是一个音频压缩库； Modules就是TeamTalk中使用的各种库了，展开来看下你就明白了： network是teamtalk使用的网络通信的代码，其实teamtalk pc端和服务器端使用的是同一套网络通信库，只不过如果服务器运行在linux下，其核心的IO复用模型是epoll，而pc客户端使用的IO复用模型是select； speexdec 也是和ogg格式相关的编码和解码器； teamtalk是主程序入口工程； utility包含了teamtalk中用到的一些工具类工程，比如sqlite的包装接口、md5工具类等。除了上面介绍的一些库以外，程序还使用了sqlite库、谷歌protobuf库、日志库yaolog等。关于yaolog可参见http://blog.csdn.net/gemo/article/details/8499692，这个日志库比较有意思的地方是可以单独打印出网络通信中的字节流的二进制形式，推荐一下，效果如下图所示（位于win-client\bin\teamtalk\Debug\log\socket.log文件中）：三、程序总体框架介绍整个程序使用了mfc框架来做一个架子，而所有的窗口和对话框都使用的是duilib，关于duilib网上有很多资料，这里不介绍duilib细节的东西了。一个mfc程序框架，使用起来也很简单，就是定义一个类集成mfc的CWinApp类，并改写其InitInstance()方法，mfc内部会替我们做好消息循环的步骤。TeamTalk相关的代码如下： //位于teamtalk.h中 class CteamtalkApp : public CWinApp { public: CteamtalkApp(); public: virtual BOOL InitInstance(); virtual BOOL ExitInstance(); private: /** * 创建用户目录 * * @return BOOL * @exception there is no any exception to throw. */ BOOL _CreateUsersFolder(); /** * 创建主窗口 * * @return BOOL * @exception there is no any exception to throw....

11 一种高性能网络游戏服务器架构设计

11 一种高性能网络游戏服务器架构设计网络游戏的结构分为客户端与服务器端，客户端采用2D绘制引擎或者3D绘制引擎绘制游戏世界的实时画面，服务器端则负责响应所有客户端的连接请求和游戏逻辑处理，并控制所有客户端的游戏画面绘制。客户端与服务器通过网络数据包交互完成每一步游戏逻辑，由于游戏逻辑是由服务器负责处理的，要保证面对海量用户登录时，游戏具有良好的流畅性和用户体验，优秀的服务器架构起到了关键的作用。 1 服务器架构设计 1.1 服务器架构分类服务器组的架构一般分为两种：第一种是带网关服务器的服务器架构；第二种是不带网关服务器的服务器架构，这两种方案各有利弊。在给出服务器架构设计之前，先对这两种设计方案进行详细的探讨。所谓网关服务器，其实是Gate服务器，比如LoginGate、GameGate等。网关服务器的主要职责是将客户端和游戏服务器隔离，客户端程序直接与这些网关服务器通信，并不需要知道具体的游戏服务器内部架构，包括它们的IP、端口、网络通信模型(完成端口或Epoll)等。客户端只与网关服务器相连，通过网关服务器转发数据包间接地与游戏服务器交互。同样地，游戏服务器也不直接和客户端通信，发给客户端的协议都通过网关服务器进行转发。 1.2 服务器架构设计根据网络游戏的规模和设计的不同，每组服务器中服务器种类和数量是不尽相同的。本文设计出的带网关服务器的服务器组架构如图1所示。本文将服务器设计成带网关服务器的架构，虽然加大了服务器的设计复杂度，但却带来了以下几点好处：（1）作为网络通信的中转站，负责维护将内网和外网隔离开，使外部无法直接访问内部服务器，保障内网服务器的安全，一定程度上较少外挂的攻击。（2）网关服务器负责解析数据包、加解密、超时处理和一定逻辑处理，这样可以提前过滤掉错误包和非法数据包。（3）客户端程序只需建立与网关服务器的连接即可进入游戏，无需与其它游戏服务器同时建立多条连接，节省了客户端和服务器程序的网络资源开销。（4）在玩家跳服务器时，不需要断开与网关服务器的连接，玩家数据在不同游戏服务器间的切换是内网切换，切换工作瞬间完成，玩家几乎察觉不到，这保证了游戏的流畅性和良好的用户体验。在享受网关服务器带来上述好处的同时，还需注意以下可能导致负面效果的两个情况：如何避免网关服务器成为高负载情况下的通讯瓶颈问题以及由于网关的单节点故障导致整组服务器无法对外提供服务的问题。上述两个问题可以采用“多网关” 技术加以解决。顾名思义，“多网关” 就是同时存在多个网关服务器，比如一组服务器可以配置三台GameGate。当负载较大时，可以通过增加网关服务器来增加网关的总体通讯流量，当一台网关服务器宕机时，它只会影响连接到本服务器的客户端，其它客户端不会受到任何影响。从图1的服务器架构图可以看出，一组服务器包括LoginGate、LoginServer、GameGate、GameServer、DBServer和MServer等多种服务器。LoginGate和GameGate就是网关服务器，一般一组服务器会配置3台GameGate，因为稳定性对于网络游戏运营来说是至关重要的，而服务器宕机等突发事件是游戏运营中所面临的潜在风险，配置多台服务器可以有效地降低单个服务器宕机带来的风险。另外，配置多台网关服务器也是进行负载均衡的有效手段之一。下面将对各种服务器的主要功能和彼此之间的数据交互做详细解释。（1）LoginGate LoginGate主要负责在玩家登录时维护客户端与LoginServer之间的网络连接与通讯，对LoginServer和客户端的通信数据进行加解密、校验。（2）LoginServer LoginServer主要功能是验证玩家的账号是否合法，只有通过验证的账号才能登录游戏。从架构图可以看出， DBServer和GameServer会连接LoginServer。玩家登录基本流程是，客户端发送账号和密码到LoginServer验证，如果验证通过，LoginServer会给玩家分配一个SessionKey，LoginServer会把这个SessionKey发送给客户端、DBServer和GameServer，在后续的选择角色以后进入游戏过程中，DBServer和GameServer将验证SessionKey合法性，如果和客户端携带的SessionKey不一致，将无法成功获取到角色或者进入游戏。（3）GameGate GameGate(GG)主要负责在用户游戏过程中负责维持GS与客户端之间的网络连接和通讯，对GS和客户端的通信数据进行加解密和校验，对客户端发往GS的用户数据进行解析，过滤错误包，对客户端发来的一些协议作简单的逻辑处理，其中包括游戏逻辑中的一些超时判断。在用户选择角色过程中负责维持DBServer与客户端之间的网络连接和通讯，对DBServer和客户端的通信数据进行加解密和校验，对客户端发往DBServer的用户数据做简单的分析。维持客户端与MServer之间的网络连接与通讯、加解密、数据转发和简单的逻辑处理等。（4）GameServer GameServer(GS)主要负责游戏逻辑处理。网络游戏有庞大世界观背景，绚丽激烈的阵营对抗以及完备的装备和技能体系。目前，网络游戏主要包括任务系统、声望系统、玩家PK、宠物系统、摆摊系统、行会系统、排名系统、副本系统、生产系统和宝石系统等。从软件架构角度来看，这些系统可以看着GS的子系统或模块，它们共同处理整个游戏世界逻辑的运算。游戏逻辑包括角色进入与退出游戏、跳GS以及各种逻辑动作(比如行走、跑动、说话和攻击等)。由于整个游戏世界有许多游戏场景，在该架构中一组服务器有3台GS共同负责游戏逻辑处理，每台游戏服务器负责一部分地图的处理，这样不仅降低了单台服务器的负载，而且降低了GS宕机带来的风险。玩家角色信息里会保持玩家上次退出游戏时的地图编号和所在GS编号，这样玩家再次登录时，会进入到上次退出时的GS。上面提到过，在验证账号之后，LoginServer会把这个SessionKey 发给GS，当玩家选择角色登录GS时，会把SessionKey一起发给GS，这时GS会验证SessionKey是否与其保存的相一致，不一致的话GS会拒绝玩家进入游戏。MServer的主要负责GS之间的数据转发以及数据广播，另外，一些系统也可以放到MServer上，这样也可以减轻GS的运算压力。（5）DBServer DBServer主要的功能是缓存玩家角色数据，保证角色数据能快速的读取和保存。由于角色数据量是比较大的，包括玩家的等级、经验、生命值、魔法值、装备、技能、好友、公会等。如果每次GS获取角色数据都去读数据库，效率必然非常低下，用DBServer缓存角色数据之后，极大地提高了数据请求的响应速度。 LoginServer会在玩家选组时把SessionKey发给DBServer，当玩家发送获取角色信息协议时会带上这个SessionKey，如果跟DBServer保存的SessionKey不一致，则DBServer会认为玩家不是合法用户，获取角色协议将会失败。另外，玩家选取角色正式进入游戏时，GS会给DBServer发送携带SessionKey的获取角色信息协议，这时DBServer同样会验证SessionKey的合法性。总之，只有客户端、DBServer和GS所保存的SessionKey一致，才能保证协议收到成功反馈。与DBServer通讯的服务器主要有GG，GS和LoginServer，DBServer与GG交互的协议主要包括列角色、创建角色、删除角色、恢复角色等，DBServer与GS交互的协议包括读取角色数据、保存角色数据和跳服务器等，DBServer与LoginServer交互的协议主要是用户登录协议，这时候会给DBServer发送SessionKey。（6）MServer 每一个组有一台MServer，主要负责维持3台GS之间数据的转发和数据广播。另外一些游戏系统也可能会放到MServer上处理，比如行会系统。 1.3 服务器交互的主要流程下面给出服务器之间数据通讯的主要流程从这些流程能看出各种服务器之间是如何数据交互和协同工作的。图2的流程说明了，在选角色过程中，客户端会把携带游戏账号和SessionKey的选角色协议发给GG，GG做一些简单处理之后转发给DBServer，DBServer要验证SessionKey的合法性，验证通过之后，DBServer会从角色信息缓冲区里取出该账户的所有角色信息发给客户端。这个过程在客户端的表现是，当选择好服务器组之后，客户端会直接显示该账号下的所有角色，之后就可以选择角色进入游戏了。图3的流程说明了，在玩家选角色正式进入游戏时，客户端会把携带游戏账号、角色ID和SessionKey的登录协议发给GG，GG做一些简单处理之后转发给GS。GS会验证SessionKey的合法性，验证通过之后，GS会把验证通过的结果发给客户端，同时GS给DBServer发获取角色数据的协议，这些角色数据是一个玩家所有的游戏数据，包括装备、技能等等。图4的流程说明了，在玩家游戏过程，客户端把逻辑协议(包括走、说话、跑、使用技能等)发给GG，GG完成加解密和简单逻辑处理之后转发给GS，GS负责这些协议的主要逻辑处理。 2 总结网络游戏服务器的架构设计已经成为当前网络游戏研究领域的热点，因为高性能服务器架构设计是一款网络游戏成功的关键。本文从实际应用出发，提出了一种高性能的服务器架构设计解决方案，并且详细探讨了各种服务器的功能，本文的最后给出了几个服务器之间数据通讯的关键流程，以图文并茂的方式解释各个服务器是如何协同工作的。

12 经典游戏服务器端架构概述

12 经典游戏服务器端架构概述架构的分析模型一. 讨论的背景现代电子游戏，基本上都会使用一定的网络功能。从验证正版，到多人交互等等，都需要架设一些专用的服务器，以及编写在服务器上的程序。因此，游戏服务器端软件的架构，本质上也是游戏服务器这个特定领域的软件架构。软件架构的分析，可以通过不同的层面入手。比较经典的软件架构描述，包含了以下几种架构： 1.运行时架构——这种架构关心如何解决运行效率问题，通常以程序进程图、数据流图为表达方式。在大多数开发团队的架构设计文档中，都会包含运行时架构，说明这是一种非常重要的设计方面。这种架构也会显著的影响软件代码的开发效率和部署效率。本文主要讨论的是这种架构。 2.逻辑架构——这种架构关心软件代码之间的关系，主要目的是为了提高软件应对需求变更的便利性。人们往往会以类图、模块图来表达这种架构。这种架构设计在需要长期运营和重用性高的项目中，有至关重要的作用。因为软件的可扩展性和可重用度基本是由这个方面的设计决定的。特别是在游戏领域，需求变更的频繁程度，在多个互联网产业领域里可以说是最高的。本文会涉及一部分这种架构的内容，但不是本文的讨论重点。 3.物理架构——关心软件如何部署，以机房、服务器、网络设备为主要描述对象。 4.数据架构——关心软件涉及的数据结构的设计，对于数据分析挖掘，多系统协作有较大的意义。 5.开发架构——关心软件开发库之间的关系，以及版本管理、开发工具、编译构建的设计，主要为了提高多人协作开发，以及复杂软件库引用的开发效率。现在流行的集成构建系统就是一种开发架构的理论。二. 游戏服务器架构的要素服务器端软件的本质，是一个会长期运行的程序，并且它还要服务于多个不定时，不定地点的网络请求。所以这类软件的特点是要非常关注稳定性和性能。这类程序如果需要多个协作来提高承载能力，则还要关注部署和扩容的便利性；同时，还需要考虑如何实现某种程度容灾需求。由于多进程协同工作，也带来了开发的复杂度，这也是需要关注的问题。功能约束，是架构设计决定性因素。一个万能的架构，必定是无能的架构。一个优秀的架构，则是正好把握了对应业务领域的核心功能产生的。游戏领域的功能特征，于服务器端系统来说，非常明显的表现为几个功能的需求： 1.对于游戏数据和玩家数据的存储 2.对玩家客户端进行数据广播把一部分游戏逻辑在服务器上运算，便于游戏更新内容，以及防止外挂。针对以上的需求特征，在服务器端软件开发上，我们往往会关注软件对电脑内存和CPU的使用，以求在特定业务代码下，能尽量满足承载量和响应延迟的需求。最基本的做法就是“时空转换”，用各种缓存的方式来开发程序，以求在CPU时间和内存空间上取得合适的平衡。在CPU和内存之上，是另外一个约束因素：网卡。网络带宽直接限制了服务器的处理能力，所以游戏服务器架构也必定要考虑这个因素。对于游戏服务器架构设计来说，最重要的是利用游戏产品的需求约束，从而优化出对此特定功能最合适的“时-空”架构。并且最小化对网络带宽的占用。 [图：游戏服务器的分析模型] 三. 核心的三个架构基于上述的分析模型，对于游戏服务端架构，最重要的三个部分就是，如何使用CPU、内存、网卡的设计： 1.内存架构：主要决定服务器如何使用内存，以保证尽量少的内存泄漏的可能，以及最大化利用服务器端内存来提高承载量，降低服务延迟。 2.调度架构：设计如何使用进程、线程、协程这些对于CPU调度的方案。选择同步、异步等不同的编程模型，以提高服务器的稳定性和承载量。同时也要考虑对于开发带来的复杂度问题。现在出现的虚拟化技术，如虚拟机、docker、云服务器等，都为调度架构提供了更多的选择。 3.通信模式：决定使用何种方式通讯。网络通讯包含有传输层的选择，如TCP/UDP；据表达层的选择，如定义协议；以及应用层的接口设计，如消息队列、事件分发、远程调用等。本文的讨论，也主要是集中于对以上三个架构的分析。四. 游戏服务器模型的进化历程最早的游戏服务器是比较简单的，如UO《网络创世纪》的服务端一张3.5寸软盘就能存下。基本上只是一个广播和存储文件的服务器程序。后来由于国内的外挂、盗版流行，各游戏厂商开始以MUD为模型，建立主要运行逻辑在服务器端的架构。这种架构在MMORPG类产品的不断更新中发扬光大，从而出现了以地图、视野等分布要素设计的分布式游戏服务器。而在另外一个领域，休闲游戏，天然的需要集中超高的在线用户，所以全区型架构开始出现。现代的游戏服务器架构，基本上都希望能结合承载量和扩展性的有点来设计，从而形成了更加丰富多样的形态。本文的讨论主要是选取这些比较典型的游戏服务器模型，分析其底层各种选择的优点和缺点，希望能探讨出更具广泛性，更高开发效率的服务器模型。分服模型一. 模型描述分服模型是游戏服务器中最典型，也是历久最悠久的模型。其特征是游戏服务器是一个个单独的世界。每个服务器的帐号是独立的，而且只用同一服务器的帐号才能产生线上交互。在早期服务器的承载量达到上限的时候，游戏开发者就通过架设更多的服务器来解决。这样提供了很多个游戏的“平行世界”，让游戏中的人人之间的比较，产生了更多的空间。所以后来以服务器的开放、合并形成了一套成熟的运营手段。一个技术上的选择最后导致了游戏运营方式的模式，是一个非常有趣的现象。 [图：分服模型] 二. 调度架构 1.单进程游戏服务器最简单的游戏服务器只有一个进程，是一个单点。这个进程如果退出，则整个游戏世界消失。在此进程中，由于需要处理并发的客户端的数据包，因此产生了多种选择方法： [图：单进程调度模型] a.同步-动态多线程：每接收一个用户会话，就建立一个线程。这个用户会话往往就是由客户端的TCP连接来代表，这样每次从socket中调用读取或写出数据包的时候，都可以使用阻塞模式，编码直观而简单。有多少个游戏客户端的连接，就有多少个线程。但是这个方案也有很明显的缺点，就是服务器容易产生大量的线程，这对于内存占用不好控制，同时线程切换也会造成CPU的性能损失。更重要的多线程下对同一块数据的读写，需要处理锁的问题，这可能让代码变的非常复杂，造成各种死锁的BUG，影响服务器的稳定性。 b.同步-多线程池：为了节约线程的建立和释放，建立了一个线程池。每个用户会话建立的时候，向线程池申请处理线程的使用。在用户会话结束的时候，线程不退出，而是向线程池“释放”对此线程的使用。线程池能很好的控制线程数量，可以防止用户暴涨下对服务器造成的连接冲击，形成一种排队进入的机制。但是线程池本身的实现比较复杂，而“申请”、“施放”线程的调用规则需要严格遵守，否则会出现线程泄露，耗尽线程池。 c.异步-单线程/协程：在游戏行业中，采用Linux的epoll作为网络API，以期得到高性能，是一个常见的选择。游戏服务器进程中最常见的阻塞调用就是网路IO，因此在采用epoll之后，整个服务器进程就可能变得完全没有阻塞调用，这样只需要一个线程即可。这彻底解决了多线程的锁问题，而且也简化了对于并发编程的难度。但是，“所有调用都不得阻塞”的约束，并不是那么容易遵守的，比如有些数据库的API就是阻塞的；另外单进程单线程只能使用一个CPU，在现在多核多CPU的服务器情况下，不能充分利用CPU资源。异步编程由于是基于“回调”的方式，会导致要定义很多回调函数，并且把一个流程里面的逻辑，分别写在多个不同的回调函数里面，对于代码阅读非常不理。——针对这种编码问题，协程(Coroutine)能较好的帮忙，所以现在比较流行使用异步+协程的组合。不管怎样，异步-单线程模型由于性能好，无需并发思维，依然是现在很多团队的首选。 d.异步-固定多线程：这是基于异步-单线程模型进化出来的一种模型。这种模型一般有三类线程：主线程、IO线程、逻辑线程。这些线程都在内部以全异步的方式运行，而他们之间通过无锁消息队列通信。 2.多进程游戏服务器多进程的游戏服务器系统，最早起源于对于性能问题需求。由于单进程架构下，总会存在承载量的极限，越是复杂的游戏，其单进程承载量就越低，因此开发者们一定要突破进程的限制，才能支撑更复杂的游戏。一旦走上多进程之路，开发者们还发现了多进程系统的其他一些好处：能够利用上多核CPU能力；利用操作系统的工具能更仔细的监控到运行状态、更容易进行容灾处理。多进程系统比较经典的模型是“三层架构”。在多进程架构下，开发者一般倾向于把每个模块的功能，都单独开发成一个进程，然后以使用进程间通信来协调处理完整的逻辑。这种思想是典型的“管道与过滤器”架构模式思想——把每个进程看成是一个过滤器，用户发来的数据包，流经多个过滤器衔接而成的管道，最后被完整的处理完。由于使用了多进程，所以首选使用单进程单线程来构造其中的每个进程。这样对于程序开发来说，结构清晰简单很多，也能获得更高的性能。 [图:经典的三层模型] 尽管有很多好处，但是多进程系统还有一个需要特别注意的问题——数据存储。由于要保证数据的一致性，所以存储进程一般都难以切分成多个进程。就算对关系型数据做分库分表处理，也是非常复杂的，对业务类型有依赖的。而且如果单个逻辑处理进程承载不了，由于其内存中的数据难以分割和同步，开发者很难去平行的扩展某个特定业务逻辑。他们可能会选择把业务逻辑进程做成无状态的，但是这更加加重了存储进程的性能压力，因为每次业务处理都要去存储进程处拉取或写入数据。除了数据的问题，多进程也架构也带来了一系列运维和开发上的问题：首先就是整个系统的部署更为复杂了，因为需要对多个不同类型进程进行连接配置，造成大量的配置文件需要管理；其次是由于进程间通讯很多，所以需要定义的协议也数量庞大，在单进程下一个函数调用解决的问题，在多进程下就要定义一套请求、应答的协议，这造成整个源代码规模的数量级的增大；最后是整个系统被肢解为很多个功能短小的代码片段，如果不了解整体结构，是很难理解一个完整的业务流程是如何被处理的，这让代码的阅读和交接成本巨高无比，特别是在游戏领域，由于业务流程变化非常快，几经修改后的系统，几乎没有人能完全掌握其内容。三. 内存架构由于服务器进程需要长期自动化运行，所以内存使用的稳定是首要大事。在服务器进程中，就算一个触发几率很小的内存泄露，都会积累起来变成严重的运营事故。需要注意的是，不管你的线程和进程结构如何，内存架构都是需要的，除非是Erlang这种不使用堆的函数式语言。 1.动态内存在需要的时候申请内存来处理问题，是每个程序员入门的时候必然要学会的技能。但是，如何控制内存释放却是一个大问题。在C/C++语言中，对于堆的控制至关重要。有一些开发者会以树状来规划内存使用，就是一般只new/delete一个主要的类型的对象，其他对象都是此对象的成员（或者指针成员），只要这棵树上所有的对象都管理好自己的成员，就不会出现内存漏洞，整个结构也比较清晰简单。 [图:对象树架构] 在Objective C语言中，有所谓autorealse的特性，这种特性实际上是一种引用计数的技术。由于能配合在某个调度模型下，所以使用起来会比较简单。同样的思想，有些开发者会使用一些智能指针，配合自己写的框架，在完整的业务逻辑调用后一次性清理相关内存。 [图:根据业务处理调度管理内存池] 在带虚拟机的语言中，最常见的是JAVA，这个问题一般会简单一些，因为有自动垃圾回收机制。但是，JAVA中的容器类型、以及static变量依然是可能造成内存泄露的原因。加上无规划的使用线程，也有可能造成内存的泄露——有些线程不会退出，而且在不断增加，最后耗尽内存。所以这些问题都要求开发者专门针对static变量以及线程结构做统一设计、严格规范。 2.预分配内存动态分配内存在小心谨慎的程序员手上，是能发挥很好的效果的。但是游戏业务往往需要用到的数据结构非常多，变化非常大，这导致了内存管理的风险很高。为了比较彻底的解决内存漏洞的问题，很多团队采用了预先分配内存的结构。在服务器启动的时候分配所有的变量，在运行过程中不调用任何new关键字的代码。这样做的好处除了可以有效减少内存漏洞的出现概率，也能降低动态分配内存所消耗的性能。同时由于启动时分配内存，如果硬件资源不够的话，进程就会在启动时失败，而不是像动态分配内存的程序一样，可能在任何一个分配内存的时候崩溃。然而，要获得这些好处，在编码上首先还是要遵循“动态分配架构”中对象树的原则，把一类对象构造为“根”对象，然后用一个内存池来管理这些根对象。而这个内存池能存放的根对象的数目，就是此服务进程的最大承载能力。一切都是在启动的时候决定，非常的稳妥可靠。...

13 游戏跨服架构进化之路

13 游戏跨服架构进化之路江贵龙，游戏行业从业8年，历任多款游戏项目服务器主程，服务器负责人。关注游戏服务器架构及优化，监控预警，智能运维，数据统计分析等。 1.背景虽然游戏市场竞争激烈，产品格局变动较大,但游戏产业一直处于稳步增长阶段，无论是在端游，页游，手游还是已经初露端倪的H5游戏。可以预见，游戏类型中，MMOARPG游戏仍然会是引领市场的主流趋势，贡献着大部分流水，市场上也仍然在不断涌现精品。研发团队对MMO游戏的探索从来未间断过,从付费模式的改变，到题材多元化，次时代的视觉效果，更成熟的玩法及数值体系，本文主要针对跨服玩法上的探索和实现做一些思考和分析。根据2016年《中国游戏产业报告》数据显示，随着游戏人口红利逐渐消失，获取用户的成本居高不下，几年来至少翻了十倍以上，目前平均导量成本页游为10~15元/人，手游在15~20元/人，其中IOS上成本30~50元/人,“洗”用户模式的效果正在变得微弱，用户流失严重。让我们先来看看滚服玩法的局限性，滚服洗量模式下存在着如下的弊端： 2.设计目标在上述背景下，一款长留存，低流失的精品游戏就成了平台方，渠道商，研发方追捧的目标，设想一下，如果让所有服务器玩家通过“跨域体系”实现自由畅通交互，在此基础上，玩家可以体验到前所未有的“国战系统”——7×24小时昼夜不停服的国家战争，随时开战；突破单地图承载容量极限的国战对决，带来真正万人国战的刺激体验，形成全区玩家能够互动的游戏社交环境。依托平台运营来打造一款真正意义上摆脱传统游戏运营模式的全新产品，为平台吸纳足够的市场份额，大幅降低流失率。我们的蓝图是开创“1=1000”模式，让所有玩家，身处一个服务器却如同同时存在于所有服务器，这种打破服务器屏障的设定，杜绝了游戏出现“被迫滚服”现象出现，玩家不用再担心鬼服人烟稀少，不用担心交易所一无所有，所有的数据共享，让玩家轻松Hold住全世界。 3.进化过程项目组那时面临的现状是游戏各种档期计划、宣传推广安排都已经就绪，两个月后该独代项目要在腾讯平台按时上线，开发不能因引入跨服机制而导致所有完成度100%的功能都要去分别去增加跨服的支持，而技术人员在跨服功能开发这块经验的积累上也不充分。技术小组分析了时下项目的现状，跨服业务需求及现有的框架结构，明确了几点原则： 1.为了实现跨服，游戏代码从底层架构到上层业务逻辑的代码改动成本尽量降低 2.业务逻辑里尽量少关心或者不用关心是否在本服或者跨服，降低开发人员的跨服功能开发复杂度，提高开发的效率，缩短开发周期。那么，我们需要解决哪些技术疑点呢？ 3.1 客户端直连还是服务器转发 a)如果直连，那么，跨服玩法时客户端要维持两个连接，在跨服里，要模拟玩家登陆，绑定session的过程，游戏服和跨服两边要同时维护两份玩家数据，如何做到数据的同步？跨服要暴露给玩家，需要有公网访问IP和端口。对客户端连接管理来说较复杂。 b)如果通过大区服务器消息转发，那么，服务器之间做RPC通信，连接管理，消息需额外做一步跳转，性能能否满足？跨不跨服，对于客户端来说透明，跨服隐藏在大区之后，更加安全，不需再浪费公网IP和端口。综合考虑了下，采用了B方案。 3.1.1 RPC框架设计需求那么，我们需要先准备一套高性能轻量级的RPC框架。业界有很多典型的RPC框架，比如Motan、Thrift、gRPC、Hessian、Hprose，Wildfly,Dubbo,DubboX，为什么我们还要重复造轮子呢？综合考虑了下，框架要满足以下几点业务需求: 1.该框架要简单、易用、支持高并发的跨服请求； 2.根据现有的游戏服务器框架，会有很多定制化的场景； 3.通过NIO TCP长连接获取服务，但无需跨语言的需求； 4.支持同步请求，异步请求，异步回调CallBack； 5.要有服务发现的功能，要有Failfast能力； 6.具备负载均衡，分组等路由策略；基于有以上的诉求，结合团队以前的开发经验，于是就决定自主研发。我们选用的技术栈有 Netty、Apache Commons Pool、Redis等。框架分为服务提供方(RPC Server)、服务调用方(RPC Client)、注册中心(Registry)三个角色，基于Redis为服务注册中心，通过其Pub/Sub实现服务动态的注册和发现。Server 端会在服务初始化时向Registry 注册声明所提供的服务；Client 向 Registry 订阅到具体提供服务的 Server 列表，根据需要与相关的 Server 建立连接，进行 RPC 服务调用。同时，Client 通过 Registry 感知 Server 的状态变更。三者的交互关系如右图：图1、RPC框架三者关系 3.1.2 RPC请求的有序性连接池在设计过程中，比较重要的是要考虑请求的顺序性，也就是先请求的先完成。如果玩家的跨服请求通过不同的RPC连接并发执行，就有可能单个玩家请求因错序而导致逻辑矛盾，比如玩家移动，见图2：图2、玩家移动玩家移动是很频繁的，如果A请求让玩家从位置1移动到位置2，B请求从位置2移动到位置3，有可能B请求先被跨服接收处理，这就会产生逻辑问题。那么，如何做到请求的有序性呢？其本质是让同一份数据的访问能串行化，方法就是让同一个玩家的跨服请求通过同一条RPC连接执行，加上逻辑上的有效性验证，如图3所示： 3.1.3 同步RPC实现细节限于篇幅，这里只讲同步请求的RPC连接池实现。同步请求的时序图如图4：上图为进入跨服战场的一次同步请求,场景切换控制器StageControllAction发起进入跨服战场的请求applyChangeByBattlefield(),场景管理器StageControllManager首先要调用登录跨服的RPC请求GameRpcClient.loginCrossServer(LoginCrossServerReq)，跨服RPC请求的工作流是这样的: public LoginCrossServerAck loginCrossServer(LoginCrossServerReqreq)throws ServiceException { //从连接池中获取一个连接 RpcClient rpcClient = rpcClientPool.getResource(req.getRoleId()); try { //发起一次同步RPC请求 RpcMsg msg = rpcClient.sendWithReturn(MsgType.RPC_LoginCrossServerReq, req); return JSON.parseObject(msg.getContent(), LoginCrossServerAck....

2 网络游戏服务器开发框架设计介绍

2 网络游戏服务器开发框架设计介绍在开发过程中，会先有一份开发大纲或是一份策划案，但是这些在我的开发中可能不会有，或者即使有，也很有可能是我随性写下来的，但是我会尽可能写好它。网络通信层，我会放到单独的SOCKET编程中去讲解，这里的主题是游戏的架构设计以及系统模块间的协同工作。所以，在这里假设所有的网络层都已经开发完毕，具体的网络层开发代码不会再这里出现，因为这需要很多年的开发经验，或者对SOCKET有一定的了解才能够讲述清楚或理解，所以我不想再我还没有足够的把握之前去说这样的问题，主要问题是不想让人说我不专业；另一方面是不希望给没有接触过SOCKET编程或了解不多的人带来误导或困扰。在开发游戏具体功能前，第一个要做的就是理清系统功能，这里的系统功能并不是具体的游戏功能，而是从软件角度出发的，行业内部称其为分布式服务器开发，讲的是如何构建一个可移植、可分布到不同网络机器独立或依赖运行的应用程序。本系列开发教程是我个人游戏经历和工作历程的一个沉淀，也是我个人主观的一个未实现版本，在这里，我希望它可以以教程的方式存在，并去按部就班的一步一步实现出来。所有的源码代码都是开源的，我不会有丝毫保留，这样做的目的是方便很多像我一样的游戏狂热者入门无门，另一方面也是希望前辈们可以对我的错误进行指正。下面将具体描述服务器的划分以及功能实现。此系列开发教程，总共将分为10个模块：它们分别为 LoginGate服务器、 LoginServer服务器、 GameGate服务器、 GameServer服务器、 IMServer服务器、 AIServer服务器、 CenterServer服务器、 BillingServer服务器、 WebServices服务器、 DBServer服务器。 1 LoginGate：登陆网关服务器，将所有的LoginServer服务器地址暴露给最终用户，每个LoginGate服务可以挂接n个LoginServer，将最终用户的所有请求转发给目标LoginServer。当最终用户通过此服务完成登陆后，会与该服务断开连接，断开连接前，服务器会将数据上报给GameGate服务。 2 LoginServer：登陆服务器，仅作于内部服务与LoginGate进行连接，所有的最终用户请求由LoginGate过滤后，转发过来进行处理。与LoginGate的所有通信都是明文，即未加密数据。 3 **GameGate：**游戏网关服务器，与LoginGate协作完成最终用户的登陆过程，每一个服务会连接到唯一一个LoginGate服务上进行注册，LoginGate会将以完成验证登陆的用户信息同步到所有已注册成功的GameGate上，根据注册不同的GameGate类型信息，LoginGate会发生不同的通过认证的最终用户信息。 GameGate挂接n个GameServer服务到自身，此服务将所有注册到自身的GameServer信息发送给最终用户，提供用户选择具体的区或线路进行游戏（区和线路在不同的游戏设定中有不同的定义），在这里区的定义对应的是GameGate，每一个GameGate可以表示物理或逻辑上的多个游戏分区，每个分区由至少一个GameServer组成；线路定义为GameServer，每一个GameServer代表一条线路，线路之间互相不可见，但是可以通过IMServer进行一些扩展通信，例如公会、好友、聊天等服务可以设置透明通信或隐藏通信。透明通信由IMServer向目标GameServer转发请求，并进行处理；隐藏通信仅在当前GameServer进行处理，不会做跨越性操作。 4 GameServer：游戏服务器，作为内部服务与GameGate协作处理最终用户的请求，这个服务主要处理游戏逻辑，例如战斗。此服务启动后，会根据配置文件的配置信息进行相应的服务注册，该服务启动成功后，会注册到GameGate和IMServer、AIServer服务器，它们分别提供最终用户游戏、交友、公会、聊天和智能体的移动、创建、销毁等服务。作为整个游戏的核心处理服务器，会处理掉大部分的用户交互服务请求，只有在不能处理的情况下，才会请求其它服务协同处理。 5 IMServer：IM通信服务器，全称InstantMessaging（译为即时通讯），ICQ、MSN、QQ等聊天工具都属于此范畴。此服务的作用是提供物理或逻辑不同位置的GameServer上的最终用户通讯的一个媒介，用户成功登陆GameServer时，会将自己的好友、公会信息注册到此服务上，当需要跨GameServer服务时，共IMServer使用。此服务主要提供聊天、交友、交易、公会等社交类行为服务，该服务可以直接或间接的与最终用户进行通信，但最终用户无法直接与该服务进行通信，比如请求操作，所有的用户操作都由GameServer转发，IMServer可以选择性的直接反馈最终用户或通过GameServer反馈。 6 **AIServer：**人工智能服务器，全称Artificial Intelligence（译为人工智能），例如现代服务性机器人（自动吸尘器、智能探测仪、智能防爆装置等）都属于人工智能范畴。这里的人工智能主要体现在游戏中的NPC、MONSTER等有行为表现物体。GameServer启动后会连接到此服务进行注册，并获取所需智能体的信息，以反馈给最终用户，并最终显示在用户应用程序中。该服务主要控制智能体的移动、攻击、创建、销毁等行为，另外包括在战斗中或非战斗状态下的行为，比如游走在街道上的商品小贩；在搜索到攻击目标时，主动或召集附近的战斗单位一起攻击用户，都属于该服务的工作内容。 7 **CenterServer：**中心服务器，用于监控、更新已注册到此服务的状态，比如电信1区（傲视天地）服务器的运行状态等。此服务主要是管理除自身以外的所有服务程序的运行状态，以及时反馈给技术活运维人员。 8 **BillingServer：**计费服务器，用于计算用户在游戏中的消耗、增值；比如XX在游戏中购买了一个双倍经验卡，消耗10金币，或者用户通过网站形式进行充值，都会通过该服务反馈给用户最终结果。 9 **WebServices：**网站服务，主要用于网站与游戏之间的交互。比如XX用户通过网站进行充值服务，充值成功后，通知计费服务以响应用户操作；或通过网站进行游戏激活、礼品领取等，都需要此服务与游戏应用程序进行交互，以体现实时的变化。 10 DBServer：用于全局数据维护，例如更新、查询、插入、删除操作；这些数据包含用户账号、充值、代金卷、点卡、月卡以及游戏中需要用到的角色数据。服务器整体架构图分布示意图： LoginGate内部运行示意图： LoginServer内部运行示意图：由于其它服务器模块程序的内部图与这两个类似，所以就不在这个上面耽搁太多时间，下一篇将讲述具体的游戏开发，网络库使用的是开源库ACE，下载地址http://download.dre.vanderbilt.edu/previous_versions/ACE-5.8.0.zip。

3 游戏后端开发需要掌握的知识

3 游戏后端开发需要掌握的知识这篇是从网上找到牛人的博客总结下来的：实战方面：（1）两种在知名IT公司使用的游戏服务器架构设计点击图片可以放大 1 各个服务器的功能以及作用： **CenterServer服务器管理器：**管理所有的服务器，分配服务器的端口，负责全局的逻辑（管理），对各功能服务器和场景服务器提供服务，保证服务器的合法性 DBserver角色档案缓冲服务器 GameServer逻辑服务器：玩家的实时同步在里面实现 GateServer网关服务器：负责消息转发 **LoginServer登录服务器：**连接账号数据 2 不带负载均衡的和带负载均衡：相同点：与带负载均衡大概的架构相同不同点：不带负载均衡 Gate Server 和Game Server之间是一对一的关系，每个Game Server能容纳的玩家数量是一定的，正常情况下一个Gate Server的对应一个Game Server实时在线人数能达到3000人，一旦达到峰值，就会找下一个对应的Game Server。各个Gate Server服务器之间是不通信的带负载均衡一个Gate Server的对应多个Game Server 各个GateServer之间可以互相通信，而且还可以随意扩展，通过配置文件可以实现配置 3 服务器的工作过程：用户从客户端选择游戏服务器列表登录到Login Server,在登陆的过程中先去平台服务器进行账号的验证验证通过后会通知Login Server，然后Login Server会把验证的消息发送到center Server，请求其中的Gate Server的地址和端口 Center Server会找一个可用的Gate Server信息,发送回LoginServer Login Server会把消息发送给客户端客户端断开与Login Server的连接，然后与Game Server 连接进入游戏场景中

4 关于游戏服务端架构的整理

4 关于游戏服务端架构的整理一个大型的网落游戏服务器应该包含几个模块：网络通讯，业务逻辑，数据存储，守护监控（不是必须）。其中业务逻辑可能根据具体需要，又划分为好几个子模块。这里说的模块可以指一个进程，或者一个线程方式存在，本质上就是一些类的封装。对于服务器的并发性，要么采用单进程多线程，要么采用多进程单线程的方式，说说两种方式的优缺点：一、单进程多线程的服务器设计模式，只有一个进程，但一个进程包好多个线程：网络通讯层，业务逻辑，数据存储，分别在独立的线程中，无守护进程。优点：数据共享和交换方便，使用全局变量或者单例就可以，数据存储方便。单进程，服务器框架结构相对简单，编码容易。缺点：所有功能只能在单个物理服务器上，不能做成分布式。不方便监控各个线程状态，容易死锁一个线程出错，例如内存非法访问，栈空间被破坏，那么服务器进程就退出，所有玩家掉线，影响大。二、多进程单线程的服务器设计模式，多个进程，每个进程只有一个线程：网路通讯，业务逻辑，数据存储，守护进程，分别在不同的进程。优点：各个进程可以分布在不同的物理服务器上，可以做成分布式的服务器框架，例如可以将数据存储单独放到一个物理服务器上，供几个区的服务器使用。将网络通讯进程独立出来，甚至可以做成导向服务器，实现跨服战。可以通过守护进程监控其它进程状态，例如有进程死掉，马上重启该进程，或者某个进程cpu使用率接近100%（基本可以判断是某个逻辑死循环了）, 强制kill掉该进程，然后重启。单个服务器进程异常退出，只要不是网络通讯进程（一般这个都会比较稳定，没什么逻辑），那么就可以及时被守护进程重启，不会造成玩家掉线，只会造成在1-2秒内，某个逻辑功能无法使用，甚至玩家都感觉不到。服务器通过共享内存进行数据交换，那么如果其中一个服务器死掉，数据还在，可以保护用户数据（当然多线程也可以使用共享内存）。并发性相对多线程要高点。缺点：不方便使用互斥锁，因为进程切换的时间片远远于线程切换，对于一个高并发服务器是无法允许这么高时间片的切换代价的。因此必须设计好服务器的框架，尽量避开使用锁机制，但要保证数据不出错。多进程编程，在各个进程间会有很多通讯，跨服务器进程的异步消息较多，会让服务器的编码难度加大。下面先按照一个游戏的功能，将服务器的功能分块框架画出来: 点击图片可放大以上是一个游戏服务器最基础的功能框架图，接下来要做的就是设计服务器的框架了 1. 早期的MMORPG服务器结构 Client<->GameServer<->DB 所有业务数据集中处理优点: 简单,快速开发缺点: 所有业务放在一起,系统负担大大增加.一个bug可能导致整个服务器崩溃,造成所有玩家掉线甚至丢失等严重后果。开服一刹那,所有玩家全部堆积在同一个新手村.-»»卡，客户端卡（同屏人数过多渲染/广播风暴）服务器卡(处理大量同场景消息/广播风暴) 2. 中期-用户分离集群式 GameServe1 Client | DB GameServer2 玩家不断增多->分线->程序自动或玩家手动选择进入 **缺点:**运营到后期,随着每条线玩家的减少, 互动大大减少。 3. 中后期数据分离集群式按地图划分服务器,当前主流新手村问题：《天龙八部》提出了较好的解决方案，建立多个平行的新手村地图，一主多副，开服时尽可能多的同时容纳新用户的涌入，高等级玩家从其它地图回新手村只能到达主新手村。 4. 当前主流的网络游戏架构注：在GateServer和CenterServer之间是有一条TCP连接的。而GameServer和LogServer之间的连接可以是UDP连接。这是有一个大概的图，很多地方需要细化。 **GateServer:**网关服务器,AgentServer、ProxyServer 优点: 作为网络通信的中转站，负责维护将内网和外网隔离开，使外部无法直接访问内部服务器，保障内网服务器的安全，一定程度上较少外挂的攻击。网关服务器负责解析数据包、加解密、超时处理和一定逻辑处理，这样可以提前过滤掉错误包和非法数据包。客户端程序只需建立与网关服务器的连接即可进入游戏，无需与其它游戏服务器同时建立多条连接，节省了客户端和服务器程序的网络资源开销。在玩家跳服务器时，不需要断开与网关服务器的连接，玩家数据在不同游戏服务器间的切换是内网切换，切换工作瞬问完成，玩家几乎察觉不到，这保证了游戏的流畅性和良好的用户体验。缺点: 网关服务器成为高负载情况下的通讯瓶颈问题由于网关的单节点故障导致整组服务器无法对外提供服务的问题解决： **多网关技术。**顾名思义，“多网关” 就是同时存在多个网关服务器，比如一组服务器可以配置三台GameGme。当负载较大时，可以通过增加网关服务器来增加网关的总体通讯流量，当一台网关服务器宕机时，它只会影响连接到本服务器的客户端，其它客户端不会受到任何影响。 **DCServer:**数据中心服务器。主要的功能是缓存玩家角色数据，保证角色数据能快速的读取和保存 CenterServer:全局服务器/中心服务器,也叫WorldServer. 主要负责维持GameServer之间数据的转发和数据广播。另外一些游戏系统也可能会放到Center上处理，比如好友系统,公会系统。改进: 将网关服务器细化为LogingateServer和多个GameGateServer. 5. 按业务分离式集群由于网络游戏存在很多的业务，如聊天，战斗，行走，NPC等，可以将某些业务分到单独的服务器上。这样每个服务器的程序则会精简很多。而且一些大流量业务的分离,可以有效的提高游戏服务器人数上限。优点：业务的分离使得每种服务器的程序变的简单，这样可以降低出错的几率。即使出错，也不至于影响到每一个整个游戏的进行,而且通过快速启动另一台备用服务器替换出错的服务器。业务的分离使得流量得到了分散，进而相应速度回得到提升。大部分业务都分离了成了单独的服务器,所以可以动态的添加，从而提高人数上限。改进：甚至可以将登陆服务器细化拆分建角色,选择角色服务器 6. 一种简单实用的网络游戏服务器架构下图中每个方框表示一个独立的进程APP组件，每个服务进程如果发生宕机会影响部分用户，整体服务但不会全部中断。在宕机进程重启后，又可以并入整体，全部服务得以继续。 **gls：**game login server，游戏登录服务器，某种程序上，其不是核心组件，gls调用外部的接口，进行基本的用户名密码认证。此外需要实现很多附属的功能：登录排队（对开服非常有帮助），GM超级登录通道（GM可以不排队进入游戏），封测期间激活用户控制，限制用户登录，控制客户端版本等。 **db：**实质上是后台sql的大内存缓冲，隔离了数据库操作，比较内存中的数据，只把改变的数据定时批量写入sql。系统的算法，开发稳定性都要求非常高。 **center：**所有组件都要在这里注册，在线玩家的session状态都在这里集中存放，和各组件有心跳连接。所有对外的接口也全部通过这里。角色入口：玩家登录游戏后的选择角色 **gs：**game server，最核心组件，同一地图，所有游戏逻辑相关的功能，都在这里完成。 **gate：**建立和用户的常链接，主要作sockt转发，屏蔽恶意包，对gs进行保护。协议加密解密功能，一个gate共享多个gs，降低跳转地图连接不上的风险。 **IM，关系，寄售：**表示其它组件，负责对应的跨地图发生全局的游戏逻辑。 7.另一个架构图 1- 这是一条WebService的管道，在用户激活该区帐号，或者修改帐号密码的时候，通过这条通道来插入和更新用户的帐号信息。 2- 这也是一条WebService管道，用来获取和控制用户该该组内的角色信息，以及进行付费商城代币之类的更新操作。 3- 这是一条本地的TCP/IP连接，这条连接主要用来进行服务器组在登陆服务器的注册，以及登陆服务器验证帐户后，向用户服务器注册帐户登陆信息，以及进行对已经登陆的帐户角色信息进行操作（比如踢掉当前登陆的角色），还有服务器组的信息更新（当前在线玩家数量等）。 4- 这也是一条本地TCP/IP连接，这条连接用来对连接到GameServer的客户端进行验证，以及获取角色数据信息，还有传回GameServer上角色的数据信息改变。 5- 这条连接也是一条本地的TCP/IP连接，它用来进行公共信息服务器和数个游戏服务器间的交互，用来交换一些游戏世界级的信息（比如公会信息，跨服组队信息，跨服聊天频道等）。 6- 这里的两条连接，想表达的意思是，UserServer和GameServer的Agent是可以互换使用的，也就是玩家进入组内之后，就不需要再切换 Agent。如果不怕乱套，也可以把登陆服务器的Agent也算上，这样用户整个过程里就不需要再更换Agent，减少重复连接的次数，也提高了稳定性。（毕竟连接次数少了，也降低了连不上服务器的出现几率）在这个架构里面，**GameServer实际上是一个游戏逻辑的综合体，**里面可以再去扩展成几个不同的逻辑服务器，通过PublicServer进行公共数据交换。...

5 各类游戏对应的服务端架构

5 各类游戏对应的服务端架构类型一：卡牌、跑酷等弱交互服务端卡牌跑酷类因为交互弱，玩家和玩家之间不需要实时面对面PK，打一下对方的离线数据，计算下排行榜，买卖下道具即可，所以实现往往使用简单的 HTTP服务器：登录时可以使用非对称加密（RSA, DH），服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信，并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和时间戳以及服务端自己的私钥计算得到。**用模仿 TLS的行为，**来保证多次 HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。每局开始时，访问一下，请求一下关卡数据，玩完了又提交一下，验算一下是否合法，获得什么奖励，数据库用单台 MySQL或者 MongoDB即可，后端的 Redis做缓存（可选）。如果要实现通知，那么让客户端定时15秒轮询一下服务器，如果有消息就取下来，如果没消息可以逐步放长轮询时间，比如30秒；如果有消息，就缩短轮询时间到10秒，5秒，即便两人聊天，延迟也能自适应。此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余，这类游戏因为逻辑简单，玩家之间交互不强，使用 HTTP来开发的话，开发速度快，调试只需要一个浏览器就可以把逻辑调试清楚了。类型2：第一代游戏服务器 1978 1978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序《MUD1》，在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家，甚至包括国外的玩家。《MUD1》程序的源代码在 ARPANET共享之后出现了众多的改编版本，至此MUD才在全世界广泛流行起来。不断完善的 MUD1的基础上产生了开源的 MudOS（1991），成为众多网游的鼻祖： MUDOS采用 C语言开发，因为玩家和玩家之间有比较强的交互（聊天，交易，PK），MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处****理，主线程每隔1秒钟更新一次所有对象（网络收发，更新对象状态机，处理超时，刷新地图，刷新NPC）。游戏世界采用房间的形式组织起来，每个房间有东南西北四个方向可以移动到下一个房间，由于欧美最早的网游都是地牢迷宫形式的，因此场景的基本单位被称为 “房间”。 MUDOS使用一门称为LPC的脚本语言来描述整个世界（包括房间拓扑，配置，NPC，以及各种剧情）。游戏里面的高级玩家（巫师），可以不断的通过修改脚本来为游戏添加房间以及增加剧情。早年 MUD1上线时只有17个房间，Roy Trubshaw毕业以后交给他的师弟 Richard Battle，在 Richard Battle手上，不断的添加各种玩法到一百多个房间，终于将 MUD发扬光大。用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。比如 1995年国内第一款 MUD游戏《侠客行》，你敲入*：”go east”，*游戏就会提示你：“*后花园 - 这里是归云庄的后花园，种满了花草，几个庄丁正在浇花。此地乃是含羞草生长之地。这里唯一的出口是 north。这里有：花待阿牧（A mu），还有二位庄丁（Zhuang Ding）”，然后你继续用文字操作，查看阿牧的信息：“look a mu”，*系统提示：“*花待阿牧（A mu）他是陆乘风的弟子，受命在此看管含羞草。他看起来三十多岁，生得眉清目秀，端正大方，一表人才。他的武艺看上去【不是很高】，出手似乎【极轻】”。*然后你可以选择击败他获得含羞草，但是你吃了含羞草却又可能会中毒死亡。在早期网上资源贫乏的时候，这样的游戏有很强的代入感。用户数据保存在文件中，每个用户登录时，从文本文件里把用户的数据全部加载进来，操作全部在内存里面进行，无需马上刷回磁盘。用户退出了，或者每隔5分钟检查到数据改动了，都会保存到磁盘。这样的系统在当时每台服务器承载个4000人同时游戏，不是特别大的问题。从1991年的 MUDOS发布后，全球各地都在为他改进，扩充，退出新版本，随着 Windows图形机能的增强。1997游戏《UO》在 MUDOS的基础上为角色增加的x,y坐标，为每个房间增加了地图，并且为每个角色增加了动画，形成了第一代的图形网络游戏。因为游戏内容基本可以通过 LPC脚本进行定制，所以MUDOS也成为名副其实的第一款服务端引擎，引擎一次性开发出来，然后制作不同游戏内容。后续国内的《万王之王》等游戏，很多都是跟《UO》一样，直接在 MUDOS上进行二次开发，加入房间的地图还有角色的坐标等要素，该架构一直为国内的第一代 MMORPG提供了稳固的支持，直到 2003年，还有游戏基于 MUDOS开发。虽然后面图形化增加了很多东西，但是这些MMORPG后端的本质还是 MUDOS。随着游戏内容的越来越复杂，架构变得越来越吃不消了，各种负载问题慢慢浮上水面，于是有了我们的第二代游戏服务器。类型3：第二代游戏服务器 2003 2000年后，网游已经脱离最初的文字MUD，进入全面图形化年代。最先承受不住的其实是很多小文件，用户上下线，频繁的读取写入用户数据，导致负载越来越大。随着在线人数的增加和游戏数据的增加，服务器变得不抗重负。同时早期 EXT磁盘分区比较脆弱，稍微停电，容易发生大面积数据丢失。因此第一步就是拆分文件存储到数据库去。此时游戏服务端已经脱离陈旧的 MUDOS体系，各个公司在参考 MUDOS结构的情况下，开始自己用 C再重新开发自己的游戏服务端。并且脚本也抛弃了 LPC，采用扩展性更好的 Python或者 Lua来代替。由于主逻辑使用单线程模型，随着游戏内容的增加，传统单服务器的结构进一步成为瓶颈。于是有人开始拆分游戏世界，变为下面的模型：游戏服务器压力拆分后得以缓解，但是两台游戏服务器同时访问数据库，大量重复访问，大量数据交换，使得数据库成为下一个瓶颈。于是形成了数据库前端代理（DB Proxy），游戏服务器不直接访问数据库而是访问代理，再有代理访问数据库，同时提供内存级别的cache。早年 MySQL4之前没有提供存储过程，这个前端代理一般和 MySQL跑在同一台上，它转化游戏服务器发过来的高级数据操作指令，拆分成具体的数据库操作，一定程度上代替了存储过程：但是这样的结构并没有持续太长时间，因为玩家切换场景经常要切换连接，中间的状态容易错乱。而且游戏服务器多了以后，相互之间数据交互又会变得比较麻烦，于是人们拆分了网络功能，独立出一个网关服务 Gate（有的地方叫 Session，有的地方叫 LinkSvr之类的，名字不同而已）：把网络功能单独提取出来，让用户统一去连接一个网关服务器，再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管进行交换。这样类型的服务器基本能稳定的为玩家提供游戏服务，一台网关服务1-2万人，后面的游戏服务器每台服务5k-1w，依游戏类型和复杂度不同而已，图中隐藏了很多不重要的服务器，如登录和管理。这是目前应用最广的一个模型，到今天仍然很多新项目会才用这样的结构来搭建。人都是有惯性的，按照先前的经验，似乎把 MUDOS拆分的越开性能越好。于是大家继续想，网关可以拆分呀；基础服务如聊天交易可以拆分呀；还可以提供web接口，数据库可以拆分呀，于是有了下面的模型：...