作为万代南梦宫娱乐公司（BNE）打造的一款全新手机游戏，《七龙珠：武斗传奇》基于公司旗下广受好评的“龙珠Z”系列作品，目前已经向全球玩家正式开放。为了做好准备以飨玩家服务，BNE 早在2017年2月就开始与 Google Cloud 沟通，探讨这款游戏可能面临的种种挑战，希望 Google 方面能够提供足以应对各类实际负载难题的强大云基础设施。
根据预期负载强度，BNE 方面提出了以下三条雄心勃勃的具体要求：
1.极高的可扩展性。这款游戏将在全球范围内发布，因此需要一套能够支持数百万玩家并确保良好游玩体验的强大后端。
2.全球网络。这款游戏允许玩家之间实时战斗，因此需要配备跨地区高可靠性、低延迟网络。
3.实时数据分析。这款游戏支持玩家间的实时互动，因此要求数据分析流水线将数据流即时传输至数据仓库。以此为基础，运营团队将能够衡量并评估玩家们的具体游玩方式，进而对游戏内容做出快速调整。
在这三个领域，我们都拥有着丰富的实践经验。Google 在全球范围内运营着多种十亿用户级别的大型服务，我们也会利用由服务产生的数据对服务内容做出逐步改进。由于 Google Cloud Platform 沿用这些服务所使用的相同基础设施，因此 Google Cloud Platform 客户也将享受到同样强大的技术支持方案。
下面，让我们共同了解 BNE 如何与 Google Cloud 合作，共同为《七龙珠：武斗传奇》构建基础设施。
挑战一：极高的可扩展性
日本游戏厂商普遍使用 MySQL，工程师们也习惯了关系数据库中的模式（schema）、SQL查询以及强一致性等要素。这大大简化了应用程序层面的工作，保证技术人员不受数据库限制（例如最终一致性或者架构实施）的影响。事实上，在游戏领域之外，MySQL 在日本同样具有广泛的使用空间，这里的大部分后端工程师都拥有丰富的MySQL实践经验。
MySQL虽然具有诸多优势，但同时也存在一大致命短板：可扩展性差。具体来讲，作为一套纵向扩展数据库，如果要提高MySQL的性能水平，就需要同时添加更多 CPU、RAM以及磁盘资源。另外，当单一MySQL实例无法处理当前负载时，我们需要将负载拆分成多个部分——相当于将用户分成几组，再逐一分配给不同的独立MySQL实例。但是，这种分片操作同样问题多多。大多数游戏开发人员需要在游戏上线之前核算出必要的数据库分片数量，这是因为重新分片会占用大量人力而且极易出错。一旦出错，游戏厂商要么面临数据库过度配置的问题，要么是因玩家数量超出预期而无法提供必要的数据库资源。这就带来了一个现实难题：如果游戏的人气水平与预期相符，那一切都好；但如果游戏大获成功且需求超出预期，又该如何应对？如果活跃用户在游戏发布之初数量可观，但之后逐步下降，又该怎么办？MySQL 分片无法动态扩展，相关调整不仅会带来高昂的维护成本，同时也存在巨大的风险。
在理想条件下，数据库应当能够在无停机前提下灵活实现规模伸缩，同时保持关系数据库的固有优势。因此，在 BNE 方面表示他们正考虑利用 MySQL 分片处理《七龙珠：武斗传奇》的大规模预期流量时，我们提出了自己的建议——Cloud Spanner。
为何选择 Cloud Spanner?
Cloud Spanner 是一项全托管关系数据库服务，可提供横向可伸缩性与可高用性保障，同时实现与 MySQL 架构类似的高一致性水平。更重要的是，作为一项托管服务，Cloud Spanner 由 Google SRE 负责运营，帮助客户摆脱数据库维护负担并最大程度降低停机风险。我们相信，Cloud Spanner 将帮助 BNE 顺利将这款游戏推向全球市场。
预先评估
在采用新技术之前，工程师自然有必要首先进行测试，以确保方案能够在实际情况下提供符合预期的性能表现。在替换 MySQL 之前，BNE 在 Google Cloud Platform 当中创建了一个新的 Cloud Spanner 实例，其中的表模式与 MySQL 用例保持一致。由于 BNE 的后端开发人员使用Scala编程语言，因此选择了 Cloud Spanner 的 Java 客户端库，同时编写了部分示例代码以进行负载测试。通过这种方式，开发人员希望了解 Cloud Spanner 能否满足游戏的每秒写入率（QPS）需求——峰值约为30000 QPS。通过与Google 客户工程师以及Cloud Spanner工程团队的通力合作，BNE 方面轻松完成了测试目标。BNE 方面甚至开发出自己的DML（数据处理语言）打包程序，用于编写 INSERT、UPDATE 以及 DELETE 等 SQL 命令。
游戏发布
有了概念验证作为前提，BNE 方面开始放手实施。根据预期的单日活跃用户（DAU）数量，BNE公司计算出支持全部预注册玩家所需要的 Cloud Spanner 节点。在发布筹备阶段，他们还先后进行了两轮 Beta 封测进行后端验证——数据库全程运作良好！最终，《七龙珠：武斗传奇》的全球预约玩家数量超过300万，但凭借着充分的准备，官方为用户带来了堪称完美的游戏首发体验。
总结而言，在Google Cloud的协助下，BNE公司得以摆脱耗费精力的数据库运营工作，专注于改进游戏本身的设计与体验。
挑战二：全球网络
现在聊聊BNE面对的第二大挑战：构建一款支持全球玩家实时对战（PvP）的游戏。BNE 在《七龙珠：武斗传奇》的设计当中，引入了允许世界各地玩家随时对战的机制。即使不熟悉网络知识，大家也会想到这种设计在延迟控制方面提出的挑战。例如，东京与旧金山之间的往返时间（RTT）均值约为100毫秒。为了解决这个问题，BNE 方面决定将每游戏中的每1秒时长拆分为4个250毫秒的基本单位。换言之，尽管玩家在进行游戏时获得的是实时感受，但游戏本身实际上采取高速回合制设计。有些朋友可能觉得250毫秒的延迟已经提供了充足的余量，但互联网通信并不稳定，实际延迟情况也往往很难预测。
为什么选择云网络？
下图所示，为游戏客户端如何通过互联网访问 Google Cloud Platform 上的游戏服务器由于每一次访问的跳数都可能发生变化，因此玩家的实际 PvP 体验也可能时而顺畅、时而卡顿。
BNE之所以决定选择 Google Cloud Platform 作为《七龙珠：武斗传奇》的后端，一大重要原因在于Google提供的专用网络体系。如下图所示，当游戏客户端访问Google Cloud Platform 分布全球的数百个入网点（POP）时，即可接入 Google 专用网络。如此一来，所有跃点皆在可预测范围内，从而保证延迟处于最低水平。
充分发挥 Google Cloud 网络优势
通常，游戏厂商在实现玩家 PvP 操作时会选择两种方式：其一，建立玩家间直连；其二，通过专用游戏服务器连接。对于战斗延迟要求较为严格的游戏，厂商往往会选择P2P通信方式。但遗憾的是，P2P 只能在两位玩家地理位置相距不远的情况下表现良好，跨区域通信时则效果不佳（某些运营商甚至会直接阻断P2P协议）。如果两位玩家身处不同大洲，那么在通过 Google 专用网络进行通信时，系统会首先尝试通过 P2P 进行直连；如果直连失败，则将其转移至 coturn这一开源 STUN/TURN Server 处，由此作为两个节点的通信中继。如此一来，即使来自不同大洲，玩家也仍可享受到低延迟、高可靠性的 Google 网络。
挑战三：实时数据分析
BNE面对的最后一项挑战，正是实时数据分析。BNE 希望为游戏玩家提供最出色的用户体验，目前的可行方法之一为实时游戏运营，简称 LiveOps。这套方案允许运营人员持续对游戏内容进行变更，从而长期保持新鲜的游戏体验。但要想了解玩家的真实需求，运营团队需要数据——通常是用户的操作日志数据。如果能够以近实时方式获取这些数据，运营团队即可判断应对游戏做出哪些调整，借以快速提高用户的满意度与参与度。
为了收集这类数据，BNE 将Cloud Pub/Sub 与 Cloud Dataflow 结合起来，旨在对用户数据进行实时转换，并将结果插入 BigQuery。
Cloud Pub/Sub 提供面向全球网络的高可靠性消息传递系统，该系统可对日志内容进行缓冲，直到 Cloud Dataflow 接手处理。
Cloud Dataflow 是一项全托管并发处理服务，允许用户以实时、并发方式执行ETL操作。
BigQuery是一套全托管数据仓库，用于存储全部游戏日志。BigQuery 提供PB 级存储能力，因此用户无需担心其扩展空间。凭借着强大的并发处理能力，BNE得以轻松应对高强度日志查询操作并快速获取响应，甚至能够在几秒钟之内完成对TB级别数据的扫描。
这套系统帮助游戏开发商以近实时方式对玩家行为建立起可视化洞察，据此判断应在后续更新或者即时调整中做出哪些修改，从而满足游戏玩家的实际需求。
总结
在Cloud Spanner 的有力支持下，BNE 得以专注于提升游戏品质，而不必将时间与精力耗费在数据库容量规划与扩展身上。
在运营方面，凭借着这套全托管可伸缩数据库，BNE也能够显著降低由人类错误带来的相关风险以及运营的成本。
利用云网络，BNE 通过Google 专用网络为游戏玩家带来最佳用户体验，确保来自不同地区的玩家享受对战的乐趣。
最后，利用 Google 的分析服务组合（Cloud Pub/Sub、Cloud Dataflow 以及 BigQuery），BNE 得以近实时分析玩家行为、快速调整游戏，最终快速改善玩家的游玩体验。
文章信息
相关推荐
