查看: 706|回复: 1

论手游服务端、网页游戏服务端和端游游戏服务端的架构...

[复制链接]

4738

主题

5078

帖子

1万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
18934

最佳新人活跃会员热心会员推广达人宣传达人灌水之王突出贡献优秀版主荣誉管理论坛元老

发表于 2020-2-10 16:25:02 | 显示全部楼层 |阅读模式

手游服务端网页游戏服务端和端游游戏服务端的架构与区别 https://www.gmbbs.net/
类型1:弱交互服务终端,如卡片和跑酷
卡跑酷不需要玩家之间的实时面对面PK,因为互动很弱。只需要点击对方的离线数据,计算排名列表,买卖道具。因此,简单的HTTP服务端通常用于实现:
手游、页面游和结束游的服务架构及差异
登录时可以使用非对称加密。服务端根据客户端的uid、当前时间戳和服务端的私钥计算散列加密密钥,并将其发送给客户端。此后,双方使用该密钥进行HTTP通信和RC4加密。客户端收到密钥和时间戳后,会将其存储在内存中,以便以后进行通信。服务端不需要保存密钥,因为每次都可以根据客户端传输的uid和时间戳以及服务端自己的私钥进行计算。模拟TLS的行为用于确保多个HTTP请求之间的客户端身份,时间戳用于确保同一个人有两次不同的登录密钥。
在每一轮开始时,访问它,请求检查点数据,在游戏结束后提交它,检查它是否合法以及你得到什么奖励。数据库可以由一个单独的MySQL或MongoDB缓存,后端的Redis是可选的。如果要实现通知,客户端应该定期轮询服务端15秒钟。如果有什么消息,应该记下来。如果没有消息,轮询时间可以逐渐延长,例如30秒。如果有消息,轮询时间将缩短到10秒5秒。即使两个人聊天,延迟也是可以适应的。
这种服务端足以实现三国战略或卡牌和酷跑游戏。由于其简单的逻辑和玩家之间的弱交互,使用HTTP开发这样的游戏开发速度很快,只需要一个浏览器就可以清楚地调试逻辑。
类型2:第一代游戏服务端1978
1978年,著名的英国埃塞克斯大学金融学院的学生罗伊·特鲁布肖写了世界上第一个MUD程序《MUD1》。在埃塞克斯大学于1980年加入ARPANET后,他加入了许多外部玩家,甚至是外国玩家。自从ARPANET被共享后,《MUD1》程序的源代码出现了许多改编版本,因此MUD在世界上变得广泛流行。基于对MUD1的不断改进,开源MudOS(1991)应运而生,并成为许多在线游戏的创始人:
手游、页面游和结束游的服务架构及差异
MUDOS是用C语言开发的,因为玩家和玩家之间有较强的交互(聊天、交易、PK)。MUDOS使用单线程非阻塞套接字为所有玩家服务。所有玩家的请求都被发送到同一个线程进行处理。主线程每1秒更新所有对象(网络发送和接收、更新对象状态机、超时处理、刷新地图、刷新NPC)。
游戏世界是以房间的形式组织的。每个房间可以向东南和西北四个方向移动到下一个房间。由于欧洲和美国最早的网络游戏是地牢迷宫的形式,场景的基本单元被称为“房间”。MUDOS使用一种称为LPC的脚本语言来描述整个世界(包括房间拓扑、配置、NPC和各种场景)。游戏中的高级玩家(向导)可以通过修改脚本不断为游戏添加房间和情节。在早期,当MUD1发布时,只有17个房间。罗伊·特鲁布肖毕业后把它交给了他的弟弟理查德·巴特尔。理查德·巴特尔不断在100多个房间里添加各种游戏,最终让MUD发展起来。
用户使用Telnet等客户端,使用Tcp协议连接到MUDOS,使用纯文本玩游戏,并使用回车符分隔每个命令。例如,在1995年,中国的第一个泥浆游戏是《侠客行》。当你输入“向东”,游戏会提示你:“后花园——这是云庄的后花园。它到处都是花和植物。几个村民正在浇花。这是含羞草生长的地方。这里唯一的出口是北边。这里有:华和两个庄丁。然后你继续用文字来检查阿木的信息:“看阿木。系统提示:“华是的弟子,受命在此照顾含羞草。”。他看上去30多岁了,五官端正,举止得体,相貌英俊。他的武功看起来[不是很高]而他的动作看起来[极轻]。然后你可以选择打败他得到含羞草,但是如果你吃了含羞草,你可能会中毒而死。在互联网资源稀缺的早期,这种游戏有很强的替代意识。
用户数据存储在文件中。当每个用户登录时,所有用户数据都从文本文件加载进来,所有操作都在内存中执行,而无需立即刷回磁盘。如果用户退出或每5分钟检测到更改,磁盘将被保存。当每台服务端同时承载4000人时,这样的系统不是一个特别大的问题。自1991年发布MUDOS以来,世界各地都在为他改进、扩展和退出新版本。随着视窗图形功能的增强。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。由于主逻辑采用单线程模型,随着游戏内容的增加,传统的单服务端结构成为瓶颈。所以有人开始把游戏世界分成以下几个模式:
手游、页面游和结束游的服务架构及差异
游戏服务端拆分后压力减轻,但两台游戏服务端同时访问数据库,存在大量重复访问和大量数据交换,使数据库成为下一个瓶颈。因此,形成了数据库前端代理。游戏服务端不直接访问数据库,而是访问代理,另一个代理在提供内存级缓存的同时访问数据库。在早期,MySQL4以前不提供存储过程。这个前端代理通常运行在与MySQL相同的平台上。其转化游戏服务端发送的高级数据操作指令被分成特定的数据库操作,在某种程度上取代了存储过程:
手游、页面游和结束游的服务架构及差异
然而,这种结构并没有持续很久,因为玩家在切换场景时经常需要切换连接,中间的状态很容易混乱。此外,当有更多的游戏服务端时,它们之间的数据交互将变得更加麻烦。因此,人们将网络功能分开,独立创建了一个网关服务网关(在某些地方,它被称为会话,在某些地方,它被称为LinkSvr等等,只是名称不同):
手游、页面游和结束游的服务架构及差异
网络功能是分开提取的,允许用户以统一的方式连接到网关服务端,然后网关服务端将数据转发到后端游戏服务端。游戏服务端之间的数据交换也连接到网络管理进行交换。这种类型的服务端基本上可以为玩家提供稳定的游戏服务,一个网关服务10,000到20,000人,下面的游戏服务端每个服务5 k到1 w。根据游戏的类型和复杂性,图中隐藏了许多不重要的服务端,如登录和管理。这是目前使用最广泛的型号。直到今天,许多新项目都只能用这种结构建造。
每个人都有惰性。根据以前的经验,看来MUDOS越开放,它的性能就越好。因此,我们仍然认为网关可以拆分,聊天交易等基本服务可以拆分,网络界面可以提供,数据库可以拆分,因此我们有以下模型:
手游、页面游和结束游的服务架构及差异
这个模型容易使用吗?确实有一些成功的游戏使用了这样的架构,并利用了它的性能,比如一些大型的MMORPG。然而,有两个挑战:每增加一级服务端,状态机的复杂性就会增加一倍,导致研发和错误发现的成本增加;而对开发团队的挑战是相当大的,一旦项目时间紧张,开发人员缺乏经验,就很容易挂掉。
例如,我看到上海一线游戏公司的一个角色扮演游戏升级到这样的结构。我查看了他们团队成员的经验,询问了他们的发布日期,并敦促他们使用稍微简单一点的模型。人们非常自信。他们认为成功的项目是这样完成的。他们也想这么做。他们真的想实现一套。所以他们毫不犹豫地开始编码。这个项目持续了一年多,然后就没有了。
目前,当游戏的成功率不高时,在第一套相对复杂的结构中需要考虑投资回报,比如你的游戏推出后半年内PCU将会达到多少?如果一个APRG游戏不能达到每组5000台服务端,选择一个更接近实际情况的结构会更经济。即使以后有超过5000人在你的项目中朝着10000人的目标前进,我相信你的项目那时已经赚了很多钱。你数着钱,一步一步地重复,然后一个接一个地把它分开。我相信心里也很高兴开花。
上述类型基本上是从MUDOS的拆分开始的,MUDOS中的每个组件都是从一台机器中逐步拆分成分布式组件的。尽管许多新项目今天仍在使用上述类似的结构之一,或者他们自己已经分割了其他热模块。因为它们本质上是MUDOS的分解,所以被归类为第二代游戏服务端。
类型4:第三代游戏服务端2007
自《魔兽世界》以来,无缝世界地图已经深深扎根于人们的心中。与以前的游戏相比,玩家需要在走几步后切换场景。对于每个交换机来说,等待LOADING几十秒钟是非常有害的。因此,无缝地图已成为2005年后大MMORPG的标准配置。与之前的地图切割游戏相比,无缝世界中没有地图,只有一个服务端处理它:
手游、页面游和结束游的服务架构及差异
每个节点服务端用于管理一个地图区域,节点主服务端(NM)为它们提供全面管理。更高层次的世界提供大陆层次的管理服务。这里省略了一些详细的服务端,如传统的数据库前端、登录服务端、日志和监控等。全部由ADMIN总结。在这样的结构下,玩家从一个地区到另一个地区需要简单的治疗:
手游、页面游和结束游的服务架构及差异
玩家1
不需要在地理上连接节点负责的区域。例如,大陆边缘和高山地区人口较少,可以由一个节点管理。然而,没有必要在地理上连接这些区域。节点管理哪些块?NodeMaster上的配置可以在定期维护期间根据游戏的实时运行负载进行更改。
因此,第一个问题是许多节点服务端需要与玩家通信。他们需要询问具有管理服务端特定UID的玩家在哪个门。以前,服务端按场景裁剪的问题不大。询问一次后,它们可以被缓存。然而,现在服务端的类型已经增加了很多,玩家将再次四处浮动。根据用户识别号寻找玩家更麻烦。另一方面,GATE需要根据坐标动态计算要与哪个节点通信,从而产生更厚的逻辑。因此,必须从负责连接管理的GATE中删除“用户对象”。因此,建立了以下模型:
手游、页面游和结束游的服务架构及差异
然而,这种结构并没有持续很久,因为玩家在切换场景时经常需要切换连接,中间的状态很容易混乱。此外,当有更多的游戏服务端时,它们之间的数据交互将变得更加麻烦。因此,人们将网络功能分开,独立创建了一个网关服务网关(在某些地方,它被称为会话,在某些地方,它被称为LinkSvr等等,只是名称不同):
手游、页面游和结束游的服务架构及差异
网络功能是分开提取的,允许用户以统一的方式连接到网关服务端,然后网关服务端将数据转发到后端游戏服务端。游戏服务端之间的数据交换也连接到网络管理进行交换。这种类型的服务端基本上可以为玩家提供稳定的游戏服务,一个网关服务10,000到20,000人,下面的游戏服务端每个服务5 k到1 w。根据游戏的类型和复杂性,图中隐藏了许多不重要的服务端,如登录和管理。这是目前使用最广泛的型号。直到今天,许多新项目都只能用这种结构建造。
每个人都有惰性。根据以前的经验,看来MUDOS越开放,它的性能就越好。因此,我们仍然认为网关可以拆分,聊天交易等基本服务可以拆分,网络界面可以提供,数据库可以拆分,因此我们有以下模型:
手游、页面游和结束游的服务架构及差异
这个模型容易使用吗?确实有一些成功的游戏使用了这样的架构,并利用了它的性能,比如一些大型的MMORPG。然而,有两个挑战:每增加一级服务端,状态机的复杂性就会增加一倍,导致研发和错误发现的成本增加;而对开发团队的挑战是相当大的,一旦项目时间紧张,开发人员缺乏经验,就很容易挂掉。
例如,我看到上海一线游戏公司的一个角色扮演游戏升级到这样的结构。我查看了他们团队成员的经验,询问了他们的发布日期,并敦促他们使用稍微简单一点的模型。人们非常自信。他们认为成功的项目是这样完成的。他们也想这么做。他们真的想实现一套。所以他们毫不犹豫地开始编码。这个项目持续了一年多,然后就没有了。
目前,当游戏的成功率不高时,在第一套相对复杂的结构中需要考虑投资回报,比如你的游戏推出后半年内PCU将会达到多少?如果一个APRG游戏不能达到每组5000台服务端,选择一个更接近实际情况的结构会更经济。即使以后有超过5000人在你的项目中朝着10000人的目标前进,我相信你的项目那时已经赚了很多钱。你数着钱,一步一步地重复,然后一个接一个地把它分开。我相信心里也很高兴开花。
上述类型基本上是从MUDOS的拆分开始的,MUDOS中的每个组件都是从一台机器中逐步拆分成分布式组件的。尽管许多新项目今天仍在使用上述类似的结构之一,或者他们自己已经分割了其他热模块。因为它们本质上是MUDOS的分解,所以被归类为第二代游戏服务端。
类型4:第三代游戏服务端2007
自《魔兽世界》以来,无缝世界地图已经深深扎根于人们的心中。与以前的游戏相比,玩家需要在走几步后切换场景。对于每个交换机来说,等待LOADING几十秒钟是非常有害的。因此,无缝地图已成为2005年后大MMORPG的标准配置。与之前的地图切割游戏相比,无缝世界中没有地图,只有一个服务端处理它:
手游、页面游和结束游的服务架构及差异
每个节点服务端用于管理一个地图区域,节点主服务端(NM)为它们提供全面管理。更高层次的世界提供大陆层次的管理服务。这里省略了一些详细的服务端,如传统的数据库前端、登录服务端、日志和监控等。全部由ADMIN总结。在这样的结构下,玩家从一个地区到另一个地区需要简单的治疗:
手游、页面游和结束游的服务架构及差异
玩家1
不需要在地理上连接节点负责的区域。例如,大陆边缘和高山地区人口较少,可以由一个节点管理。然而,没有必要在地理上连接这些区域。节点管理哪些块?NodeMaster上的配置可以在定期维护期间根据游戏的实时运行负载进行更改。
因此,第一个问题是许多节点服务端需要与玩家通信。他们需要询问具有管理服务端特定UID的玩家在哪个门。以前,服务端按场景裁剪的问题不大。询问一次后,它们可以被缓存。然而,现在服务端的类型已经增加了很多,玩家将再次四处浮动。根据用户识别号寻找玩家更麻烦。另一方面,GATE需要根据坐标动态计算要与哪个节点通信,从而产生更厚的逻辑。因此,必须从负责连接管理的GATE中删除“用户对象”。因此,建立了以下模型:


