游戏服务端架构 介绍

游戏服务端架构 介绍

端游、手游服务端经常使用的架构是什么样的？

http://www.zhihu.com/question/29779732

根据知乎问答文章整理而成。

做者：韦易笑

谢邀，手游页游和端游的服务端本质上没区别，区别的是游戏类型。
类型1：卡牌、跑酷等弱交互服务端
卡牌跑酷类由于交互弱，玩家和玩家之间不须要实时面对面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接口，数据库能够拆分呀，因而有了下面的模型：

这样的模型好用么？确实有成功游戏使用相似这样的架构，而且发挥了它的性能优点，好比一些大型 MMORPG。可是有两个挑战：每增长一级服务器，状态机复杂度可能会翻倍，致使研发和找bug的成本上升；而且对开发组挑战比较大，一旦项目时间吃紧，开发人员经验不足，很容易弄挂。
好比我见过某上海一线游戏公司的一个 RPG上来就要上这样的架构，我看了下他们团队成员的经验，问了下他们的上线日期，劝他们用前面稍微简单一点的模型。人家自信得很，认为有成功项目是这么作的，他们也要这么作，本身很想实现一套。因而他们义无反顾的开始编码，项目作了一年多，而后，就没有而后了。
现今在游戏成功率不高的状况下，一开始上一套比较复杂的架构须要考虑投资回报率，好比你的游戏上线半年内 PCU会去到多少？若是一个 APRG游戏，每组服务器5千人都到不了的话，那么选择一套更为贴近实际状况的结构更为经济。即便后面你的项目真的超过5千人朝着1万人目标奔的话，相信那个时候你的项目已经挣大钱了 ，你数着钱加着班去逐步迭代，一次次拆分它，相信内心也是乐开花的。
上面这些类型基本都是从拆分 MUDOS开始，将 MUDOS中的各个部件从单机一步步拆成分布式。虽然今天任然不少新项目在用上面某一种相似的结构，或者本身又作了其余热点模块的拆分。由于他们本质上都是对 MUDOS的分解，故将他们概括为第二代游戏服务器。
类型4：第三代游戏服务器 2007
从魔兽世界开始无缝世界地图已经深刻人心，比较以往游戏玩家走个几步还须要切换场景，每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。因而对于 2005年之后的大型 MMORPG来讲，无缝地图已成为一个标准配置。比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了：

每台 Node服务器用来管理一块地图区域，由 NodeMaster（NM）来为他们提供整体管理。更高层次的 World则提供大陆级别的管理服务。这里省略若干细节服务器，好比传统数据库前端，登陆服务器，日志和监控等，通通用 ADMIN归纳。在这样的结构下，玩家从一块区域走向另一块区域须要简单处理一下：

玩家1彻底由节点A控制，玩家3彻底由节点B控制。而处在两个节点边缘的2号玩家，则同时由A和B提供服务。玩家2从A移动到B的过程当中，会同时向A请求左边的状况，并向B请求右边的状况。可是此时玩家2仍是属于A管理。直到玩家2完全离开AB边界很远，才完全交由B管理。按照这样的逻辑将世界地图分割为一块一块的区域，交由不一样的 Node去管理。
对于一个 Node所负责的区域，地理上不必链接在一块儿，好比大陆的四周边缘部分和高山部分的区块人比较少，能够统一交给一个Node去管理，而这些区块在地理上并无联系在一块儿的必要性。一个 Node到底管理哪些区块，能够根据游戏实时运行的负载状况，定时维护的时候进行更改 NodeMaster 上面的配置。
因而碰到第一个问题是不少 Node服务器须要和玩家进行通讯，须要问管理服务器特定UID为多少的玩家到底在哪台 Gate上，之前按场景切割的服务器这个问题不大，问了一次之后就能够缓存起来了，可是如今服务器种类增长很多，玩家又会飘来飘去，按UID查找玩家比较麻烦；另一方面 GATE须要动态根据坐标计算和哪些 Node通讯，致使逻辑愈来愈厚，因而把：“用户对象”从负责链接管理的 GATE中切割出来势在必行因而有了下面的模型：

