1、前言

中国作为世界消费人口、消费水平最高的国家之一，特别近几年的新冠疫情局势，加快了互联网行业数字化进程，促进了中国泛娱乐发展加速、再加速。回头望去，互联网从搜狐、新浪为代表的门户冲浪，到腾讯QQ、微博社交娱乐，从游戏单机时代到网游时代，娱乐媒介也逐步从PC端向手机端演进，再加上基础网络2G到5G的大规模升级迭代，泛娱乐也加入了更多的直播、短视频元素，引申种类繁多的泛娱乐形式。负责“连接一切”的互联网，特别是移动互联网，第一次让内容生产者和粉丝之间的黏性与互动，达到了不间断、无边界的状态。在互联网时代，文化产品的连接融合现象明显。游戏、文学、动漫、影视、音乐、戏剧不再孤立发展，而是可以协同打造同一个明星IP，构建一个知识产权新生态。

2、中国网络游戏概览

游戏，这个在社会道德角度褒贬不一到载体却是泛娱乐演进中覆盖年龄段最广、进化最快、门类最多的、流量变现最直接的方式之一。最让我们有体感的还是中国网游，在早期大家耳熟能详的还是金山西山居旗下《仙剑奇缘》，盛大旗下的《传奇》，巨人网络旗下《征途》等客户端游戏，这些游戏属于先行者，在PC还不是非常普及的阶段红遍了大江南北的网吧，成为80后这一代人的记忆，也是因为这些游戏让网络游戏在中国普及。同时，而随着计算机的普及，2008年围绕社交场景版的网页游戏鼻祖《开心农场》的问世带动了一个新的“游戏瘦身”时代，从而带来了页游的井喷，包括了《千军破》、《傲视天地》等一系列注重游戏策划、游戏数值设计的优秀精品，而随着这块蛋糕凸显，页游百家争鸣逐步从“策划为先”走向了“运营为先”，也因此出现了后面的平台发行模式。在经历了几年沉淀，移动互联网开始成为主流，碎片化时间的强占成为游戏市场红海，手游也就应运而生，市场竞争进入白热化。在运营模式+画面要求的双轮驱动下，中国网游新时代头部玩家凸显，《刀塔传奇》、《我叫MT》、《开心消消乐》、《王者荣耀》、《原神》、《剑与远征》、《明日方舟》、《恋与制作人》等优质游戏琳琅满目，这里的厂商包括了北京的搜狐畅游、完美世界、紫龙游戏，上海的四小天鹅：米哈游、莉莉丝、叠纸、鹰角，杭州的网易游戏，厦门吉比特，广州的游戏运营公司37互娱、efun，还有大厂腾讯等等。截至2022年，游戏进入了IP时代、精品时代。

3.游戏技术进化史

3.1游戏的发展阶段及挑战

游戏根据时代主流，区分为端游、页游、手游三大形态，也完成了从大客户端时代向小客户端演进，用户操作更容易、娱乐性覆盖更全面，产品也越来越注重游戏画面，极致的用户操作体验，游戏数值设计的苛刻要求，IP场景共鸣化，网络延时低等特性，也对游戏技术解决方案，技术服务模式提出了更高的要求。从开服的第一天到导流推广、活跃运营、合服乃至玩家消耗至尽的全生命周期，技术挑战始终伴随，主要包括了：

1）业务不间断：故障期间的玩家影响重，比如无法充值、重要节点的游戏无法进行

2）游戏架构存在不合理：因为游戏有风口效应，为了快速上线往往牺牲规范，怎么快速怎么来，导致了很多设计的不合理，在故障场景的影响放大或在玩家量级翻番的情况下代码重写对游戏来说基本不可能

3）基础设施不完善：在端游、页游的早期还是以IDC托管支撑为主，运维人员即要做机器选型，又要上架、配置网络、部署系统等复杂的过程，在游戏快速增长的背景下太低效

4）日常运维工作繁杂：服务器上线后的运营阶段工作非常繁杂，开服、清档、合服、运营查询这一些列的维护工作反复、易错。

3.2游戏技术服务演进

3.2.1 技术架构演进

3.2.1.1 原始架构时代：从典型互联网的BS架构向游戏CS架构转变

