畅游:游戏运维最佳实践

回顾视频:

 

以下内容根据阿里云行业圆桌论坛视频整理而成。

本期嘉宾介绍:

黎志刚,畅游运维部总监;

翔贺,阿里云资深架构师。

上云趋势不可避免,越来越多的企业启动上云之路。在云计算普惠时代,各行各业都在发生着变化。

阿里云行业圆桌会,汇聚APP、网站、游戏、金融、电商、音视频、健康、教育、能源、政务、运输、制造等12大行业类别,邀请阿里云经典客户,一起聊聊他们的上云之路,以及云上技术实践!

 

畅游业务情况简介

黎志刚介绍说,畅游在手游和端游方面做了很长时间,在游戏运维方面也积累了十几年的经验,很高兴接到阿里云的邀请,跟大家分享运维的心得。我们在去年推出了二次元的仓之骑士团,获得了苹果几轮官网推荐;我们的旗舰天龙八部,不管是端游或手游,都表现不错,特别是在MMORPG类型游戏里,大家也都可以试玩。

 

阿里云对混合云提供了哪些方案?

翔贺谈到,感谢畅游的信任,从硬件到虚拟化再到操作系统,全链路兼容性很难调试,将老操作系统应用到正式生产环境还是一个很痛苦的过程。

混合云与畅游走的很近,畅游对于混合云来讲有很明确的要求。第一,托管物理IDC质量一定要过硬,第二,云上云下一定要有大带宽,高稳定高可用的链路打通,我们会和第三方合作伙伴一起打造基础设施。在前端,混合云在安全上有很重要的优势,阿里安全体系很健全,混合云模式既保证了用户线下的场景核心需求,同时依托阿里安全防护体系,将安全堡垒又加固了一层,混合云可能比常规的云上云下打通更实际,优势更明显。

 

畅游上云实践

游戏上云有什么不同吗?畅游的上云历程是怎样的?

黎志刚认为,游戏上云和其他行业上云最大的不同在于,它的开发和版本以及应用程序特殊性很多,导致它对云上的操作系统、驱动和特殊配置上要求和其他应用不一样,这样对云的要求会更苛刻一些,不同游戏版本和类型对公有云的要求都是不一样的,我们与阿里云合作做端游的过程中,对一个产品的老操作系统版本进行一个改造,操作系统太老导致应用程序无法在云上拉写,新版本操作系统应用又搭建不起来,对此,阿里云为我们定制了一个操作系统版本。

开始使用云是比较便利的,维护成本和各方面都有很大的进步,我们的故障修复、应用上线的时间速度提升几十倍甚至上百倍。在手游井喷式的发展时,考虑资源上手游时,我们优先考虑了公有云,使用了阿里云的所有服务,目前,我们的很多业务基本都在云上跑。

 

游戏上云的趋势是什么?

黎志刚觉得,使用云后的便利性很强,在手游基本用云的情况下,我们希望端游也能够到云上,可以提高冗余性、效率等,维护的成本都可以得到控制。端游我们做了多种尝试,将老的端游进行上云测试,目前进展比较顺利。未来,手游和业游都会在云上跑,端游也会逐步迁到云上来。

翔贺也说到,上云是一个循序渐进的过程,从最开始大家不敢把游戏放在云上,到一步步逐渐尝试相信这个环境,再到现在有一定的信任。我们在做云产品时,也不会很盲目的让用户将他最核心的业务一次性的迁移上云,这就是混合云存在的价值。基于游戏的场景,我们也在不断的了解用户需求,包括DB层、操作系统兼容性、性能表现层等,我们都会在产品上去丰富,现在推出的多主频类型,就是为了能够更好适应老端游,以及很依赖CPU计算性能的场景,我们都有做尝试。

 

目前游戏行业可能接触多个云计算厂商,简单介绍下这方面的情况?

游戏要让用户访问到,只有两个途径,iOS和android,黎志刚说到,为了让用户都能访问,由于所有渠道跟用户挂入量有关,可能在推广上可以更好的为某个渠道服务时,在选择云厂商时就会有一些区别,受到市场因素限制。

 

畅游:数据库优选MySQL

畅游使用哪种数据库比较多?对于自建MySQL和阿里云RDS,畅游的选择有什么考虑吗?