网关服务器再次退回到精简的网络转发功能，而用户逻辑则由按照 UID划分的 OBJ服务器来承担，GATE是按照网络接入时的负载来分布，而 OBJ则是按照资源的编号（UID）来分布，这样和一个用户通讯直接根据 UID计算出 OBJ服务器编号发送数据便可。而新独立出来的 OBJ则提供了更多高层次的服务：

· 对象移动：管理具体玩家在不一样的 Node所管辖的区域之间的移动，并同须要的 Node进行沟通。

· 数据广播：Node能够给每一个用户设置若干 TAG，而后通知 Object Master 按照TAG广播。

· 对象消息：通用消息推送，给某个用户发送数据，直接告诉 OBJ，不须要直接和 GATE打交道。

· 好友聊天：角色之间聊天直接走 OBJ/OBJ MASTER。

整个服务器主体分为三层之后，NODE专一场景，OBJ专一玩家对象，GATE专一网络。这样的模型在无缝场景服务器中获得普遍的应用。可是随着时间的推移，负载问题也愈来愈明显，作个活动，远来不活跃的区域变得十分活跃，靠每周维护来调整仍是比较笨重的，因而有了动态负载均衡。
动态负载均衡有两种方法，第一种是按照负载，由 Node Master 定时动态移动修改一下各个 Node的边界，而不一样的玩家对象按照先前的方法从一台 Node上迁移到另一台 Node上：

图11 动态负载均衡
这样 Node Master定时查找地图上的热点区域，计算新的场景切割方式，而后告诉其余服务器开始调整，具体处理方式仍是和上面对象跨越边界移动的方法同样。
可是上面这种方式实现相对复杂一些，因而人们设计出了更为简单直接的一种新方法：

图12 基于网格的动态负载均衡
仍是将地图按照标准尺寸均匀切割成静态的网格，每一个格子由一个具体的Node负责，可是根据负载状况，可以实时的迁移到其余 Node上。在迁移分为三个阶段：准备，切换，完成。三个状态由Node Master负责维护。准备阶段新的 Node开始同步老 Node上面该网格的数据，完成后告诉NM；NM确认OK后同时通知新旧 Node完成切换。完成切换后，若是 Obj服务器还在和老的 Node进行通讯，老的 Node将会对它进行纠正，获得纠正的 OBJ将修正本身的状态，和新的 Node进行通讯。
不少无缝动态负载均衡的服务端宣称本身支持无限的人数，但不意味着 MMORPG游戏的人数上限真的能够无限扩充，由于这样的体系会受制于网络带宽和客户端性能。带宽决定了同一个区域最大广播上限，而客户端性能决定了同一个屏幕到底能够绘制多少个角色。
从无缝地图引入了分布式对象模型开始，已经彻底脱离 MUDOS体系，成为一种新的服务端模型。又因为动态负载均衡的引入，让无缝服务器如虎添翼，容纳着超过上一代游戏服务器数倍的人数上限，并提供了更好的游戏体验，咱们称其为第三代游戏服务端架构。网游以大型多人角色扮演为开端，RPG网游在至关长的时间里一度占据90%以上，使得基于 MMORPG的服务端架构获得了蓬勃的发展，然而随着玩家对RPG的疲惫，各类非MMORPG游戏如雨后春笋般的出如今人们眼前，受到市场的欢迎。
类型5：战网游戏服务器
经典战网服务端和 RPG游戏有两个区别：RPG是分区分服的，北京区的用户和广州区的用户老死不相往来。而战网，虽然每局游戏通常都是 8人之内，但全国只有一套服务器，全部的玩家均可以在一块儿游戏，而玩家和玩家之使用 P2P的方式链接在一块儿，组成一局游戏：

