金科技术总监夏祥龙：​游戏发行系统的技术架构体系

【GameLook专稿，未经授权不得转载】

GameLook报道/6月16日，2022亚马逊云科技游戏开发者大会盛大开幕，此次大会以“科技成就伟大游戏”为主题，从构建、运行和增长的全游戏生命周期，向行业展现云科技力。

在大会的“Run 运行”分论坛上，广州金科文化科技有限公司技术总监夏祥龙以《游戏发行架构体系演进与实践》进行了精彩的分享。

以下是演讲实录：

夏祥龙：大家好！感谢主办方亚马逊科技的邀请，很高兴能在这里分享我们在游戏发行中的一些设计思想和思考。我是广州金科文化的技术总监夏祥龙，今天分享的主题是“游戏发行架构体系的演进与实践”。

首先介绍一下我们公司的业务背景，金科文化是金科汤姆猫旗下的全资子公司，集团是以“会说话的汤姆猫”为核心的全栖IP运营商，范围涵盖了线上线下、娱乐教育、衍生品授权以及乐园专卖店等等。

“会说话的汤姆猫”家族App全球累计下载量已经超过180亿次，月活跃用户最高达到4.7亿次，日活跃用户为4209万人次。同时，《会说话的汤姆猫》系列动画片在全球各大视频网站上都有播放，观看量达到880亿次，业务涵盖了欧盟、美国、中国、俄罗斯、巴西、印度等全球大部分的国家与地区。

广州金科成立于2017年，公司刚开始做发行业务的时候是以“会说话的汤姆猫”单机游戏起步，发展过程中实现了从单机到网络游戏，从国内到海外发行，业务类型包含了游戏联运、游戏投放等，其实和大多数的游戏公司均有一定的重合度，接下来我主要分享一下各个系统的设计内容。

游戏发行系统一般都会涉及到一个问题，这个系统应该发展成什么模样？它应该具备哪些系统？从最基础的需求出发，大致有四个需求。

第一个是能打包，第二个则是能够完成用户登录，第三个是支付，第四个是能够满足运营与研发能够日常看数据的需求。

针对不同需求，拥有着不同的业务难点，我们简单总结了一下。首先打包系统占用人力比较多，因为在刚开始大部分都是技术人员手动去，所以在整个过程中占用了比较大的人力。第二个便是调试的成本比较高，这里面涉及到研发、渠道、游戏发行的中台这三方的调试。第三个是配置多，从游戏基础的图标到游戏的开屏时间以及广告、支付等各项配置其实是比较多的，而且这也带来了一个问题，那就是比较容易出错，并且一旦出错整个业务线都要跟着去做跟踪与定位。

第二个则是用户系统，这个系统显著的特点就是高并发，在闲时和用户高峰期有几倍到几十倍的差距，在国内、国外不同地区的网络都有不同的情况，还会经常出现网络拥堵。对于游戏研发商而言，它还要匹配每个渠道的登录模式与登录流程，如果都去对接的话成本也是非常高的。

第三个是支付系统，支付系统也有各种模式，比如直接支付、游戏币代付还有固定档位的支付等，还要具备多个通道。支付系统另外日常会遇到的两个比较重要的问题一个是一致性的校验，另一个是掉单处理，其中一致性校验对应的是我们经常会遇到的刷单问题，这个问题解决不了对于游戏就是巨大的经济损失。另外一个掉单问题，我们在处理订单与通知发货的过程中，如果没有即时发货那就会遭到用户投诉，直接会牵扯到客服、运营、游戏研发等多方面的人，都要去配合做这方面的工作，消耗是比较大的。

最后一个是数据分析，最常见的要具备运营过程中需要分析的日常数据，这个系统和用户系统是比较相似的，因为是根据用户量配合得到的数据并发、大数据量，无论数据有着怎样的体量都需要拥有一定的查询速度，如果查询太慢这个过程中就会涉及到服务器的架构，比如成本如何进行平衡，这既是性能匹配的问题。

接下来，我们挨个看一下相关系统的设计与业务流程。

首先是打包系统，它的架构和常规系统有一点不同，从S3存储Akp包到经过我们部署在服务器上的Jinkens打包，最后所有业务的经过我们的EC2 WebServer进行处理，经过打包后最终进入到PostgreSql。