从游戏形态来看，客户端游戏早期以CS架构为主，而不用BS架构。CS框架的好处是将游戏数据存储在本地，能够充分发挥主机性能，使得玩家能够获得流畅的游戏体验，个大型的网落游戏服务器应该包含几个模块：网络通讯，业务逻辑，数据存储，守护监控（不是必须），其中业务逻辑可能根据具体需要，又划分为好几个子模块，运维阶段面临的问题更多是游戏内多模块的调用，所以核心要做到Server端的细化服务运维。

典型互联网的BS架构向游戏CS架构转变

3.2.1.2 石器架构时代：从传统IT “All in one”架构至云上稳定性架构转变

而在页游、手游形态阶段，架构较为通用，这阶段以弱交互游戏为主，这种服务器架构和我们常用的web服务器架构差不多，也是采用nginx负载集群支持服务器的水平扩展，多以LNMP/LAMP架构为主，且大部分未做高可用。客户端通过入口到游戏大区列表，根据选服务访问对应系统，web层面多用Nginx或apache，结合php-fpm或tomcat，数据层落单点mysql存储，这样单游戏在一台服务器上的架构我们形象的称之为“All in one”架构。这个架构最大的问题无疑就是故障场景往往无法快速恢复，在极端的硬件损坏场景影响往往很大，所以非常依赖运维工作，这也是最早的刀耕火种模式，运维需要建设数据库多机备份模式、异常快速拉起能力、服务进程稳定性等。

传统IT“All in one”架构 云化架构

3.2.1.3 黄金架构时代：多游戏场景的精细架构演进

随着游戏业务场景多样化，云产品更加丰富，架构使用上更加精细化。就有了云原生游戏架构，通过云产品能力等组合打出场景支撑组合拳，让运维更简单。当后期国内游戏受到政策影响，及国产化游戏出海成为趋势，海外加速也不断的涌现，更加剧了全球同服架构进化。同时，面对游戏运维、运营的各种业务需求，也派生了多场景大规模数据存储、数据分析等架构，时至今日，架构还在不断精进......

某游戏云原生游戏架构 某游戏海外加速架构

3.3 游戏技术服务实践

3.3.1 游戏运维SRE实践

3.3.1.1 制定SRE黄金准则

• 架构设计准则  - 我们认为所有的架构都是不完美的，都存在缺陷，因此我们在做业务架构设计时都必须要考虑服务稳定性保障，如负载均衡、多点容灾、集群化服务、数据多活等能力；
• SRE 前置准则  - 在业务立项之初，SRE 角色需要提前介入，将运营阶段可能出现的问题或风险提前在架构设计、编码阶段暴露，提前准备好解决方案，甚至规避问题与风险；
• 混沌实验准则  - 故障不可避免，为何不让其在测试或预发布环境提前到来，通过模拟现网真实故障来验证服务的“韧性”，找出系统的弱点，同时验证我们的监控告警的有效性，是我们的第一把利器；
• 可观测性准则  - 通过采集业务指标、日志、追踪等数据，快速分析与定位问题，同时发现复杂系统的瓶颈点，在很长一段时间内，业务指标、日志、追踪的采集与应用，都是独立存在并分开建设，随着时间的推移，发现这三者是相互关联，相辅相成的，是我们的第二把利器；
• 全链路压测准则  - 通过与可观测性、混沌实验能力的深度整合，实现模拟真实业务环境全链路压测，达到业务上线前的精准资源评估，主动发现潜在性能、版本缺陷等问题，是我们的第三把利器；
• DevOps 交付准则  - 通过打造高效的价值交付链，覆盖 CI、CD、CO 服务全生命周期运营管理，CI 我们采用 ODP 封装蓝盾方案，CD 与 CO 采用运维编排及监控告警等能力，SRE 会将大分部精力聚焦在 CO 环节；
• 故障应急准则  - 故障不可避免，我们能做的是不断去提升 MTBF（ 平均无故障工作时间 ），降低 MTTR（ 平均修复时间 ），包括事前的实施大量混沌实验、故障预案；事中采用打造的工具链，快速发现、分析、定位与解决问题；事后组织总结复盘，沉淀案例经验；
• SRE 学习准则  - 营造学习的文化，目的是实现多个不同职能团队的有机融合，相互了解大家面临的问题或挑战，形成一致的目标，达到有效的协同，解决业务问题。

3.3.1.2 游戏自动化运维体系构成