玩家经过 Match Making 服务器使用：建立、加入、自动匹配、邀请 等方式组成一局游戏。服务器会选择一我的作 Host，其余人 P2P链接到作主的玩家上来。STUN是帮助玩家之间创建 P2P的牵引服务器，而因为 P2P联通状况大概只有 75%，实在联不通的玩家会经过 Forward进行转发。
大量的链接对战，体育竞技游戏采用相似的结构。P2P有网状模型（全部玩家互相链接），和星状模型（全部玩家链接一个主玩家）。复杂的游戏状态在网状模型下难以造成一致，所以星状P2P模型经受住了历史的考验。除去游戏数据，支持语音的战网系统也会将全部人的语音数据发送到作主的那个玩家机器上，经过混音去重再编码的方式返回给全部用户。
战网类游戏，以竞技、体育、动做等类型的游戏为主，较慢节奏的 RPG（包括ARPG）有本质上的区别，而激烈的游戏过程必然带来到较 RPG复杂的多的同步策略，这样的同步机制每每带来的是不少游戏结果由客户端直接计算得出，那在处处都是破解的今天，如何保证游戏结果的公正呢？
主要方法就是投票法，全部客户端都会独立计算，而后传递给服务器。若是结果相同就更新记录，若是结果不一致，会采起相似投票的方式肯定最终结果。同时记录本剧游戏的全部输入，在可能的状况下，找另外闲散的游戏客户端验算整局游戏是否为该结果。而且记录常常有做弊嫌疑的用户，供运营人员封号时参考。
类型7：休闲游戏服务器
休闲游戏同战网服务器相似，都是全区架构，不一样的是有房间服务器，还有具体的游戏服务器，游戏主体再也不以玩家 P2P进行，而是链接到专门的游戏服务器处理：

和战网同样的全区架构，用户数据不能象分区的 RPG那样一次性load到内存，而后在内存里面直接修改。全区架构下，为了应对一个用户同时玩几个游戏，用户数据须要区分基本数据和不一样的游戏数据，而游戏数据又须要区分积分数据、和文档数据。胜平负之类的积分能够直接提交增量修改，而更为广泛的文档类数据则须要提供读写令牌，写令牌只有一块，读令牌有不少块。同账号同一个游戏同时在两台电脑上玩时，最早开始的那个游戏得到写令牌，能够操做任意的用户数据。然后开始的那个游戏除了能够提交胜平负积分的增量改变外，对用户数据采用只读的方式，保证游戏能运行下去，可是会提示用户，游戏数据锁定。
类型8：现代动做类网游
从早期的韩国动做游戏开始，传统的战网动做类游戏和 RPG游戏开始尝试融合。单纯的动做游戏玩家容易疲倦，留存也没有 RPG那么高；而单纯 RPG战斗却又慢节奏的乏味，没法知足不少玩家激烈对抗的指望，因而两者开始融合成为新一代的：动做 + 城镇 模式。玩家在城镇中汇集，而后以开副本的方式几我的出去以动做游戏的玩法来完成各类 RPG任务。本质就是一套 RPG服务端+副本服务端。因为每次副本时人物能够控制在8人之内，所以能够得到更为实时的游戏体验，让玩家玩的更加爽快。
说了那么多的游戏服务器类型，其实也差很少了，剩下的类型你们拼凑一下其实也就是这个样子而已。游戏服务端经历了那么多结构上的变迁，内部开发模式是否依然不变？到底是继续延续传统的开发方式？仍是有了更多突破性的方法？经历那么屡次架构变迁，后面是否有共通的逻辑？将来的发展还会存在哪些困难？游戏服务端开发如何达到最终的彼岸？请看下节：技术的演进。
技术的演进
（待续）

【感觉

从目前流行的开源游戏服务端框架来分析：

网易pomelo 属于 第二代游戏服务端 五型的架构，即图7的架构。

skynet由于是一个服务端框架，官方只是提供了login server 和 gate server的参考实现，其余的须要本身来实现，编程的自由度变大了，架构彻底取决于程序员本身的选择，程序员能够本身尝试去实现第二代的架构，也能够实现第三代的架构。注意: skynet仅仅是框架，其余属于完整解决方案。

Kbengine属于第三代服务端框架，可能相似于图10。（这个理解不肯定）

Kbengine引擎应该是对图10中的Gate服务器和NODE和OBJ进行了细分。在功能上大致划分为与位置有关（在Kbengine中称为Cellapp）和与位置无关（在Kbengine中称为Baseapp）。相似于下面的示图架构。

】