端游及手游服务端的常用架构.docx

端游及手游服务端的常用架构.docx

《端游及手游服务端的常用架构.docx》由会员分享，可在线阅读，更多相关《端游及手游服务端的常用架构.docx（13页珍藏版）》请在冰豆网上搜索。

端游及手游服务端的常用架构

17xuee认为手游页游和端游的效劳端本质上没区别，区别的是游戏类型。

　类型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年，英国著名的财经学校UniversityofEssex的学生RoyTrubshaw编写了世界上第一个MUD程序?

MUD1?

，在UniversityofEssex于1980年接入ARPANET之后参加了不少外部的玩家，甚至包括国外的玩家。

?

MUD1?

程序的源代码在ARPANET共享之后出现了众多的改编版本，至此MUD才在全世界广泛流行起来。

不断完善的MUD1的根底上产生了开源的MudOS（1991），成为众多网游的鼻祖：

MUDOS采用C语言开发，因为玩家和玩家之间有比拟强的交互（聊天，交易，PK），MUDOS使用单线程无阻塞套接字来效劳所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象（网络收发，更新对象状态机，处理超时，刷新地图，刷新NPC）。

　　游戏世界采用房间的形式组织起来，每个房间有东南西北四个方向可以移动到下一个房间，由于欧美最早的网游都是地牢迷宫形式的，因此场景的根本单位被成为“房间〞。

MUDOS使用一门称为LPC的脚本语言来描述整个世界（包括房间拓扑，配置，NPC，以及各种剧情）。

游戏里面的高级玩家（巫师），可以不断的通过修改脚本来为游戏添加房间以及增加剧情。

早年MUD1上线时只有17个房间，RoyTrubshaw毕业以后交给他的师弟RichardBattle，在RichardBattle手上，不断的添加各种玩法到一百多个房间，终于让MUD发扬光大。

　　用户使用Telnet之类的客户端用Tcp协议连接到MUDOS上，使用纯文字进展游戏，每条指令用回车进展分割。

比方1995年国内第一款MUD游戏?

侠客行?

，你敲入：

"goeast"，游戏就会提示你：

“后花园-这里是归云庄的后花园，种满了花草，几个庄丁正在浇花。

此地乃是含羞草生长之地。

这里唯一的出口是north。

这里有：

花待阿牧（Amu），还有二位庄丁（ZhuangDing）〞，然后你继续用文字操作，查看阿牧的信息：

“lookamu〞，系统提示：

“花待阿牧（Amu）他是陆乘风的弟子，受命在此看管含羞草。

他看起来三十多岁，生得眉清目秀，端正大方，一表人才。

他的武艺看上去【不是很高】，出手似乎【极轻】〞。

然后你可以选择击败他获得含羞草，但是你吃了含羞草却又可能会中毒死亡。

在早期网上资源贫乏的时候，这样的游戏有很强的代入感。

　　用户数据保存在文件中，每个用户登录时，从文本文件里把用户的数据全部加载进来，操作全部在内存里面进展，无需马上刷回磁盘。

用户退出了，或者每隔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来代替。

由于主逻辑使用单线程模型，随着游戏内容的增加，传统单效劳器的构造进一步成为瓶颈。

于是有人开场拆分游戏世界，变为下面的模型：

　　游戏效劳器压力拆分后得意缓解，但是两台游戏效劳器同时访问数据库，大量重复访问，大量数据交换，使得数据库成为下一个瓶颈。

于是形成了数据库前端代理（DBProxy），游戏效劳器不直接访问数据库而是访问代理，再有代理访问数据库，同时提供内存级别的cache。

早年MySQL4之前没有提供存储过程，这个前端代理一般和MySQL跑在同一台上，它转化游戏效劳器发过来的高级数据操作指令，拆分成具体的数据库操作，一定程度上代替了存储过程：

　　但是这样的构造并没有持续太长时间，因为玩家切换场景经常要切换连接，中间的状态容易错乱。

而且游戏效劳器多了以后，相互之间数据交互又会变得比拟麻烦，于是人们拆分了网络功能，独立出一个网关效劳Gate（有的地方叫Session，有的地方叫LinkSvr之类的，名字不同而已）：

