大家好，我是灸哥，今天给大家聊聊我刚看的《不畏移山，手机 QQ 技术架构设计变迁史》一文的感受，同时聊聊我们在什么样的情况下不得不做系统架构升级～

原文链接： 不畏移山，手机QQ技术架构升级变迁史

这篇文章是 QQ 25 周年技术巡礼系列的最终章，主要讲解的是手机 QQ 技术架构升级背后的技术故事。

手机 QQ 应该是陪伴八零后成长的一款产品，已经经过了 20 多年的演进，功能不断加，代码不断加，按照架构演进的历史进程规律，臃肿已是必然。所以文中介绍的这次升级其实是不得不做的一次升级，本文对这次大升级的过程描述较为详尽，从背景、过程、挑战、成果等各方面都进行了详细深入的介绍。

历史包袱和挑战

手机 QQ 从问世以来，二十多年的时间，一直都是即时通讯的标杆，但是任何一款产品，经过这么多年的发展，随着功能的不断增加，原有的技术架构肯定会越来越臃肿，对研发效率和用户体验都带来了极大的风险和影响。那面对这一挑战，手机 QQ 团队不得不“盘”他，于是他们决定启动架构升级的项目，来应对日益增长的业务需求场景。

解耦重构的策略

为了解决历史包袱，手机 QQ 团队采用了分阶段、逐步演进的架构优化策略，先通过业务边界划分、解耦和重构，然后让新架构的模块更加内聚，接口更加清晰，显著地提升了研发的效率和产品的质量。

手机 QQ 的原有架构：、

可以看出的问题有三：

1. 基础代码和业务代码边界模糊

2. 基础核心类持续膨胀，业务之间代码依赖越来越不合理

3. 研发效率低下

针对原有架构的问题分析，开始设计新架构，主要采取的策略：

1. 按照业务划分模块，业务模块之间相互解耦，通过接口和路由进行通信

2. 按照层级设计划分，层级自上而下依赖，严格控制依赖传递

从架构图中是可以看出，在新架构中，模块更加内聚，接口更加清晰，依赖数量减少，可测试性得到很大的提升。

解耦重构的过程包括了三个阶段，每个阶段都设定了明确的目标，并取得了显著的成果。

阶段一：2020 年 11 月 - 2021 年 02 月

这一阶段完成 300W 行核心代码、30 个基础模块、40 个基础组件的完全解耦。

阶段二：2021 年 03 月 - 2021 年 06 月

本阶段是继续为业务模块解耦，建设防劣化机制。

这一阶段主要完成了防劣化机制和动态化能力的搭建

阶段三：2021 年 07 月以后

本阶段是为了进一步完善基础模块和组件化，实现子工程化。

这一阶段主要完成基础模块和公共组建的重构并建立了基础模块发布组件的流程，同时对频道、小世界等业务进行子工程化改造，可以独立编译运行。

三个阶段之后的成果如下图：

而文中关于 NT 架构升级的内容，本文就不多做总结了。各位可自行查阅原文～

手机 QQ 的架构升级是一个持续的过程，它不仅提升了产品的技术实力，也为未来的技术创新奠定了基础。展望未来，QQ 将继续在 NT 架构的基础上，为用户提供更加流畅稳定的产品体验。

本次手机 QQ 的架构升级，是对他们团队来说是一次充满挑战的技术革新之旅，通过团队和智慧，手机 QQ 成功实现了摆脱技术债务，可以更加高效和稳定。

那我们在本文末尾来回答一个问题：

什么时候要对原有系统架构进行重构升级？

01 性能瓶颈

当现有架构无法满足性能要求，比如在处理速度、响应时间、并发用户数等。

02 可维护性差

随着系统的生存时间越来越长，时间的推移，功能的增加，代码的增加，尤其是“烂”代码，这时候的系统就会变得难以维护，代码质量直线下降，开始出现大量的技术债务，随之的后果就是开发和维护成本快速增加。

03 扩展性差

当原有架构已经不能灵活地适应新功能的开发，或者在添加新功能的时候需要大量的额外工作，严重影响了产品的迭代速度。

04 可靠性差

当原有架构下，你的系统开始经常出现稳定性和可靠性的问题，比如频繁的系统崩溃、数据丢失等，用户体验急剧下降，企业口碑受损。

05 技术落后

当原有架构所使用的技术框架、技术工具已经过时时，已经无法很好地支持最新的技术标准和实践，导致安全风险增加、性能下降以及各种莫名其妙的兼容性问题。

06 业务发展需求

随着业务的变化扩展以及市场的变化动荡，原有架构已经无法支持新的业务模式或者市场需求，这时候就必须需要通过重构来改进了。

推荐阅读

1. 让DDD（领域驱动设计）与微服务双剑合璧助你掌握现代软件架构设计的精髓
2. 一文掌握常用架构设计模式｜探索架构之旅：MVC、CQRS、六边形、洋葱、DDD 、COLA 等
3. 微服务治理之道：从架构、研发、测试、运维、管理、业务全方位治理助力企业数字化转型
4. 微服务治理之道：从架构、研发、测试、运维、管理、业务全方位治理助力企业数字化转型
5. 走进微服务架构｜微服务的架构演变、核心特征以及与单体架构的对比分析