网易雷火UX用户体验中心编译，转载需注明本公众号关于GDC
GDC是全球游戏行业最具规模、最有权威、最有影响力的专业峰会。GDC2022中，雷火UX共获邀17场演讲，分布在9个核心演讲以及8个峰会演讲，再度刷新中国游戏行业纪录，领跑全球。
每年的GDC大会上，全球顶尖的游戏开发者们将齐聚在这里，交流彼此的想法，构想游戏业的未来方向。接下来雷火UX公众号会选择一部分高质量的演讲，陆续为大家进行介绍。本篇为大家介绍的是来自动视公司的工具开发工程师Adrian Astley的演讲“Tools Summit: Efficiently Shuffling Loads of Data from Place to Place ”。Adrian Astley
Tools & Infrastructure Engineer, Activision
演讲标题：
Tools Summit: Efficiently Shuffling Loads of Data from Place to Place工具峰会：高效、均衡的跨地区数据传输演讲者信息：Adrian于2017年加入电子游戏行业，主要从事开发工具和基础设施管理方面的工作。他开发的工具帮助动视发行了6款《使命召唤》游戏以及旗下其他游戏。
演讲概述：
本次演讲中，Adrian分享的工具Indy，用来进行批量数据传输和分布式构建工作。Indy工具非常成功，已经稳定运行超过4年，覆盖动视几乎所有项目，节约巨大的带宽资源和时间，实现全球化多地协同工作。该演讲对Indy工具进行了全面介绍，并总结了开发和使用过程中的经验教训。
01. 问题描述
动视的游戏开发模式是采用大型分布式开发，特点就是多工作室、多岗位、多地区、多QA站点协作开发，多个LAN网络通过WAN网络进行通信，地理上分布于美国、澳大利亚、上海和欧洲等。目前遇到的问题如下：
跨地区跨机器的数据传输游戏测试的任务包括编译构建代码，制作游戏数据，运行游戏。这些任务在多台工作机器上并发运行，能更好利用服务器资源，提升测试效率，但同时也带来了服务器之间数据资源的传输问题。存储过于简单文件共享服务器最初搭载的是SMB或NFS等文件系统，不具有扩展性。延迟巨大如果文件共享服务器放在美国加利福尼亚，其他地区获取文件延迟是巨大的。
下图是不同地区向加利福尼亚文件共享服务器传输1GB文件需要的传输耗时数据。加利福尼亚本地传输只需几秒，其他地区，上传耗时高达几千秒。随着传输延时的增加，带宽也会急剧下降，任何在远端地区工作机上进行的任务会越来越慢，最终将无法使用。
扩展性和容错性
文件共享服务器负载过大，服务器宕机或需要维护或者断电了，需要考虑系统扩展性和容错性。数据去重
下图的所有任务都需与文件共享服务器进行数据的交互。即使两次任务只有小许修改，都需要再次上传和下载所有数据，这样一来造成很多重复的存储。
同时游戏数据量非常大。假设每小时有10次代码提交，每次需构建3张地图，数据大小约为70GB，目前需要给5个平台（PC,XB3,XB4,PS4,PS5）进行编译，那么每小时的数据量84TB。如果需要测试3张地图，每张地图做2次测试，那么每小时测试的数据量是21TB，一天就是504TB。
数据需清理
不清理是不可能的，因为数据实在太大。如果通过脚本遍历文件进行清除，遍历操作随着文件系统不断变大而陷入死循环。
02. 历史做法存在的问题以及如何提升
历史的一般做法是使用多种开源或者内置的工具进行数据传输，这样很混乱，没有完整的系统，过程中也存在很多问题。历史做法及存在的问题
● 打包工具包括一些安装程序，压缩工具和Docker系统。安装程序，如linux的.deb/.rpm, 是将一组文件通过脚本进行组合安装，有些安装程序会只复制不存在的文件，但都没做下载的去重检查，每次下载都需要下载全部安装包。压缩工具，如zip/tar/7zip等，不会做数据去重。Docker系统有不错的文件隔离和重复数据删除属性。● 数据传输工具，有很多开源的和内置的工具，如微软robocopy。这些工具只需提供源目录和目标目录就可以并发地、快速地进行数据传输。文件比对通过比较文件大小和时间戳等，并不是百分百准确。最佳的比对方式是基于内容的Hash值比对。为了计算Hash值就必须去共享服务器上下载文件，需要用户去鉴别文件是否重复。以上的工具都是基于文件系统的基础上使用，不具备可扩展性。如何提升
首先，要明确提升的目标：
● 简单二进制的客户端工具；
● 基于数据块的数据去重功能；
● 自动清除无用数据；
● 系统组件垂直可扩展，具备容错性，尤其是数据存储方面；
● 能充分借鉴和利用开源工具和社区资源。基于这些目标，需要做的事情如下：● 本地命令行输入终端，用户可输入命令进行操作，命令语句明确且易用，能使用脚本运行；
● 能把文件上传到远端的服务器。因为文件共享不是很好的方式，所以可选择HTTP对象存储作为文件服务器；
● HTTP是高度可扩展的，可跨平台，有丰富的工具和完善的基础设施；
● 需要一些服务器的组件，专门用于数据去重和数据清理等。
03. Indy工具的全面介绍
Indy工具包括二进制客户端indy，元数据服务器Ark，云对象存储服务器WebDAV，使用Golang来开发工具和服务器组件。Indy通过Image来组织所有的数据资源。Image包含文件包，ENV变量，以及处理文件/变量的命令操作。
图示的系统有客户端A和B，Ark元数据服务器，以及对象存储服务器。第一步，Client A通过“Indy build”命令创建一张Image，并且它想要共享这张Image。接下来，Client A通过‘Indy push’命令，会告诉Ark需要上传的数据，然后Client A并发上传构建的图到对象存储服务器。Client B通过“Indy pull”命令进行下载，告知Ark需要下载的数据，然后从对象存储服务器下载。下载下来的图像是不能直接使用的，需要用“Indy mount”命令加载为一个Image对象才可以使用。
图像的构建需要创建IndyFile文件(下图左)，利用自定义语言对图像的内容进行定义。自定义语言如“Add”指令是添加文件，“CHUNK”指令是切割文件。有了IndyFile之后，就可调用“Indy build”命令。Indy工具会读取IndyFile中的指令，并运行指令创造一张Image。Build命令会输出一串Sha1哈希串，用于唯一标识Image。通过Sha1值去引用图像是不方便的，所以通过创建一个可读性友好的标签（Label），作为一个指针来引用Image，标签格式如下图右。
命令“Indy build“运行IndyFile的指令生成一张Image的内容清单，如下图。图像清单是JSON文件，列出了所需的文件，每个文件包含了文件块的Sha1值和大小。
如上所述，标签是一个可读性友好的指针，用来引用图像，如下图标签为aastley/gdc-test:v1，它指向图像obff1。因为标签是指针，所以可添加任意数量的标签来引用同一张图。“Indy images”命令可查看本地所有图像。标签可设置TTL（Time to Live），代表标签的过期时间。
当TTL到来时，运行“gc”命令进行垃圾回收。Indy的引用层次结构如下所示。最上层是标签，顶层标签都指向一个特定的图像。各图像指向包含的文件块。需注意的是，文件块可以被多个图像所共用。
垃圾回收有3个阶段。第一阶段是检查标签TTL是否过期，过期就删除，如下图标签aastley/my-awesome-label:123。
第二阶段是检查所有图像，未被任何标签引用的图像可删除。图obbf149和f1d2d2f皆有标签引用，所以无需删除。
第三阶段，对所有文件块的引用数进行计数，文件块的引用数为0表示没有被应用，可删除。
“Indy push”命令用来进行数据上传，告知Ark需要上传的数据，Ark会查询数据库找到对应的文件块，再把查询结果返回给客户端。Indy客户端只上传Ark查询缺失的文件块到云存储服务器。Indy最后会发送一个POST请求给Ark，告知上传成功。Indy只会上传缺失的文件块，因此大大节约了带宽资源。
Indy客户端通过标签向Ark获得图像的Sha1值，通过这个值去对象存储服务器上获得IndyFile。Indy比对IndyFile和本地已有的文件块信息，计算出本地没有的文件块。Indy调用pull命令从对象存储服务器并发下载本地缺失的文件块，有效节约带宽资源。
对于缓存系统来说，由于文件是基于内容的Sha1哈希串来标识，所有文件都是不可变的，不存在缓存的一致性问题。下图的系统有中央对象存储器，每个工作室有专门的缓存节点。所有客户端内部的下载和上传操作都通过缓存节点，客户端无需连接中央对象存储器。这个模式的优点如下：
● 缓存节点缓存文件，工作室内所有客户端通过LAN从缓存节点下载数据，减少WAN带宽，降低对象存储器的负载压力。
● 缓存节点是可控的，可做更有效的专门调整来保障WAN流量尽可能优化。
● 缓存节点是可扩展的，通过增加缓存节点提高负载能力，增加容错性。多缓存节点下，遇到缓存节点维护或挂了，客户端仍可使用其他在线服务的节点。
另外，如何来确定文件块的大小呢？演讲者分享了一个实验，创建不同大小的文件，分别放到两个基本一样的nginx服务器。一个nginx服务器是20Gbps网卡，另一个是40Gbps网卡。每个文件下载1000次，测算下载速度。当文件块大小只有100KB时，吞吐量很低。即使是40Gbps的网卡，也只能到达约8Gbps的带宽。
文件在1MB大小时，性能明显提升。10MB大小时，到达了20Gbps网卡的最大网速，接近40Gbps网卡的最大网速。HTTP请求的数据交换量越大，可以看到有效的带宽数据越高。但是，数据超过10MB之后，下载速度趋于网卡的最大速率。
文件块大小的选择，还需要考虑数据去重和HTTP重试的影响。对于过小文件块，带宽基本保持不变且很慢。对于过大文件，即使文件块只修改一个字节或者传输中断，仍需要重传整个文件块。从实验数据来看，1-5MB大小的文件块可以在传输速度、数据去重和重传之间达到一个好的平衡。
04. 开发和使用过程中的经验教训
演讲者对开发和使用过程中的经验教训进行了总结，为相关人员如何更好的利用这一工具解决大规模数据传输问题提供参考。● 警惕BUG：Indy被广泛应用，每天都有成千上万的任务运行。如果一个BUG发生的概率是1/1000,000,000，如果每天做100,000,000次操作，那么这个BUG每10天就会出现一次。● 过硬的硬件质量：对大规模的工作集群来说，磁盘/内存会坏掉，系统会蓝屏等，且这些状况随时会发生。为了预防，Pull和Push操作过程中都要做数据校验。此外，存储数据的磁盘必须是可靠的，一块磁盘坏掉了，它上面的所有的文件都会损坏。● 预防网络拥堵和DDoS攻击：Indy系统包含许多数据，必须时刻关注网络环境。如果网络遭遇拥堵或DDoS攻击，客户端请求失败然后立刻请求重试，这样恶性循环网络拥堵更加严重。解决这个问题，需要对所有请求增加随机指数回退机制，保证网络恢复时没有新请求。● 优化防火墙配置：由于几十个缓存节点会在一瞬间产生Gbps级别的网络带宽，这就需要提前报备IT部门。为了防止Indy占用公司的所有带宽，需要在防火墙上做流量整形，确认防火墙的级别，确保所有设置是启动的。● 安全完整地创建文件：使用多线程/多进程创建文件，创建文件标准做法是先写到临时文件，再系统调用fsync()，最后重命名文件。为了确保写入是安全和完整的，调用fsync()且重命名文件之前要确保数据已经刷新到磁盘中。● 使用S3对象存储：NFS文件系统不能扩展，有单点失败问题。
05. 总 结
通过对Indy，这一协助动视暴雪曾成功制作和发行了多部《使命召唤》游戏的工具的介绍，演讲者为大家分享了在全球多地协同开发过程中如何提升效率的方法。最后演讲者提出了未来的开发计划，以期更有效的节省资源和成本，实现全球化多地协同工作。
● 完善服务器的权限管理
● 开发缓存节点的服务自发现功能
● 完善客户端命令的机制
● 开发GUI界面的构建管理系统，提升用户友好度
