如何设计王者荣耀角色转移服务避免系统崩溃（附服务架构方案）

技术背景

为啥会出现这个需求

按照王者荣耀这款游戏的技术总监的王者荣耀架构分享:‘“开始Android和iOS分开也有一定原因，我们之前设想Android会先更新，iOS后跟进，以保持版本更新的稳定性。”基于前期游戏技术架构的设计以及目前大量用户的安卓与IOS互通的需求，所以产生这次转区服务的需求。整个角色转移服务的开发从2019年下半年开始，到2020年2月第一次灰度部分用户收费19.9元，2020年4月29日开放每天早上十点限量2000个，30日早上限量2000个，晚上8点限量50000个，从对外的时间上来分析整个转区服务的开发周期至少在6个月以上。

#王者荣耀技术架构分享原文
http://www.52im.net/forum.phpmod=viewthread&tid=1595

为了让更多小伙伴能够理解这里简单给大家介绍一下运营、产品、设计、技术、测试分别的岗位职责:
运营：负责产品的拉新、促活、留存、营收。
产品：负责整个产品的生命周期管理，负责设计或整理转换需求方的需求为合适的产品功能。
设计：负责产品以及运营活动的整体视觉设计
技术：负责整个产品的技术实现，包括实现技术架构方案，详细处理流程。
测试：上线产品的质量保障，采用各种测试方法保证系统功能的流程符合预期。

角色转移事件回放

角色转移流程：
王者荣耀运营团队，4月22日提前大概一周发布了整个角色转移服务的规则和注意事项，让大家提前做好转区的准备。可见当时看到这个消息的时候还是非常开心的，毕竟期盼已久的角色转移功能终于要上线了。

收到这个消息之后，我想大部分小伙伴都是下载了王者营地，提前清理好要转移的账户的角色数据，坐等正式开始转移。

每天都上线王者营地打卡看看是不是有开放测试的信息，打卡一周之后，4月28日发布了29日上午十点有2000转区名额，然后迫不及待的赶紧充钱坐等十点抢号。

整个抢号流程为下图所示：
1、角色转移服务首页-开始或查看转移情况-（开始转移的按钮，如果当前数量不够，会提示名额不足）

2、手动确认角色转移协议-（手动确认这个地方，经常出现确认半天没有反应，导致用户频繁操作，而且前端和后端也没有加限制，导致一个用户多次请求一个服务）

3、检测角色是否符合转移要求（这个地方是最坑爹的地方，我从4月30日晚上8点开始点击这个检测，直到9点40才转移成功，关键当天晚上才开放5万个名额，实在忍不住吐槽，所以才写的这篇文章）

4、检测成功之后，就到了支付页面（都已经到支付页面，居然还有提示被抢光，心里十分诧异）

5、支付成功之后就完成整个流程，可以在首页查询转移记录，是否成功

从上面这5个步骤来看，除了最后一步提示成功，基本上步步都有可能会失败，有可能你前面步骤操作半天，最后到支付告诉你没有名额了！你敢相信，这样的产品体验实在太多问题，下面先总结一下这次官方活动的情况：

总结：

从运营的角度来看，这次活动还是做的比较不错的。可以从以下几点看：

（1）很多人之前可能都不是王者营地的用户，通过这次角色转移会给自己的这款产品增加流量。

（2）提前一个星期公布角色转移信息，一方面可以提前为转移服务清理角色数据，另一方面提前告诉要收费99元，看看大家对这个事情的评论和看法，还可以增加大家这段时间的粘性，每天来打卡看后续消息。

（3）根据活动的热度，逐渐开放转移名额，可以弥补前期没有抢到人的失落，增加活动的留存和收益。

从产品、技术与测试角度来看，这次活动的问题还是非常大的，可以从以下几点来分析：

（1）流程设计不合理：第一步检测名额通过之后，为什么后续步骤每一步还需要增加这个名额检测，直接在第一步放符合要求的名额进来不就行了。这个锅丢给技术和产品。

（2）没有做限流控制：每天早上十点活动开始的时候，会导致王者营地整个战绩的功能都是异常状态，说明核心功能方没有对这个活动业务方的请求进行限制。另外就是前端没有做限流控制，因为用户点击一直失败，就会重复的一直点击，每一次的这个点击都会请求到后台，导致我在重复检测的时候，居然会提示我转移失败，说我请求太多？！但是你一直显示失败，用户频繁点击这个习惯，作为产品居然不懂？作为前端和技术居然也没有提出这个问题？！这个锅丢给技术。