【GM论坛[www.gmbbs.net]免责声明】
1、本站提供的所有资源仅供参考学习使用,版权归原著所有,禁止下载本站资源参与商业和非法行为,请在24小时之内自行删除!
2、本站所有内容均由互联网收集整理、网友上传,并且以计算机技术研究交流为目的,仅供大家参考、学习,不存在任何商业目的与商业用途。
3、若您需要商业运营或用于其他商业活动,请您购买正版授权并合法使用。 我们不承担任何技术及版权问题,且不对任何资源负法律责任。
4、论坛的所有内容都不保证其准确性,完整性,有效性。阅读本站内容因误导等因素而造成的损失本站不承担连带责任。
5、用户使用本网站必须遵守适用的法律法规,对于用户违法使用本站非法运营而引起的一切责任,由用户自行承担
6、本站所有资源来自互联网转载,版权归原著所有,用户访问和使用本站的条件是必须接受本站“免责声明”,如果不遵守,请勿访问或使用本网站
7、本站使用者因为违反本声明的规定而触犯中华人民共和国法律的,一切后果自己负责,本站不承担任何责任。
8、凡以任何方式登陆本网站或直接、间接使用本网站资料者,视为自愿接受本网站声明的约束。
9、本站以《2013 中华人民共和国计算机软件保护条例》第二章 “软件著作权” 第十七条为原则:为了学习和研究软件内含的设计思想和原理,通过安装、显示、传输或者存储软件等方式使用软件的,可以不经软件著作权人许可,不向其支付报酬。若有学员需要商用本站资源,请务必联系版权方购买正版授权!
10、本网站如无意中侵犯了某个企业或个人的知识产权,请告之,本站将立即删除。
   提问发帖求助请点此发帖 https://www.gmbbs.net/

0

主题

27

帖子

124

积分

月卡VIP会员

积分
124
发表于 2020-2-10 17:20:25 | 显示全部楼层
啥也不说了,感谢楼主分享哇!支持...www.gmbbs.net GM论坛 必出精品
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表