当前位置:澳门贵宾厅 > www.vip8888.com > 游戏由众小的世界组成,有些服不需要使用数据库只承担玩家的战斗功能
游戏由众小的世界组成,有些服不需要使用数据库只承担玩家的战斗功能
2020-04-07

期待第二阶段 “理想的异地双活”能给业务带来真实的价值!

当然,要实现业务真正意义上的异地双活,我们需要考虑的因素会有许多,例如,异地机房的数据同步问题是诸多因素中的一个重要因素。

由于大世界架构的游戏有个很明显的特征,功能性的服区分比较明显,例如有战斗节点server、日志节点log、登录节点center、数据节点data、缓存节点cache,其中有些功能服需使用数据库,有些服不需要使用数据库只承担玩家的战斗功能。这些不同的功能服无论部署在南方机房还是北方机房都存在着以下2个比较严重的问题,具体如下:

以上是我厂针对手游的部分运维服务方案,当然也有不足的地方需要不断的进行摸索和完善。

为了保障业务在单机房遭受DDOS攻击、南北骨干网抖动故障场景下的正常运行和稳定,于是我们构思出了如下方案:

传统的手游架构基本是由页游的模式转变而来的,即开服型架构

PXC集群通过内网专线连接,专线故障时能自动切换到公网通讯。非缓冲层数据通过PXC集群保持数据一致。游戏节点同时部署在南北机房,除了入口节点以外,任何一方的游戏节点故障,程序可自动转移。玩家进入游戏均通过域名+端口的形式,域名针对省级做智能解析,玩家就近访问。入口节点通过D监控实现故障自动转移。原反向代理服务仅用于用户战斗节点的分配,不再作为全链路转发。

图7 市级故障

www.vip8888.com,2.2 第二阶段

图4 BGP大世界类型游戏异地双活方案

要解决“真正异地双活”的问题,实际上主要是解决数据同步的问题,底层的数据要求强一致性同时实现多写。而在我们的业务场景,数据有缓冲层数据、非缓冲层数据。缓冲层数据“双活”我们计划采用redis集群+Sentinel的方案来实现。非缓冲层的数据“双活”我们计划采用MySQL集群方案。那么问题来了,业界上主流的MySQL集群方案有MySQL ClusterPercona Xtradb Cluster

监控系统在全国预埋分布式监控节点做网络拨测监控,拨测数据统一调度上报到监控中心。监控中心基于大数据分析,以三不不滥发、不误发、不漏发为何核心思想,快速准确识别网络故障,实时报警通知运维。

因为无论是MR、MM、MGR架构都是基于Binlog同步原理,涉及Mysql Binlog复制机制的方案均有延时的可能性。因为我们需要实现多写,如果无法保证数据实时一致性,业务将无法正常运作。

两个方案均有其优缺点和应用场景,具体有关数据库回档的方案,详见运维军团公众号的前期文章《只需一招,让失控的研发哥爱上你》。

基于第一阶段之上,新增一些关键技术点:

文章来自微信公众号:运维军团

于是我们针对MySQL集群选型采取了一些压测,主要对比两种集群在高并发下写场景下的吞吐量、数据一致性、平均操作延迟等情况。

2) 业务主要部署在北方IDC机房;

随着业务的长久运行,第一阶段的方案虽然能解决机房遭受DDOS攻击、南北骨干网抖动等故障场景,但也暴露了不少其他问题。例如:

局部数据恢复:采用binlog回滚原理,对局部数据进行恢复;

-webpages/mysqlwsrepoptions.html

随着移动设备以及网络的飞速发展,传统的“人机大战“已不能满足各类玩家的口味,故而各大游戏厂商皆将“魔爪”伸向了移动端,至此手机网络游戏应运而生。对于游戏运维而言,从“页游摸爬滚打”多年,一朝转至手游时代,无疑面临一种新的挑战!

我们采取用一些技术手段:

图1 手游开服型架构图

为什么不是Mysql Replication或MySQL Group Replication?

该架构的特点:

-xtradb-cluster/5.7/index.html

5) 当业务所在机房的网络出现异常,只要南北专线保持畅通,就可以将玩家的请求从南方的BGP转发服务,通过专线转发至业务所在机房,这也是我们在应对DDOS攻击的一个策略。

最近由于游戏业务的迫切需求,我们需要启用一套可靠的异活双活方案,降低业务的单点。大世界类型游戏的特点是组件模块化,战斗节点、数据节点、登录认证服务器多为独立部署,这样的设计有利于高在线的承载能力。但问题来了,这样的架构要求在同一个内网里通信,我们常规部署都是把所有服务器集中在一个机房里。这样一来,一旦机房受到攻击或者机房出口异常再加上国内骨干网的间歇性抽风,这会对业务将带来全局的影响,严格来说存在一个非必然但不合理的单点。在经济学里有一句谚语“Don’t put all your eggs into the same basket!”——不要鸡蛋全部放在一个篮子里。