　　把网络功能单独提取出来，让用户统一去连接一个网关效劳器，再有网关效劳器转发数据到后端游戏效劳器。

而游戏效劳器之间数据交换也统一连接到网管进展交换。

这样类型的效劳器根本能稳定的为玩家提供游戏效劳，一台网关效劳1-2万人，后面的游戏效劳器每台效劳5k-1w，依游戏类型和复杂度不同而已，图中隐藏了很多不重要的效劳器，如登录和管理。

这是目前应用最广的一个模型，到今天任然很多新工程会才用这样的构造来搭建。

　　人都是有惯性的，按照先前的经历，似乎把MUDOS拆分的越开性能越好。

于是大家继续想，网关可以拆分呀，根底效劳如聊天交易，可以拆分呀，还可以提供web接口，数据库可以拆分呀，于是有了下面的模型：

　　这样的模型好用么？

确实有成功游戏使用类似这样的架构，并且发挥了它的性能优势，比方一些大型MMORPG。

但是有两个挑战：

每增加一级效劳器，状态机复杂度可能会翻倍，导致研发和找bug的本钱上升;并且对开发组挑战比拟大，一旦工程时间吃紧，开发人员经历缺乏，很容易弄挂。

　　比方我见过某XX一线游戏公司的一个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，然后通知ObjectMaster按照TAG播送。

· 对象消息：

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

· 好友聊天：

角色之间聊天直接走OBJ/OBJMASTER。

　　整个效劳器主体分为三层以后，NODE专注场景，OBJ专注玩家对象，GATE专注网络。

这样的模型在无缝场景效劳器中得到广泛的应用。

但是随着时间的推移，负载问题也越来越明显，做个活动，远来不活泼的区域变得十分活泼，靠每周维护来调整还是比拟笨重的，于是有了动态负载均衡。

　　动态负载均衡有两种方法，第一种是按照负载，由NodeMaster定时动态移动修改一下各个Node的边界，而不同的玩家对象按照先前的方法从一台Node上迁移到另外一台Node上：

图11动态负载均衡

　　这样NodeMaster定时查找地图上的热点区域，计算新的场景切割方式，然后告诉其他效劳器开场调整，具体处理方式还是和上面对象跨越边界移动的方法一样。

　　但是上面这种方式实现相对复杂一些，于是人们设计出了更为简单直接的一种新方法：

图12基于网格的动态负载均衡

　　还是将地图按照标准尺寸均匀切割成静态的网格，每个格子由一个具体的Node负责，但是根据负载情况，能够实时的迁移到其他Node上。

在迁移分为三个阶段：

准备，切换，完成。

三个状态由NodeMaster负责维护。

准备阶段新的Node开场同步老Node上面该网格的数据，完成后告诉NM；NM确认OK后同时通知新旧Node完成切换。

完成切换后，如果Obj效劳器还在和老的Node进展通信，老的Node将会对它进展纠正，得到纠正的OBJ将修正自己的状态，和新的Node进展通信。

　　很多无缝动态负载均衡的效劳端宣称自己支持无限的人数，但不意味着MMORPG游戏的人数上限真的可以无限扩大，因为这样的体系会受制于网络带宽和客户端性能。

带宽决定了同一个区域最大播送上限，而客户端性能决定了同一个屏幕到底可以绘制多少个角色。

　　从无缝地图引入了分布式对象模型开场，已经完全脱离MUDOS体系，成为一种新的效劳端模型。

又由于动态负载均衡的引入，让无缝效劳器如虎添翼，容纳着超过上一代游戏效劳器数倍的人数上限，并提供了更好的游戏体验，我们称其为第三代游戏效劳端架构。

网游以大型多人角色扮演为开端，RPG网游在相当长的时间里一度占据90%以上，使得基于MMORPG的效劳端架构得到了蓬勃的开展，然而随着玩家对RPG的疲惫，各种非MMORPG游戏如雨后春笋般的出现在人们眼前，受到市场的欢送。