3.3.1.3 游戏部署的自动化实践

传统IT模式的“半人肉”部署实践

游戏运维的早期开服以人肉为主，分区分服务阶拆解的最原始动作包括：游戏服务端打包->解压游戏包->变更配置修改区服务->初始化数据库（清档）->QA测试->对外开放入口。如果今天的服务器只有一台两台没有问题，随着服务器数量增多，实践中经常遇到游戏火爆的突发开服事件，而且在2011年后游戏联合运营模式出现，人肉模式会涌现了很多问题，而且随着开服时间拉长，到一定生命周期后也面临着繁复的合服工作，游戏运维对开服、合服做了脚本化工作，那也是自动化的早期雏形。

早期的版本部署/变更脚本示例：

游戏上云后的镜像部署实践

基于shell半自动化工作，基本可以应对百至千服的常规工作，随着虚拟化普及，游戏上云后ECS的镜像功能开始普及。所以，游戏运维通常会通过游戏服务镜像的功能，让你快速启动另一组服务器，例如你搭建完一组，共三台，游戏服1，游戏服2，游戏服3，调试完毕后，为每个服做一个镜像，这样你就可以快速启动1组新服，很快就可以完成上百组服务器的配置，在需要开新服时，你基本5分钟就可以开一组，所以为每个不同角色的游戏服留镜像是很有必要的，同时也可以使用跨区复制功能，快速在另一个region搭建新服，快速完成多region部署，这些工作通过api是可以做到完全自动化的，基本实现了数千台规模的服务部署。

基于Ansible的自动化部署实践

前面讲到，最早的时候我们用 SSH 写很多脚本，要用 SSH 连过去，也是在某一台机器上执行，不用在目标机上登陆。这种做法在相当一段时间内是我们实际使用的手段，它实际上比 Puppet 有效。但是它有一些问题：管理成本高、脚本会越来越多。部署的过程有很多的基础部件需要反复部署，几乎是没法管理。后来我们用了 RunDeck，它有界面、有一定的管理能力。我们还用过 Fabric，即批量执行命令，能做到类似部署的事情。但是，目标机规模大了之后仅有管理的能力是不够的。后来我们又调研过 Salt，不认为有太大的差别。选择 Ansible 主要因为丰富的相关支持，包括很多现有的组件和模块和开源的 Ansible 部署和脚本。我们的团队不喜欢纠结。我们发现 Ansible 它可以配置系统，部署软件以及协调更高级的IT任务，例如持续部署，滚动更新。Ansible非常适用于管理企业IT基础设施，从具有少数主机的小规模到数千个实例的企业环境都很通用，整体具备了简单、强大、无代理的三大核心优势。通俗的讲，Ansible的底层就是pssh的批量逻辑，上层封装playbook执行，而playbook的语法非常接近shell，从历史的部署模式进行改造升级相当方便，基本实现了数万台规模的服务部署。而我们也发现这套框架在游戏版本更新、机器初始化、回收下线等场景屡试不爽。

3.3.1.4 游戏稳定和安全的具体案例

1）对于一些全球同服的游戏来说，稳定性问题如何解决？

阿里云提供的全球同服解决方案，大概分三个层面。第一个层面，解决跨国骨干网络的传输问题。游戏产品需要一条稳定、低延时、几乎无丢包的通信线路，才有可能去构建一个所谓的全球同服架构。在使用云服务前，用户需要去花极高价格去租借跨国通讯线路，整体流程也非常冗长，而且当业务临时发生变化，变更成本会非常高。如今，用户点几下鼠标就可以了。

第二层，全球数据的交互和同步。在分布式缓存时，很多数据会送往唯一决策的地方记录和计算。可以说，数据同步是一件难度不低的事情，除了要求稳定的网络链路外，还需要有很好的同步机制。当同步出故障时，未完成任务如何继续处理，如何避免“脑裂问题”（两边数据对不上），在此基础上如何保证数据同步服务的高稳定性。

第三层，全球范围流量调度能力。你可以把这部分理解为最后一公里，在前面都已经部署完成后，这个最后一公里显得尤为重要。就算此前的骨干网络效果再好，如果最后一公里接错了位置、或者经常抖动，整体效果也不会很好。

具体来说，全球调动能力主要通过几点。其中一点是阿里云这边的智能DNS解析，这个功能会根据用户所在IP地址，提供相应的访问接入点。