这里面为什么会有Jinkens On Cloud Server与On Native Server，是因为我们在处理业务的时候，每一个包体在出包的时候大小是不一样的，比如单机游戏的大小可能是几十到几百兆不等，但一些大的网络游戏动辄就是上G的文件体量，在内网传输的时候大家一般都是千兆起步，所以上传到服务器相对是很快的，十几秒就可以搞定了，但在外网的时候，上传速度就会严重影响打包的过程。

所以正常情况下，我们所有的包体比如自研游戏与已经给到包体的游戏都是从内网进行传输，但也避免不了研发需要进一步尝试，这个时候我们就需要具备外网系统，虽然外网传输速度慢一点，但也能把业务交给CP方进行出包。

打包系统的核心流程大概就是像下图这样，以安卓为例，首先游戏出aar文件，当这个文件进入到系统后就会进行基础的配置包括是否有开屏、闪屏、闪屏的时间是多少秒，对应出包之后的icon是怎样的，角标是放在哪个角上等等。

如果是初次出包，那我们就要选择刚才说到的，是否有广告、广告是用的哪一家、是否要跟踪投放数据、投放用了哪些组件，这些组件是否需要配置。如果说已经出过包，上一次出包的时候我们就已经记住了所有的配置，只需点击确认进入到我们的打包系统出Akp或Aab包即可，出包后就会进入到我们的S3系统。这个系统是组件化设计，按照需要进行选择，所有的参数都是根据后台的配置进行选择以及可视化的调整，对应的打包信息都是存储在云端，避免后续要找包验证的时候找不到。

这里面，我们在打包系统常常会遇到的问题是出错后调试成本非常高，那要如何去调整？一般情况，出错都是参数配置错误，比如用户的多个参数没有配对，那可能出错后，从游戏研发到中台、渠道的后台各个方面都要去检查。

而在这个架构中，当你需要某个系统时，对应的渠道参数就会去检查，这个参数登录情况是否有配置，没有配置肯定会提供相关的报错。如果打了投放相关的组件如头条抖音等等，那在后台没有配置相关的数据也会直接告诉你哪个地方缺少了配置，对应的运营、相关人员等提前处理掉，避免出包之后才发现这个地方有问题，再去找相关的人去查，减少了工作量。

从这个技术配置、广告配置还有系统组件这几个方面相关的配置，都是由我们的测试来进行，解放了研发、技术人员的投入，整个过程可能都不需要技术人员的参与，这样也能够减少人力成本。

接下来我们来看一下用户系统，它的基础架构相对是比较简单的，首先是前端使用CloudFront进行动态加速，然后所有的数据请求都是通过ALB进行数据请求的分发，再然后就来到API Services这样的一个服务，这个服务使用的是目标组合的形式进行动态伸缩，根据用户并发量自行进行调整，并不需要运维介入到这个过程中。一些常见的活跃数据我们都存储到Redis中，整个用户的相关数据则放在了Dynamo DB。

为什么会选用Dynamo DB的模式？因为在用户闲时可能只有几万、几十万，但在高峰期可能可以达到几百万甚至几千万用户的登录量，对于系统的压力是比较大的。而我们前端的数据处理是通过动态伸缩的服务器目标组来进行压力的承接。

在数据库这个层面，如果我们采用传统模式，数据库应该是抗不下来的，选择Dynamo DB其实是利用了它的动态伸缩，无论是几十个访问量还是几千个并发量，都可以通过伸缩自己控制，避免了在游戏首发或高峰时段，更多的人力参与进去。目前我们无论是首发还是高峰，基本都不需要运维参与服务器的缩减。

下面是用户系统的登录流程，这里图中的是一个简化版，它核心解决的问题是将游戏和渠道之间的交互切分开来，游戏如果要自己对接第三方渠道成本是相对比较高的，因为每一个渠道对应的接入流程、方式都是不一样的，比如接入oppo、Vivo、华为、小米等等，随便一数都有十几个渠道，挨个对接的话，游戏研发所需要消耗的精力是比较大的。

从这个图中就能看到，用户客户端要求登录就会直接与SDK交互，所有合集交互都有SDK进行屏蔽，只需要发起登录然后告诉它登录的信息是哪一个，对应的信息给到客户端后再和服务器端交互。