　　类型5：

战网游戏效劳器

　　经典战网效劳端和RPG游戏有两个区别：

RPG是分区分服的，区的用户和XX区的用户老死不相往来。

而战网，虽然每局游戏一般都是8人以内，但全国只有一套效劳器，所有的玩家都可以在一起游戏，而玩家和玩家之使用P2P的方式连接在一起，组成一局游戏：

　　玩家通过MatchMaking效劳器使用：

创立、参加、自动匹配、邀请等方式组成一局游戏。

效劳器会选择一个人做Host，其他人P2P连接到做主的玩家上来。

STUN是帮助玩家之间建立P2P的牵引效劳器，而由于P2P联通情况大概只有75%，实在联不通的玩家会通过Forward进展转发。

　　大量的连接对战，体育竞技游戏采用类似的构造。

P2P有网状模型（所有玩家互相连接），和星状模型（所有玩家连接一个主玩家）。

复杂的游戏状态在网状模型下难以形成一致，因此星状P2P模型经受住了历史的考验。

除去游戏数据，支持语音的战网系统也会将所有人的语音数据发送到做主的那个玩家机器上，通过混音去重再编码的方式返回给所有用户。

　　战网类游戏，以竞技、体育、动作等类型的游戏为主，较慢节奏的RPG（包括ARPG）有本质上的区别，而剧烈的游戏过程必然带来到较RPG复杂的多的同步策略，这样的同步机制往往带来的是很多游戏结果由客户端直接计算得出，那在到处都是破解的今天，如何保证游戏结果的公正呢?

　　主要方法就是投票法，所有客户端都会独立计算，然后传递给效劳器。

如果结果一样就更新记录，如果结果不一致，会采取类似投票的方式确定最终结果。

同时记录本剧游戏的所有输入，在可能的情况下，找另外闲散的游戏客户端验算整局游戏是否为该结果。

并且记录经常有作弊嫌疑的用户，供运营人员封号时参考。

　类型6：

休闲游戏效劳器

　　休闲游戏同战网效劳器类似，都是全区架构，不同的是有房间效劳器，还有具体的游戏效劳器，游戏主体不再以玩家P2P进展，而是连接到专门的游戏效劳器处理：

　　和战网一样的全区架构，用户数据不能象分区的RPG那样一次性load到内存，然后在内存里面直接修改。

全区架构下，为了应对一个用户同时玩几个游戏，用户数据需要区分根本数据和不同的游戏数据，而游戏数据又需要区分积分数据、和文档数据。

胜平负之类的积分可以直接提交增量修改，而更为普遍的文档类数据那么需要提供读写令牌，写令牌只有一块，读令牌有很多块。

同XX同一个游戏同时在两台电脑上玩时，最先开场的那个游戏获得写令牌，可以操作任意的用户数据。

而后开场的那个游戏除了可以提交胜平负积分的增量改变外，对用户数据采用只读的方式，保证游戏能运行下去，但是会提示用户，游戏数据锁定。

类型7：

现代动作类网游

　　从早期的韩国动作游戏开场，传统的战网动作类游戏和RPG游戏开场尝试融合。

单纯的动作游戏玩家容易疲倦，留存也没有RPG那么高；而单纯RPG战斗却又慢节奏的乏味，无法满足很多玩家剧烈对抗的期望，于是二者开场融合成为新一代的：

动作+城镇模式。

玩家在城镇中聚集，然后以开副本的方式几个人出去以动作游戏的玩法来完成各种RPG任务。

本质就是一套RPG效劳端+副本效劳端。

由于每次副本时人物可以控制在8人以内，因此可以获得更为实时的游戏体验，让玩家玩的更加爽快。

　　说了那么多的游戏效劳器类型，其实也差不多了，剩下的类型大家拼凑一下其实也就是这个样子而已。

游戏效劳端经历了那么多构造上的变迁，内部开发模式是否依然不变?

终究是继续延续传统的开发方式?

还是有了更多突破性的方法?

经历那么屡次架构变迁，后面是否有共通的逻辑?

未来的开展还会存在哪些困难?