图1,我们可以看到开服型手游几个特点:

-cluster-install-linux-rpm.html

  1. “手游”我们都对你做了什么3.1 “鸡蛋同篮”的尴尬?

因此,我们衍生出了第二阶段的方案,具体实现的架构:

另外,我们也可以将大世界的节点分别部署在不同的机房,并通过南北专线进行相连,这样我们就可以将客户端请求域名就近解析,玩家就可以就近进行访问,从而提高玩家访问效率。当一处机房出现故障,我们可以将业务切至另一处机房,从而实现业务在一定程度上的高可用。

具体使用说明可以参考我们前面的公众号文章《MySQL VS MongoDB 你会如何选择?

图8 数据库备份流程图

单看测试结果,当数据量和并发数越大,mysql cluster集群的插入吞吐量、平均操作延时都越优于percona xtradb cluster集群。这一点也不意外,因为NDB引擎主要使用内存存储数据,而PXC是需要落地磁盘的。但是NDB引擎有很多劣势,例如巨耗内存、管理维护麻烦、容易崩溃出错、容易丢数据等,Oracle MySQL官网也强调NDB不建议应用于生产环境。这点有些纳闷…

APM应用性能监控系统:主要是客户端与服务端的通信交互透明化,方便我们以真实玩家的报障数据为分析对象,准确、有效地定位异常问题。

我们来看看压测结果:

以上是针对服务器和IDC机房的监控,你以为这就足够了吗?当然不够,对于一款独立的游戏项目,我们怎么才能做到于细微处见“真章”呢?

这个方案虽然在设计上显得草根,但在线上正式应用后,已经取得了一些效果,最严重的情况就是专线中断,这时我们的业务仍然可以保证正常的运行,由反向代理服务自动切换到公网转发。当然我们只能称它为“伪异地双活方案”。如下图所示:

第二个阶段:手工阶段+部分项目的打包后台;

南北两地架设一条处于公网之外的专线,专线走服务器的内网卡通讯,相比公网缩小了10ms的延迟。将大世界的入口节点分别部署在南北两个机房,避免外网登录入口程序单点。南方机房利用反向代理通过内网专线全部转发到业务所在的北方机房,内网专线断开时反向代理服务自动切换到公网进行转发,实现转发过程中的高可用。玩家进入游戏均通过域名+端口的形式,域名针对省级做智能解析,达到玩家就近访问的效果。应用D监控,如果检测到域名解析故障时,切换解析到正常的另一方,形成自动故障转移。

1) 南北IDC机房通过专线直连,并且打通内网;

目前第二阶段方案虽然仅是测试阶段,但也通过了内部业务的测试,验证了方案的可行性。我们也计划在近期正式应用到线上。

在此我们引入了“BGP转发”服务,阅读过本公众号前几期文章的读者对此服务应该有一定的了解。那么我们来看下如何利用该服务,并且借助IDC机房专线直连,打通IDC机房间的内网方案,实现业务在网络上的异地双活:

PXC与传统MySQL区别不大,大部份日常的维护是相同的,也比较贴合游戏的应用场景。关于性能方面,我们可以用SSD来代替普通机械盘,提高IO性能。最终认为Percona Xtradb Cluster更适用于我们的业务场景。

4) 现有区服不能承载时,新开区服,引导玩家,进行分流。

-cluster-ndbd-definition.html

  1. 浅析手游架构
  1. 写在前面

下面是我厂的数据库备份流程图:

原文来自微信公众号:运维军团

图9 手游客户端自动化打包流程

  1. 参考资料

4) 正常情况下,玩家是直接请求北方机房的业务,当南北骨干网络异常时,南方玩家请求北方机房就存在异常,此时,我们可以让南方玩家直接请求南方的BGP服务,并通过此服务将玩家请求通过南北专线,转发至业务所在的北方机房,从而减小此类网络问题对我们业务的影响;

  1. 异地双活之演进2.1 第一阶段

3.2 “蜜汁”监控——运维利剑组合

有了定时有效的数据库备份,才是我们遇到数据异常回档的首要条件。

2) 后端对应功能称为节点,节点与节点之间需要相互通信;

图5 某游戏项目服务器CPU空闲率汇总图

这个行业需要科学,需要艺术,需要革新,也需要谦卑。相信,我们一直在路上不断前行……

3.3 数据容灾哪家强,无须山东找“蓝翔”

