1 背景
1.1 起始之由
1.2 重构前现状
1.3 问题分析
2 重构
2.1 目标
2.2 制定方案
2.3 部分细节设计
3 总结
1 背景
游戏业务自 2017 年启航，至今已近乎走过七个春秋，历经漫长岁月的发展，不知不觉间背负起沉重的历史包袱。犹如一棵大树，既有繁茂精壮的枝桠，亦有诸多枯败凋零的枝叶。此文主要聚焦于商品更新 MQ 消费这一细微模块，详述游戏业务如何对原有代码予以重构，令游戏这棵大树重焕蓬勃生机。
1.1 起始之由
一日，骤然收到线上对下游接口 RPC 调用限流之警报，限流警报阈值为600k/min。遂着手排查触发限流警报之因由。追根溯源，发觉乃外部存有更新操作，而更新接口调用阈值大约3K/min。明明更新流量不高，缘何触发限流？于是开启了对系统的调研与排查。
1.2 重构前现状
经过对限流原因的初步探索，我们进一步对商品消费 MQ 进行了全面梳理，发现游戏已有19个订阅商品更新 MQ 的 Consumer，分布在不同集群。这些 Consumer 各自存有内部的查询与更新相关操作，因其部分更新操作会催生新的 Message，致使接口调用进一步扩增。
调研还发现有的废弃 Consumer 还在线上持续消费，有的相同的消费逻辑被多个 Consumer 在消费。
针对上面问题简单梳理总结，问题如下：
a. 逻辑分散，可维护性差
b. 服务调用量成倍放大
c. 存在并发更新和覆盖的情况
d. 存在废弃或者重复消费情况
1.3 问题分析
为什么会形成这样的现状？
作者认为：前期需求快速迭代，新增新的 Consumer 可迅速响应需求，且开发便捷。然而，伴随需求的演变与迭代，新增的 Consumer 渐多，需求与人员的变更，使得系统全貌愈发难以全面掌控。不断变更的逻辑，致使整个系统的维护愈发艰难，从而衍生出形形色色的问题。
若要降低 MQ 相关接口调用量，有两个核心要点：其一，减少查询，实现数据复用；其二，减少更新接口调用，抑制新的 Message 产生。但当下系统已然如此分散，于现有结构上极难获取出色的解决方案。欲改变当前此种状况，需要全新的结构，对原有 MQ 消费逻辑进行重构。借由新的结构，不但能够化解当下的问题，还能够构建新的约束，引导未来新的功能撰写方式，使整个系统更为健康稳定。
2 重构
2.1 目标
在着手重构之前，最为关键的是明晰目标。目标能够辅助我们拟定方案，明确范围，指引项目落地而不偏离正轨。
a. 合理的结构
b. 优化重复无效消费逻辑
c. 提高消费能力
d. 逻辑优化
e. 构建新体系
期望通过合理的代码架构，令消费商品 MQ 消息的逻辑高度内聚且低耦合、各个类及方法的职责清晰明确。重构并非对老系统的简单复制，更肩负着为系统未来扩展定义新的约束规范。恰似于这棵游戏大树中萌生出新的枝干与分支，决定着后续细枝的生长方向。
除了架构合理，还需优化解决此前的重复和无效消费的情况，提升整体消费能力，解决原先接口调用放大的问题。此外，在调研中发现系统存在一些已下线的废弃逻辑和部分有问题的代码，趁此次重构之机予以优化。（注：通常不建议在重构中修改逻辑，对于修改逻辑务必要进行充分测试，否则可能引入新的系统 Bug）
2.2 制定方案
重构的总体方案主要由三部分构成：架构设计、实施计划、测试计划。
2.2.1 架构设计
总体架构主要运用享元设计模式和策略设计模式，整个架构自上而下由三部分组成。
a. 数据预处理
b. 按分类调用Handler进行消费
c. 收拢调用更新接口
a：数据预处理主要负责过滤和预查询数据。包含批量消费 MQ 消息，滤除非游戏的消息，调用批查询接口，预处理后续可能重复处理的逻辑，减少重复查询，提升接口效率。
b：主要是按分类抽取 Handler 和公共 Handler，以使职责清晰分明。抽取公共 Handler 以处理一些公共逻辑，例如记录埋点日志等。各个分类的 Handler 仅处理本分类的业务逻辑，实现逻辑解耦，提升可维护性。为方便切面的使用以及增强相关功能的内聚性，在 Handler 之下额外抽取了一层 Manage 层。Manage 层主要负责实现具体的消费逻辑，并提供可复用组件，令逻辑更具内聚性。
c：对中台商品相关的更新逻辑予以收拢，其主要目的在于减少更新接口的调用。（由于这些更新会产生新的 Message，故而通过调用批量接口的方式，来降低更新接口的调用次数，进而有效解决接口调用频率放大的问题）
2.2.2 实施计划
我们将整个重构划分为以下三期来实现。
第一期：主要针对非核心业务 MQ 逻辑进行迁移重构。非核心业务灰度上线，控制影响范围，迅速验证架构的可行性与稳定性。
第二期：核心业务相关 MQ 迁移重构。灰度上线，关注对核心业务的影响。完成此步基本完成全部业务逻辑迁移。
第三期：对结构进行微调，主要是对相关功能进一步拆解、重构，使功能内部更为内聚，降低耦合，令整个系统最终达成设计之初的预期效果。
分多步进行重构的益处主要在于控制影响范围，能够迅速见到成效。每次改动范围有限，更易于定位问题，也能够极为便利地支持产品需求。
2.2.3 测试计划
每次上线之前，核心主要通过三种测试，即白盒测试、黑盒测试、日志对比。
a：黑盒测试，校验新老流程处理后的数据是否一致。
b：白盒测试。测试每一行代码的覆盖率，并观察新老流程数据是否一致。
c：调用接口前数据对比。在调用更新接口之处打印日志，对比新老流程调用更新接口的传参是否一致。
测试仅是一方面，上线后皆需关注整个系统的运行状况，并做好关键方面的报警。此外，会同步一线客服人员，收集是否存在用户反馈的问题，依照原来Consumer的颗粒度进行灰度。
2.3 部分细节设计
统一幂等灰度切面处理
此系统乃是一个与 MQ 消费相关的重构项目，在每个消费模块皆需确保消费的幂等性，然而迁移而来的 Consumer 众多，若在每个地方皆书写一遍幂等相关处理，极为不便。我主要借助了 Spring 的 AOP 能力来达成。
主要是定义规范，定义幂等注解、统一返回值（泛型）以及撰写注解处理类。通过环绕注解来实现，处理类在处理之前会进行规范检测，不规范则直接放过（相当于使用注解失效），消费成功后我们会将返回结果通过缓存存储起来，下次再来时，直接消费成功，无需重复处理，达成处理幂等性和减少重复消费的情况。幂等缓存的颗粒度为msgId。（灰度控制方案原理相同，此处不再赘述）
异常失败应对
我们在设计下游商品更新时进行了收拢处理，以方便操作，但也带来一个问题，即可能我们的业务信息已更新，而下游可能处理失败，对此我们使用转转封装的基于 RocketMQ 的消费重试组件来实现。（简单来讲，同步消费失败，就会利用 RocketMQ，创建一个MQ消费信息来异步处理）。未更新成功的数据，通过 MQ 重试来保障消费成功。
我们还设有报警机制，未更新商品的信息，通过企业微信发送报警，以提示技术人员，并提供商品数据信息，方便在出现特殊异常情况时，人工兜底补足来处理此类情形。
数据隔离
新的Consumer在消费时提供了单独的线程池处理，便于监控逻辑处理消费情况，提升整体逻辑处理能力的并发度。
数据监控
建立丰富的监控指标和报警通知机制。通过日志查询平台、数据看板、异常企业微信报警通知，辅助我们在上线后实时观察新流程的具体状况，迅速定位问题。
3 总结
数据效果
项目上线后，下游核心接口的调用量显著降低，降幅 50%至80% 之间。其中，更新类接口的调用量降低了 80%，查询类接口的调用量减少了 50%。
思考与总结
明确系统重构的缘由，主要涵盖两方面。（现有系统存在问题需解决，或者现有系统限制了新的业务发展） 务必要充分了解自身的系统。在重构之前，对于具体的业务逻辑和影响范围等信息需进行直接评估与确定。唯有明晰系统的原貌，方能依据系统的现状设计全新的技术方案。 考虑未来发展，定义好的规范。好的规范和结构，在未来系统迭代发展起一个引导作用。引导大家按相同的思路开发，更好的协作和支持业务需求。
关于作者
许志芳，转转订单业务后端研发工程师
想了解更多转转公司的业务实践，欢迎点击关注下方公众号：