聚合SDK这里面涉及到几种对应的模式，第一个是无界面的登录，一般在单机游戏里用的比较多，用户进来后就直接默认登录，然后就可以进行游戏。第二个就是自有的账号体系登录，比如可以用手机号一键登录等这种快速登录的模式。第三个则是和渠道联运时常用的渠道登录模式，使用渠道账号登录。这几个模式里都是由客户端直接调起SDK，SDK直接屏蔽了后续的过程，它去拿自己SDK服务端提供的行为信息，通过调取渠道SDK获取到对应的Open ID，这个Open ID全部由服务器进行存储然后对应的转化成SDK这边的Open ID。游戏这边拿到的登录信息就是，登录之后获取到服务器端的Open ID，然后和服务器进行登录信息的交互，这个的登录过程就是这样的。

支付系统它的基础架构和用户系统是相似的，在并发压力上要小很多，但在一次性校验刷单、掉单等这些东西的要求会更高，因为它涉及到了具体的钱。

我们直接来看一下这个支付流程，这里面涉及到了三方，一个是游戏，第二个是SDK，第三个是渠道，如果是自有支付就直接是游戏与SDK，没有第三方支付。

订单这块我们如何做有效性的校验？首先我们的订单格式这里，游戏拥有游戏的订单号，进行发起支付的时候游戏就会拿订单号找SDK下单，SDK服务器根据游戏的订单号生成匹配的SDK订单号，然后再用这个生成之后的订单号到渠道这里下单，这样我们就有三个订单号关联起来了：游戏对应的订单号、SDK的订单号以及渠道的订单号。

如果整个订单的下单过程是成功的，那就会直接发起订单支付或自有支付，失败那就是失败，如果成功了那么整个订单号就进入了发货的流程。

一般而言，由渠道的服务器可以推出SDK服务器它的支付通知，然后再由SDK服务器通知到游戏的服务器让它发货。如果是单机游戏，可能就由SDK这边直接进行返回发货通知。

那我们如何解决用户刷单的问题？游戏的CP方经常会有一个设计说，游戏的订单号是递增的，这样的格式看似没有问题，但在开服时我们常常都会遇到一个问题就是，我们会进行数据清档，清档之后如果前面已经拥有了订单号可能就直接重复了，而对于SDK而言是不允许重复的订单支付的，所以我们在这个过程中直接定好了游戏中的相关订单格式，有游戏的标识、区服的表示，此外为了避免订单号递增我们还加上了时间戳，然后还加上了商品id。

这样订单格式就直接把关键信息都包含在里面，如果用户在订单中无论是修改了金额，还是修改了金额对应的商品情况，我们都可以通过订单号来进行校验，只需要是这个订单号，那么对应的格式就可以通过这个订单号校验，不需要通过其他的格式，如果更改了订单号，那么这个订单肯定是找不到的，就是一个无效订单。如果没改订单号，那么这当中的商品、金额都可以在校验中，无论是SDK校验还是服务端校验都是可以检查出来的。

接下来就是我们的数据分析系统，这块其实是把我们大部分的架构都囊括进来了，前端是以动态加速来进行数据的转换，所有数据都要进入ALB负载均衡和数据的转换，如果是用户系统的数据就会进入到API Services，相关的数据统计全部通过事件的形式进入Kinesis Data Streams，然后通过Firehose落地到S3。而用户的缓冲数据则是在Redis、用户、支付相关的数据等全部进入到Dynamo DB。

在进行数据的查询过程中，尤其通过IDS数据库进行查询，另外一个就是存储到S3上的文件，通过Presto进行数据计算，计算的结果需要存储则进入S3，需要进入数据库则进入IDS数据库。

早期时候我们并没有用Presto，因为在2018年我们这块还没有上线，当时我们用的是麒麟那套开源框架，那个框架其实也是比较好用的，但我们在使用过程中维护的成本比较高，当时要占用1到1.5个人力去维护这样一套框架。而当Presto上线后，经过我们的测试无论是启动还是运维角度，它的稳定性是远远高于我们自己去维护的计算架构，所以我们就替换到了Presto。这里在进行大量数据计算的时候，其实是可以使用我们的竞价模式，如果使用的好是可以把整体的费用降低到五分之一至十分之一。

接下来扩展介绍一下，从2019年便出现很多政策合规问题，我们原本的用户系统并不能满足业务发展的需要，这里以防沉迷系统举例，我们在用户系统上做出的拓展。

因为我们只是简单要登录，但在防沉迷系统上，国家的要求是在登录后要实名，那么用户就要进入到实名系统中。首先用户登录，登录的请求通过ALB到达用户认证服务，这里就直接调用存取实名信息的接口，这是实名这块的拓展。