我厂手游客户端打包大致分为三个阶段:

图3 BGP转发服务在大世界上的应用

众所周知,数据库备份是运维工作中最重要的一个环节,因为一旦丢失数据,造成的后果将是不可挽救的。在这里简单描述下我厂的数据库备份策略,供大家探讨。

前两个阶段这里不做赘述,主要介绍下第三个阶段:客户端打包一体化后台,主要基于流程化管理,借助工具的流程组合,将客户端打包所涉及的步骤工具化,从而根据工具创建自己的打包流程,开始打包即可。打包过程无需人工干预,同时具备多人协作的功能。

身处“天朝”的我们,都能清晰的感受到我天朝网络环境复杂之甚,无法比拟。作为游戏运维的我们对玩家所处之“境遇“,感同深受。为不因此,让玩家对我们的游戏失去青睐,我们深表应该做点什么,改善部分玩家的游戏体验……

机房监控主要的故障类型:机房级故障、市级故障、区域级故障等。

第一个阶段:纯手工阶段;

当然,实时的显示IDC机房到我天朝各个省会城市的网络状况,即全国MAP,也是该系统的一大亮点。

4) 整个世界游戏库只有一个,这也势必会引发一些问题,例如,数据量大,造成数据库过于庞大,当然这里我们可以考虑分库和分区;

“天下事常出于人意料之外,志同道合,便能引起类。” 我们是一个成长中的团队,期待和各位同仁为游戏运维行业多做一份贡献。

此架构的特点:游戏由众小的世界组成,各世界的玩家基本上没有交互,像是两条永不相交的平行线,对于一些关系较为亲密的玩家,受制于各种因素,要想一开始就在同个世界中“仗剑走天涯”,无疑是一种奢望。当然说到这里可能会有读者反驳,不是可以通过合服解决这个问题吗?于此同时,我只能对付之一“蜜汁微笑”……

5) 除公共节点,某个游戏节点故障,只会影响该节点玩家,其余节点不受影响,故尔关键的公共节点就显得尤为重要。

  1. 时代背景

那么在游戏运维眼中“开服型”和“大世界型”游戏的架构是怎样的呢?

  1. 结束语

说到这里大家可能会好奇,这个系统主要应对那些监控内容呢?

2) 支持异地跨机房部署,单个机房故障,只会影响该机房的区服,不会影响全局;

图6 机柜故障

机房监控主要的故障类型:机柜故障、网段故障、线路故障、机房故障等。

第三个阶段:客户端打包一体化后台。

作为运维人员,要想做到于细微之处让整个系统张弛有度,获得上佳表现,当然离不开全面的监控系统,而单一的监控系统又很难满足我们日常所需的“立体化”的监控效果,故而多种监控系统组合使用,成为我们日常运维工作中必不可少的环节。

业界公认的zabbix系统:可以说运维人员所关注的服务器几项指标都可以做到很好的支持。同时,也可进行定制化服务的监控。还有就是针对单个项目应用的服务器我们比较关注的监控项,做汇总展示,可以直观的观察到该项目的服务器健康状况。

笔者不知贵厂手游客户端打包流程是怎样的,在此,就我厂手游客户端打包流程描述一二,仅供各位读者参考:

1) 后端没有区服的概念,类似于开服型只有一个区服;

定点恢复:定点完整备份+binlog恢复至几天内的任意时间点;

3) 理论支持跨机房扩展部署,但是由于各个节点之间的网络通信要求比较高,实际实施起来存在问题;

目前我厂遇到的数据恢复方案有:

1) 每个区服都是一个独立的点,各个区服之间不会相互影响;

图2,大世界类型游戏的特点:

图2 手游大世界型游戏

以上是以玩家的视角来看开服型和大世界型游戏各自的特点。

时下,游戏行业蹑景追风,为了满足各类玩家的需求,衍生出了另一种架构类型的游戏,大世界型架构

从字面上不难看出,该类型游戏好比我们现在的“地球村“的概念,不管你在何处,都可以汇聚到一块进行游戏,从此,”携基仗剑天涯“不是梦……

3) 在南方机房部署BGP转发服务;

下面就谈一谈我厂的组合式监控系统是怎样为游戏保驾护航的。

全网监控系统:zabbix固然可以满足我们大多数的监控需求,但是对于一个服务“四海八荒九州“的游戏厂商,多个IDC机房之间的业务交织所面临的监控需求,就显得”捉襟见肘“了。全网监控系统的诞生无疑是应对此问题的”利器“。

3) 每个区服都有自己对应的数据库,各个区服数据库独立不会相互影响;

3.4手游客户端自动化打包利器