当前位置: 亚洲城ca88 > 计算机网络 > 正文

笔者们对手机游戏做过的那三个事儿,在玩耍运

时间:2020-03-25 10:59来源:计算机网络
写在前面 时代背景 讲师介绍 最近由于游戏业务的迫切需求,我们需要启用一套可靠的异活双活方案,降低业务的单点。大世界类型游戏的特点是组件模块化,战斗节点、数据节点、登
  1. 写在前面
  1. 时代背景

讲师介绍

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

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

陶会祥

  1. 异地双活之演进2.1 第一阶段
  1. 浅析手游架构

乐视云数据库负责人

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

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

先后任职于人人网、新浪、多点等公司。 期间任高级DBA,数据库架构师等职。拥有丰富的数据运维管理、自动化平台建设经验。

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

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

分享大纲:

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

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

乐视数据库介绍揭秘私有云RDS架构及实践

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

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

一、乐视数据库概述

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

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

1、数据库平台介绍

2.2 第二阶段

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

我们数据库部门的数据库种类较多:有MySQL、Oracle、MongoDB、Redis等。从另一角度,可分为传统的DB (MySQL、MongoDB..) 及云数据库RDS。其中,MySQL在公司内部广泛使用,今天将就乐视MySQL的运维情况进行分享。

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

图1 手游开服型架构图

2、数据库产品现状

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

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

MySQL版本较多,有官方MySQL5.5、MariaDB10、PXC5.6等;架构有1主多从、1主多层、PXC(Percona-XtraDB-Cluster)等结构;硬件有SAS盘、SATA SSD,主要使用SATA SSD。3、数据库架构

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

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

Master-Slave 结构有:

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

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

1主N从1主N从 MB (master-backup)1主N从 Relay

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

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

提个问题,图中1主N从 Relay结构,引入relay有什么优缺点?

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

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

优点:在跨机房高可用时,布署一台同步用的relay 在异地机房可减少跨机房同步带宽。缺点: 增加了架构复杂度,主从关系变成多层树结构。若是使用不当,比较乱,易出错。我见过超过4层的主从,梳理关系就很麻烦,建议不超过3层。4、数据库监控

我们来看看压测结果:

图2 手游大世界型游戏

我们的数据库监控以开源软件为主,有天兔Lepus、Prometheus、Open-Falcon等。

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

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

(1)天兔

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

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

Lepus是一个由Python PHP开发的数据库企业级监控系统支持MySQL/Oracle/MongoDB/Redis等数据库的监控

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

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

对于不是特别大的DB规模,天兔监控就够用,也挺好用,可省去大量开发成本。

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

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

(2)Prometheus

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

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

Prometheus是一个开源的服务监控系统,它通过HTTP协议从远程的机器收集数据并存储在本地的时序数据库上。它提供简单的网页界面、一个功能强大的查询语言以及HTTP接口等。

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

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

(3)Open-Falcon

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

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

我们用Open-Falcon来做服务器基础监控。对Open-Falcon进行了一些2次开发,如增加电话报警功能、IDC 的概念。

  1. 参考资料

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

(4)作为补充还有Zabbix、微信告警等

-cluster-install-linux-rpm.html

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

此外,公司监控平台提供email报警,短信报警,电话语音报警。

-cluster-ndbd-definition.html

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

作为补充,数据库平台增加了微信告警。 优点是方便,成本低。 重要性大于邮件的,不到电话或短信级别的可以用微信。

-xtradb-cluster/5.7/index.html

该架构的特点:

5、数据库备份

-webpages/mysqlwsrepoptions.html

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

数据备份是非常重要的,我们的DBA也非常重视数据库的备份工作。在这我把备份概念略微扩展,我认为数据库实时从库也是一种备份。

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

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

实时从库

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

大存储机器 单机多实例布署(20-30 )重要业务 异地机房从库多源复制从库

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

说明:

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

我们找了一些大磁盘存储10T ,在具布署了30 左右的MySQL数据库,不提供线上服务。 这样相当于在一台机器上有30个DB的热备份。对重要业务,进行异地跨机房从库制作。可避免单一IDC异常,引发故障。乐视有一些统计分析数据库,使用MariaDB多源复制,一个实例同时同步多个主库。某些情况也可以使用分析库来恢复数据。

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

冷备份

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

xtrabackup 物理热备份全备 增备Mount 挂载大存储定期清理历史备份

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

主要使用xtrabackup来物理备份MySQL。使用了全备 增备,每周至少一次全备,多个增备。为了简便,增备只做基于全备份的增备,并没有使用增备的增备。利用Mount 挂载大的存储 30T,做为备份存储。为避免存储容量满,会有脚本定期压缩,清理历史备份。

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

二、私有云RDS实践

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

1、私有云RDS项目背景

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

为什么做私有云RDS? 有各种理由: PaaS平台的流行,老板提出需要把数据库服务化、容器技术兴起、成本优化(硬件成本 管理成本)、用户体验等。

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

但是最真实原因:忙!

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

2、RDS介绍

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

乐视云RDS基于Docker Mcluster 开发的一种高可用、可弹性伸缩的在线数据库服务(Relational Database Service,简称RDS)。

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

其中,Mcluster(MySQL Server Cluster)是MySQL数据库集群。

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

Mcluster是我们开发出的一种私有云MySQL集群基于PXC (Percona Xtradb Cluster)封装和调优真正的多主架构没有单点故障,高可用性是RDS的根基良好的扩展性

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

PXC官方的链接: -xtradb-cluster/5.6/index.html

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

3、私有云RDS架构

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

(1)架构图

图6 机柜故障