畅游之所以偏爱RDS,这可能与游戏架构演变有关,最开始DB和应用都放在一台机器上或两台机器上进行交互,数据的一致性和档案的完整性都会有问题,
使用云以后发现,不管是从网络层、数据的交互整个使用上都提供了一整套的解决方案,redis可以实现memorycache实现不了的功能,这个程序被应用的场景远远多于自己写的memorycache,因为我们只面向自己的游戏,redis要经过各种应用的验证,redis的健壮性和冗余性各方面都会比memorycache更强,这时候我们就会更倾向使用redis服务。

畅游使用MySQL比较多,SQLserver和MongoDB也有一些,畅游做了那么多年游戏,有了自己的一套mysql配置标准,这个版本各种参数我们自己做了优化,能够支持公司内所有游戏的运行,这个版本也放在了阿里云实例中直接使用。我们其他游戏可能也会定制数据库,要求必须是某个版本某个数据类型,我们会与研发商技术团队沟通调整,我们会遵循研发商的意见。

SQLSERVER数据库主要针对存储过程和SQL语句做一些优化,上线过程中可能会遇到某个存储过程和SQL语句处理时间很长,导致访问效率很慢,就需要对SQLserver了解的人排障时候能够快速定位到问题,我们在用MySQL的排障方式也可以去做,由于两个数据库操作模式不同,导致排障时间不一样。不同地区游戏能对研发商选择的操作系统和数据库的版本,对于我们在引入时,都需要和研发商进行交流。

关于选择,主要看游戏的类型,如果是端游,我们会优先考虑天龙验证过的MySQL,如果是web应用或手游等,我们会直接使用阿里云提供的服务。

翔贺也补充到,从我经手的项目统计来看,国内游戏行业的DB有几种类型,SQLserver、MySQL和MongoDB以及自建数据库。从协同开发角度讲,在做一款项目时,他所能控制的在经验范围内,数据库有多大的并发写入量,数据块写入多少,能够有很精准的度量,如果用全新的技术,可能就会超出我的控制范围。阿里云RDS从设计第一天,就把高可用放在第一位,第二位是数据的可靠性,RDS已经完全可以满足游戏行业的需求,像局域缓存场景的Redis和memorycache,我们也打造高规格实例,能够满足很重度的游戏需求。

 

对于春节前夕某款游戏数据库删库事件以及gitlab删库事件有什么思考?

黎志刚思考说,我们也发生过类似事件,当时我们就做了优化调整,定期进行校验,模拟故障进行立马恢复,来看备份策略是否OK。不过,光有恢复和检查时不够的,在进行删除和格式化的过程中,如何保障不让事件发生或发生可找回,我们对操作系统安装初始化时进行改造,我们会将一些命令封装起来,工程师在系统上执行这些命令和脚本是执行不了的,需要匹配使用脚本和定制化函数才能执行。同时我们做到,如果删除同时将删除文件直接移到另外一个位置,可以被找回。

 

畅游业务架构及运维实践

伴随业务的发展,畅游架构的演变历程?

从最开始基础的C/S架构,向可以进行负载均衡的架构,把很多的应用功能进行切分,比如登录、场景和验证,我们的支付、资源都切成不同的服务器,这样服务架构相对来说就比较健壮了。上云以后,有备机可能分钟级、秒级就可以切换,没有备机十分钟内也可以解决;有redis后,数据档案的完整性会得到很大提升。

 

游戏可能有一些大流量高并发情况,对于架构方面需要做哪些工作?

黎志刚说,为了让档案数据不丢失,网络抖动各方面影响较少,游戏设计时在中间层数据库和应用之间做了一层缓存memorycache,这套东西可以保证所有数据交互时不出现丢失,可以解决高并发问题。手游现在基本都是负载均衡,如果遇到高并发,可以在负载均衡做更多事情。以前单个机房防御可能只做到10G,当使用到云上后,防御的整个带宽可以达到300G。

提到全球同服,全球同服对数据档案的共享要求很高,也对网络访问的联合性要求很高,现在全球同服用云的实践也比较多。

说起阿里云发展的海外数据节点,翔贺说,阿里云海外战略目标是要将数据中心铺到全球,从北美、东南亚到欧洲,已经上线了多个数据中心,另外一个很重要的技术特征是,有规划将数据中心通过高速通道打通,包括国内区域的跨城专线,包括国内到海外的国际专线,这种打通就解决了做全球同服时技术资源的联通性上的基础条件,全球同服对游戏类型有要求,比如SLG、棋牌以及卡牌,随着未来游戏行业在海外战略的发展,这一类项目会越来越多,阿里云希望在项目大爆发之前,将基础条件打造好,为了方便未来项目更好在云上构建。

 

畅游内部有哪些相关的运维工具?

