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