2）针对安全防护，游戏运维怎么办？

通过阿里云 DDoS 高防、风险识别等安全产品，帮助游戏行业客户构建全面的安全防护体系，满足抵御攻击、合规运行、提高业务风险等级等不同场景的安全需求，保障游戏业务运行的稳定、安全。

应用场景

• DDoS攻击防御： 通过 DDoS 高防或游戏盾有效抵御各类流量攻击，避免流量攻击造成游戏业务卡顿甚至瘫痪影响玩家游戏体验。
• 游戏防沉迷： 对玩家身份信息真实性进行核验，验证用户为真人且为本人，防止未成年人沉迷游戏，同时有效避免未成年人冒用账号问题。
• 游戏风控： 通过游戏风控，解决羊毛党、机器人、账户资金的异常提取、盗号等安全风险，避免灰产工作室恶意注册、撞库、垃圾账户等业务风险引发的平台资损及品牌影响。
• 等保合规： 通过等保套餐帮助客户具备等保要求的安全能力，快速帮助企业满足国家合规监管政策要求。

方案优势

• 快速构建基础安全能力： 通过 DDoS 防护、云防火墙和云安全中心，即开即用，帮助客户快速建立基础安全能力保障业务连续性，能够防御典型网络攻击和入侵检测，保障游戏登录等平台稳定性。
• 整体纵深防御体系： 通过阿里云最完整的安全技术产品，帮助客户实现网络、主机、应用、数据、业务五大维度防护能力，构建完整的云上纵深防护体系，在抵御攻击提升安全能力的同时，能够满足安全合规要求。
• 特色游戏场景化风控： 针对游戏打金工作室、虚假注册、游戏小号、薅羊毛、盗号、虚假点击等黑产行为，通过风险识别产品，帮助客户构建风险画像，结合智能算法先进技术进行精准识别，可大幅减少黑产对游戏运营、经济系统、玩家体验等造成的伤害及影响，实现降本增效。

安全方案架构

3.3.2 云模式下的游戏护航实践

3.3.2.1 游戏护航需求

进入到云模式后，从游戏客户运维视角，用了云后基础设施对用户来说是黑盒，客户只用了一台简单的ECS主机，并不了解背后的虚拟化架构、宿主、网络、共享情况和隐患；而从云技术服务视角，只交付给客户的产品并不了解客户单体使用场景，多体的行业技术，产品稳定≠用户业务稳定性。特别对于使用公共云的用户来说，一旦业务出现问题更显得手足无措，因为并了解状况，不知道是自己的问题还是云厂商的问题，也不知道怎么恢复业务，焦虑、不可控，这是对运维的新挑战。也因为游戏导流运营节奏，可以毫不夸张的说，开服前7天的数据决定了一款游戏的成败，游戏护航成为最最重要的技术话题。

3.3.2.2 服务护航流程

• 护航目标分析制定： 游戏业务背景了解，将业务语言翻译为技术语言，明确技术要求掉和目标，保障开服前期业务稳定；
• 业务现状分析： 对现状的业务架构做梳理，了解资源资源分布情况、业务归属情况，对潜在风险做巡检和扫描手机，做目前性能的量化分析。
• 制定保障方案： 明确资源预留情况，对潜在风险扫描、识别，对不满足预期的模块做系统评估，并扩容，通过性能压测、高可用建设、准备预案、进行演练等形成全面的保障方案。
• 执行保障计划： 通过清晰的保障方案执行，增派技术服务专家进行客户现场驻场，对护航期间的问题进行及时处理，通过实时监控和高频巡检，即时识别问题、闭环问题；
• 复盘总结： 事后的护航总结报告输出并和客户组织复盘会议，不断实践循环保障并迭代方案。

3.3.2.3 云产品巡检Q&A

4.游戏技术服务展望

如今，各类游戏已经深深嵌入人类文化之中，因此它们总是紧跟时代精神的发展趋势。直接影响游戏产业的数字技术领域将有所发展，但不仅如此，从更广泛意义上来，我们将迎来一场革命性的技术变革。AR和VR引来更蓬勃的发展，机器学习和人工智能在App领域深耕，区块链游戏、云游戏、元宇宙更多的新技术接踵而至，而围绕游戏技术的行业服务也将越来越成熟。