过去五六年,我们一直想做运维自动化,最终形成了一整套完备的运维操作平台。一方面是游戏运维自动化,游戏版本的发布、上线更新维护自动化;一方面将所有的资产信息做了数据总线,构建了一套CMDB系统,该系统会将线上所有的资产信息全部在库里建好,打上标签,所有运维需要的工具、脚本和系统都经过这条总线,假如线上应用进行变更时,也是在这里先更改。
我们也做了版本发布平台,所有在服务器上运行的脚本,全部在这里登记,由系统自动发布出去,这样可以将所有服务器执行上的风险降低。出现问题时系统自动呼叫运维人员,我们内部也做了APP,所有报警信息都可以通过APP传达,我们也跟微信对接了一些东西。

将IT成本中心变成利润中心,今天畅游的体系已经非常成熟了,怎么能够很好的开放出来给其它的游戏行业客户利用呢?我们希望将自己的东西提炼成开源的架构,让同行的所有人都来参与调优,参与的人越多,对框架调优就越好。第一,先将我们的东西模块化、产品化;第二,将我们整个的运维行业人才培养计划也开放出来。

对于未来运维的发展趋势,黎志刚认为,为了不让大量业务压在肩上,首先要简化业务,做自动化运维,未来也会向智能运维、无人值守运维方向发展。大多运维都是被动式的,我们也考虑利用大数据做态势感知运维。

同时,畅游对容器服务也做了探索,Docker兴起时,结合其他公司经验,我们做了很适合畅游业务的容器,优先解决业务遇到的问题,这时我们在容器上可以跟研发团队核心生产环境做流程的打通。研发写完后直接上传到目录,由系统自动同步到预发布环境,在预发布环境可以看到是否OK。我们的Docker容器大量借鉴Docker社区和开源东西,定制化的东西想要通用使用还是有难度的,所以我们想与阿里合作使用Docker容器,这样,我的容器没有满足时,可以快速使用Docker容器,这也与混合云概念有关。

翔贺接着说,阿里容器服务第一是解决兼容性问题,会支持本地化部署,将线下东西和线上实例打通,在线下垂直环境、预发环境能够跑通的程序代码,可以一键直接发布到云平台,实现整个持续交付能力;第二,阿里与Docker已经做很深度的战略合作,未来我们会在Docker容器化领域持续发展,很有可能专门出些针对游戏行业的容器化服务。

时间: 2024-09-11 00:31:19

畅游:游戏运维最佳实践的相关文章

高效运维最佳实践七字诀,不再憋屈的运维!

做运维的那么多,快乐的能有几个? 我们那么努力,为什么总感觉过得那么憋屈.苦闷?做的事情那么多,为什么业务部门.直接领导和公司貌似都那么不领情?怎么做才能自己更加开心些? 本专栏的主线实际是一个运维人员的十年成长史,从菜鸟到运维总监.但不是基础技术教学,也不会在运维技术的某一方面过深涉及.更多的是应用技巧.实践经验及案例剖析.专栏中的系列文章,包含作者在运维各个细分领域的技术和个人成才的心得体会.因此也可以成为广大运维朋友的工具书,伴随大家从初级运维成长为高级技术型运维管理人才. 技术专栏就非得

高效运维最佳实践七字诀