还有一个是要求我们申报上下线的行为，这个如何去处理？我们在发行的时候一般是有两类的游戏，一类是单机类的，另一类则是网游类的。其中网游类的比较简单，因为服务端一般都会轮询用户的状态，它会知道用户什么时候上下线，可以直接上报到国家上下线的接口中。但如果是单机游戏就没有那么准确，那我们是接入到我们自己研发的心跳服务这样一个系统，客户端进行心跳申报进入到心跳服务器，数据则进入到心跳缓存中，如果用户超过了几个心跳周期没有进行申报那么我们就认定他已经下线了，再申报到上下线系统中。

除了前面几个基础的需求系统加上一些合规系统外，在游戏研发中我们拥有一个更加严谨的诉求就是，这套系统在设计的时候到底是好是坏，是否符合我的预期，这些系统该上还是不该上，实际上很多时候都是大家拍脑袋决定要不要上，有的时候这个系统其实并不理智，我们有这样一个A/Btest系统用于日常工作里，由数据驱动来代替经验驱动。

这个A/Btest系统的核心一点便是给用户打上标签，比如这个用户是新用户还是老用户，是活跃用户还是非活跃用户，是付费用户还是非付费用户，如果是付费用户的话，那他是高价值付费用户还是低价值付费用户等相关的标签，我们都可以给用户打上。

打上了之后对于我们的研发而言，我们需要确定这个按钮的颜色是用红色好还是绿色好，不需要大家进行讨论与辩论，直接进入到A/Btest系统中导入一部分目标用户进来后，去看到底哪一个更能触发用户的点击欲望。

如果我们要新上一个系统，先要明确整个系统的目标是怎样的，比如增加付费还是增加广告点击，也是通过A/Btest系统的验证，它的核心是由我们的客户端请求实验的ID，如果这个实验处于开启状态，而且相关的流量还没有关闭的情况下，那么整个数据就会进行分析，分析完成之后就把相关的流入数据与流出数据按照我们设计好的试验方案进行分析，不同维度进行分析完成后再来具体选择方案，如果方案符合预期，那我们就把整个系统进行发布。

完成之后所有的后来用户除了之前讲到的控制流量用户外，后面所有的用户都会进入到同样的业务环境中，这样就完成了一个版本发布的过程。A/Btest系统对于我们业务研发其实是一个比较好方式，希望大家可以尝试一下。

因为时间关系，我们就介绍前面这几个系统，实际上我们的产品体系是和整个图片中展示的一样，首先是我们的A/Btest系统，然后是GM系统，这个是为了我们游戏后台服务的，比如它可以根据游戏配置相关的礼包码，此外在GM系统里对接完后还可以定时定点的对多服游戏开服，还有对游戏内各种控制。

每个游戏其实都会有一些用户的反馈问题，那我们就集成了一个客服系统，通过SDK将信息汇总到对应的后台，游戏运营人员可以在客服系统里和玩家进行交互。

投放系统则是在打包与用户系统之上，把投放相关的各种数据汇总到一起，还会涉及到投放的一些创作素材，和我们的投放业务串成一条线。

接下来防沉迷系统刚刚讲过了，此外还有隐私合规系统，这里面要配置好对应的渠道、不同的隐私协议，如果隐私更新我们如何记录下来，如果用户不同意如何让他采用我们新版的用户协议等。

配置中心则是为我们技术人员准备的，如果在每个系统里进行配置与维护成本是相对较高的。配置中心则是将每个系统需要的、可能会修改的但修改频率很高的这种数据汇总到配置中心，由它统一管理。

报表系统，除了日常的报表外，在我们业务发展过程中还会涉及到，不同的项目组、不同的研发对于报表的需求是不一样的，但很多时候都是那些常见字段进行的不同拼凑，所以我们就开发了这一套自定义的报表系统，将我们后台能够统计到的各种数据进行灵活的整合，运营或研发需要指定格式报表的时候，大多数情况我们都可以直接通过报表系统制作一张。

行业信息主要则是游戏发行时，会考虑具体在哪一天上线，有的时候需要避开一些大IP等，行业信息则主要用来搜集各个渠道上不同游戏的上线时间以及一些相关的信息，比如用户评论等，辅助我们商业部门与运营部门进行规划。

最后一个是财务系统，它主要是用来对账的，比如对账单、计算单等等，让我们其他系统有机的连在一起，这样在我们年终审计的时候，提升我们的效率。

今天我的分享内容就是这些，感谢大家的聆听！