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