做运维的那么多,快乐的能有几个? 我们那么努力,为什么总感觉过得那么憋屈.苦闷?做的事情那么多,为什么业务部门.直接领导和公司貌似都那么不领情?怎么做才能自己更加开心些? 前段时间有位IT大佬在网络上发声,我这么有钱,为什么不幸福?诚然,有钱是幸福的最重要条件之一,但有钱就一定幸福么?真的是充分必要条件?当然更悲催的是运维行当,技术好是被认可(幸福)的最重要条件,但技术再好,外部门不说咱们"坏话",已经是很不错的了.   1. 什么是高效运维 我们收集了一些来自外部门对运维的印(tou

游戏运维编年史:可能是目前最详细游戏运维指南

游戏运维编年史:可能是目前最详细游戏运维指南 从端游到页游再到手游,15年来中国网游在世界上都有着举足轻重的地位.但是再好的游戏如果出现连接.延迟等问题时也会造成巨大损失,这时游戏运维便发挥了举足轻重的作用.中国网游的发展史,其实也是游戏运维的变革史,今天便由经典武侠手游<大掌门>运维掌门人吴启超来向我们讲述,进入游戏领域10余年来的风风雨雨. 有服务器的地方就有运维 如今我们说到游戏,可能想到的是火爆异常的VR,办公室里一言不合带上眼镜就地开打:亦或是刚刚虐了李世石的AlphaGo,扬言要挑

游戏云间之浅谈游戏运维

浅谈游戏运维--游戏云间系列三 一款游戏产品上线,仅仅从技术角度来讲,分为软件层次的游戏代码研发,及硬件层次的代码部署上线.劈开代码研发方面不讲,游戏的部署上线,成为我们一个很头疼的问题.为什么头疼?从一些报告显示,大部分的游戏生命周期仅有3个月.按照正规的上线流程,从买服务器,装环境,进IDC机房这么下来,刚把游戏上线,可是游戏却不给力.这样折腾下来,浪费了多少我们的青春?浪费了多少我们的血汗钱? 一般游戏的部署有以下几种方式: 1.托管IDC机房部署. 2.代理商部署. 3.租用vps环境部

MySQL智能运维与实践,看关系型数据库如何优雅应对云时代

随着互联网场景的导入,非结构化的海量数据给传统数据库的处理能力带来了极大的挑战,作为最受欢迎的开源关系型数据库,MySQL一步步地占领了原有商业数据库市场.如今Google.Facebook.网易.淘宝等大公司都在使用MySQL数据库.而MySQL的发展也从1.0到如今的8.0版本,其功能的完善和稳定性也得到了很好的保证. 本文包含以下三部分: MySQL8.0 的新特性 云时代MySQL的运维实践 金融行业最佳应用场景 今年8.0版本将会带来哪些惊喜呢? MySQL 8.0 新特性一览 1.I

[原创]游戏云间之三:游戏运维

一款游戏产品上线,仅仅从技术角度来讲,分为软件层次的游戏代码研发,及硬件层次的代码部署上线.劈开代码研发方面不讲,游戏的部署上线,成为我们一个很头疼的问题.为什么头疼?从一些报告显示,大部分的游戏生命周期仅有3个月.按照正规的上线流程,从买服务器,装环境,进IDC机房这么下来,刚把游戏上线,可是游戏却不给力.这样折腾下来,浪费了多少我们的青春?浪费了多少我们的血汗钱? 一般游戏的部署有以下几种方式:  1.托管IDC机房部署. 2.代理商部署. 3.租用vps环境部署. 4.租用云主机环境部署.

高效运维之Redis集群技术及Codis实践

这篇是<中生代>转载的一个关于运维的文章.作者是触控科技运维总监萧田国.文章在运维圈子流传甚广.特别也发在社区,分享给感兴趣的朋友. 前言 诚如开篇文章所言,高效运维包括管理的专业化和技术的专业化.前两篇我们主要在说些管理相关的内容,本篇说一下技术专业化.希望读者朋友们能适应这个转换,谢谢. 互联网早在几年前就已进入Web 2.0时代,对后台支撑能力的要求,提高了几十倍甚至几百倍.在这个演化过程中,缓存系统扮演了举足轻重的角色. 运维进化到今天,已经不是重复造轮子的时代.所以,我们在架构优化和

高效运维:运维自动化之殇

前言 这些年来,大家都在谈运维自动化.但是否也会困惑于"只见树木.不见森林"?或者说,做了几年的运维自动化,但依然不能确定还有哪些工作没做?还有,怎样更优雅的实施运维自动化? 另外,运维自动化是万能的么?有哪些潜在问题?想了解大故障的独家剖析?且听本文分解~ 本文实际上包括两部分,关于运维自动化的一些观点(前3部分)和运维自动化的痛点(第4部分).如果已是运维自动化的专业人士,可以跳过前面内容,直接鉴赏第4部分--运维自动化之殇. 依惯例放上目录,请享用: 1. 什么是运维自动化? 2

高效运维七字诀,不再憋屈的运维

这篇是<中生代>转载的一个关于运维的文章.作者是触控科技运维总监萧田国.文章在运维圈子流传甚广.特别也发在社区,分享给感兴趣的朋友. 前言 做运维的那么多,快乐的能有几个? 我们那么努力,为什么总感觉过得那么憋屈.苦闷?做的事情那么多,为什么业务部门.直接领导和公司貌似都那么不领情?怎么做才能自己更加开心些? 本专栏的主线实际是一个运维人员的十年成长史,从菜鸟到运维总监.但不是基础技术教学,也不会在运维技术的某一方面过深涉及.更多的是应用技巧.实践经验及案例剖析.专栏中的系列文章,包含作者在运