（3）没有进行压力测试：每天早上十点2000个名额就已经导致核心服务崩溃，每个服务能够支撑的最大QPS，没有进行合理的评估和压力测试。做为秒杀类需求的服务，没有压力测试就上线了，所以才会导致上线角色转移迁移其他服务。这个锅丢给测试。

（4）服务没有自动扩容机制：即使出现瞬时的请求压力，如果有服务自动扩容机制，最多影响服务就几分钟的时间，马上会有新的机器来抗住压力。但是实际感受崩溃几个小时，所以这个锅丢给运维。

下面从我个人的开发经验分析一下，角色转移服务如何设计才比较合理。

角色转移服务架构设计

需求描述：

核心需求：实现跨服角色转移功能，微信区安卓与IOS互转、QQ区安卓与IOS互转。

需求分析：
产品上需求分析，需与产品再次明确几个问题：
1、角色数据转移规则：明确哪些数据可以转移、哪些不可以转移等。
2、角色转移规则：满足什么条件可以转移，是否可以多次转移。
3、数据唯一性处理方案：用户UID冲突、用户昵称冲突等。

技术上分析业务场景：
1、读多写少，增加缓存，尽量将所有请求拦截在前端，只放符合要求的请求到后面流程。这里量大的请求主要为检测账户是否可转移，因为检测会涉及多个服务，并且不一定有缓存，查询基本都会击穿到数据库。对于这个情况，有下列两种方式解决：

（1）在第一步控制可以进入到检测的用户名额，比如2000名就限制只有2000人可以进入这个流程（redis控制数量），然后支付成功之后，再创建角色转移任务（实际扣掉名额，到期未支付会返还名额），后续步骤不再检测是否还有名额这个逻辑。

（2）采用纯异步方式，比如转移名额2000人，可以释放4000人进行排队，每个用户一个排队号，按照顺序离线检测用户是否符合要求，符合要求的提醒用户进行支付，按实际支付状态计算名额，转满2000人为止，名额满了就提示用户转移失败，名额已满。

第一种方案是王者营地团队使用的办法类似，但是他们没有限制好进入第二步的人数，所以导致后面的步骤依然会出现名额不足，检测异常等问题。这里我也采用第一种方案来解决这个问题。

2、角色转移涉及到第三方服务比较多，其中可能会涉及到部分数据转移出现遗漏或者异常的情况。对于这种情况，可以以角色转移主服务作为管理流程，负责整个转移服务的生命周期，并且提供一个回调接口，方便第三方服务帮角色转移情况回写到主服务这边，便于后期可以统一查询。

3、安全以及防刷问题，需要增加防刷防跳机制，防止异常请求频繁请求服务，防止用户前面步骤没有执行完则直接刷后续操作。

4、如何应对流量剧增对服务造成影响，增加限流模块与熔断保护机制，具体方案之前文章已经介绍

5、对于动态扩容可以是用k8s+docker搭建部署服务，如果运维没有这套环境只能用原始的办法，提前增加机器节点数量。

6、角色转移作为一个独立的秒杀类服务，后期可能会作为一个长期使用的功能，所以建议单独项目来开发这个功能，并使用单独的机器与数据库、缓存资源，避免对线上其他服务造成影响。

7、为了防止系统在中间的步骤出现异常，每执行一步都会发送操作日志信息，然后可以写个任务定时处理操作日志，检测多个环节的数据是否一致。如果有迁移步骤异常的角色，可以自动补全操作，也可以人工补全操作。

8、服务上线之前，必须经过压力测试，压测系统能抗住的最大QPS，并根据压测的值，通过限流模块，限制前端的请求。

9、前端需要防止用户频繁点击，可以增加点击计时功能，10秒或者20秒后才能进行再次请求。后端也可以根据请求参数作为key，在redis种一个值，防止相同请求频繁操作。
根据上述明确的规则，设计角色转移服务整体的技术架构：

其中服务层的角色转移主服务为主要的功能，包括整个角色转移的流程控制、角色校验、支付、转移任务生成与查询等。下图为角色转移整个操作流程图：

总结：

整个系统基本没有数据一致性的问题，并发高的情况只有第一个步骤入口处，控制好进入后面步骤的请求，数据迁移逻辑为异步实现，基本不会出现并发问题。
核心的设计思想就是尽量帮无效请求拦截在前端，上线前必须压测，保证上下游服务都能抗住压力，且保证整个角色转移日志信息的完整性，提供一个角色转移的后台管理系统，可以便于客服及时处理用户反馈。

没有最好的架构，只有最适合的解决方案。另外发上我的战绩图，有需要王者峡谷上分的小伙伴，可以帮忙转发，关注公众号，然后点击联系我，加我微信。哈哈，周末都可以免费带飞呀！