转转游戏MQ重构：思考与心得之旅

见贤思齐

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在消费时提供了单独的线程池处理，便于监控逻辑处理消费情况，提升整体逻辑处理能力的并发度。线程池监控数据监控建立丰富的监控指标和报警通知机制。通过日志查询平台、数据看板、异常企业微信报警通知，辅助我们在上线后实时观察新流程的具体状况，迅速定位问题。MQ生成消费监控上游查询失败报警3 总结数据效果项目上线后，下游核心接口的调用量显著降低，降幅50%至80%之间。其中，更新类接口的调用量降低了80%，查询类接口的调用量减少了50%。思考与总结明确系统重构的缘由，主要涵盖两方面。（现有系统存在问题需解决，或者现有系统限制了新的业务发展）务必要充分了解自身的系统。在重构之前，对于具体的业务逻辑和影响范围等信息需进行直接评估与确定。唯有明晰系统的原貌，方能依据系统的现状设计全新的技术方案。考虑未来发展，定义好的规范。好的规范和结构，在未来系统迭代发展起一个引导作用。引导大家按相同的思路开发，更好的协作和支持业务需求。