RDS整体架构主要分为以下几大部分:

图7 市级故障

Docker:乐视云RDS是跑在Docker容器内部Database:为具体的数据库。可以是MySQL,也可以是PostgreSQL等任何数据库Matrix:负责前端数据库创建、管理、监控、维护和相关资源调度BeeHive:负责资源的调度管理,BeeHive类似KuberneteData Analysis:负责数据库日志的分析还有用户行为分析

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

(2)RDS架构图2

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

普通用户登录私有云平台matrix,申请创建RDS。 BeeHive计算分析机群中的资源情况,选择合适的3台机器布署Mcluster DB,同时还会额外布署一个VIP容器来做DB高可用和负戴均衡。

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

用户可以通过此VIP来访问MySQL。RDS管理员可通过matrix后台对平台全部的RDS进行管理、监控运行状态等。

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

4、Mcluster架构

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

Mcluster是乐视云基于PXC (Percona XtraDB Cluster)封装和调优的私有云MySQL集群。因为基于PXC封装,故Mcluster具有和PXC 相同的特点。

图8 数据库备份流程图

多点读写机群中任一DB节点都可以写入并行复制可以多个线程复制,以事务为单位,多个事务同时并行推送到所有集群节点强一致性各节点数据强一致性高可用性单一节点故障不会影响机群的可用性兼容传统MySQL与传统MySQL几乎完全兼容,数据可以直接使用不需要任何转换

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

Mcluster和主从MySQL对比

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

RDS界面

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

RDS界面——用户前端

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

类似阿里云、AWS的RDS用户平台页面。用户选择RDS的配置,主要是磁盘及内存,点下一步,就可以提交RDS申请。(每个用户可以免费建3个,超出需要DBA审核)

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

RDS界面——管理后台

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

RDS管理员可登录管理后台进行RDS管理,主要功能如下:

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

用户、宿主机资源管理RDS日常管理 申请审核,RDS信息查询,人员变更等Docker 容器管理RDS备份RDS监控 RDS运行状态监控

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

DockerFile

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

DockerFilek完成的工作:

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

安装及配置MySQL安装相关软件启动mcluter-manager

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

Mcluster-Manager

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

大家可以看到在DockerFile最后一行,会启动mcluster-manager。

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

Mclustre-Manager功能:

  1. 结束语

tornado的web服务启动、停止初始化MySQL监控、管理MySQL

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

mcluster-manager安装在Docker容器中,用来管理MySQL。外部系统不直接操作MySQL,而是通过mcluster-manager API 调用。包括启动、停止、初始化、监控、备份、管理MySQL等功能。

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

RDS运用

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

私有云RDS上线后大大减轻了DBA工作量,降低了服务器成本和人力成本。 目前在乐视体系各子公司得到广范使用。

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

运维和坑

数据库规范、流程非常重要私有云 可节省大量机器成本及人力成本私有云RDS产品设计、管理该异与公有云RDS用户在线修改大表,引发故障多节点同时大量写,容易引起死锁组件较多,相互间依赖太强运维工具待完善 如宿主机器故障,恢复工作量大

数据库规范、流程非常重要,因为这是运维自动化的基础。我们吃过这个亏,数据库版本众多,并且安装目录不同,带来很大的麻烦。

使用私有云确实是可节省大量机器成本及人力成本,这个在乐视云是可以确认的经验,因为我们每台机器上安装了20-30个Docker,即跑了20-30个MySQL,较传统的MySQL布署节省大量成本。若是有个别业务写入量特别大,因为PXC多份写的原因,这时我们也可能迁移到传统的主从DB方式。

私有云RDS产品设计,管理该和公有云有区别。如曾经有RDS用户在线修改大表,引发故障。在公有云上,DBA不用关心此问题。 但是因为是公司内部用户,是私有云,故只能是我们DBA来处理,善后 :( 另私有云常还有产品树的概念,而公有云就不用类似的设计。

组件较多,相互间依赖太强。我们的RDS 系统做得还是有点太复杂,未来版本希望可减化。

运维工具待完善,如宿主机器故障,恢复工作量较大。 某一宿主机故障,要恢复20-30 的DB。当前是DBA手动执行脚本,还是有点low。

QA

Q1:数据库备份主要是使用物理备份还是逻辑备份?A1:主要使用xtrabackup物理备份MySQL。

Q2:使用数据库增量备份,恢复起来很麻烦吗?

A2:乐视云使用基于全备的增备,并不会进行增备的增备。恢复起来并不麻烦。

Q3:PXC多主架构是否是采用一个节点写,其余节点读的架构?

A3:多点大量同时写数据,有时会有锁问题,所以我们主要是写一节点,多节点读。

Q4:如果写的节点挂了怎么办?

A4:我们前面有个架构图,用户通过Gblance来访问RDS。(相当于做了VIP高可用)

Q5:前面讲到广州到北京复制,你们走公网还是专线?

A5:我们使用专线。乐视云在全国有10多个机房。大机房之间走专线。

Q6:乐视云RDS是否存在着licence问题?

A6:不会有licence问题。我们的RDS是基于Docker MySQL开发,而MySQL、Docker都是开源软件,没有licence风险。

Q7:乐视云RDS会开源吗?会对外提供RDS服务么?

A7:目前暂无开源计划,只用在集团内部提供私有云服务,但依公司发展战略,不排除未来提供公有云RDS的可能。

回听分享,请戳这里:

?topicId=240000551075265isGuide=Y密码:159

文章来自微信公众号:DBAplus社群

编辑:计算机网络 本文来源:笔者们对手机游戏做过的那三个事儿,在玩耍运

关键词: 亚洲城ca88