游戏运维:这些年,我们对手游做过的那些事儿

社区广播:运维派(Yunweipai.com)是国内最早成立的IT运维社区,欢迎大家投稿,让运维人不再孤寂的成长!

1. 时代背景

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

2. 浅析手游架构

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

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

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

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

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

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

架构

图1 手游开服型架构图

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

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

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

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

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

手游

图2 手游大世界型游戏

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

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

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

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

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

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

3. “手游”我们都对你做了什么

3.1 “鸡蛋同篮”的尴尬?

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

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

 BGP

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

该架构的特点:

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

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

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

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

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

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

BGP

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

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

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

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

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

业界公认的zabbix系统可以说运维人员所关注的服务器几项指标(CPU、内存、磁盘、数据库、流量等)都可以做到很好的支持。同时,也可进行定制化服务的监控(进程、端口、链接数等)。还有就是针对单个项目应用的服务器我们比较关注的监控项,做汇总展示,可以直观的观察到该项目的服务器健康状况。

CPU

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

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

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

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

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

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

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

机柜故障

图6 机柜故障

 市级故障

图7 市级故障

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

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

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

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

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

备份

图8 数据库备份流程图

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

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

定点恢复(回档):定点完整备份+binlog恢复至几天内的任意时间点(取决于binlog保留的时间段);

局部数据恢复:采用binlog回滚原理,对局部数据进行恢复(有一定局限型);

两个方案均有其优缺点和应用场景,具体有关数据库回档的方案,详见运维军团公众号(ywjtshare)的前期文章《只需一招,让失控的研发哥爱上你》(特此声明:这名字不是我起的,笔者是直男)。

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

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

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

第一个阶段:纯手工阶段(费时,费力,费分工);

第二个阶段:手工阶段+部分项目的打包后台(纷繁芜杂,不易管理);

第三个阶段:客户端打包一体化后台(统一化管理,多人协作,自动化)。

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

客户端

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

4. 结束语

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

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

这个行业需要科学(规范),需要艺术(直觉),需要革新(创造),也需要谦卑(敬畏)。相信,我们一直在路上不断前行……

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

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部