注：本文原创，转载请标明出处。欢迎转发、关注微信公众号：Q的博客。不定期发送干货，实践经验、系统总结、源码解读、技术原理。
本文目的
笔者在一线互联网公司，经历过数次大型系统的重构项目，也多次担任技术负责人，经历的重构项目包含：日吞吐量数万亿的计算型系统、基础架构中间件系统、高并发高稳定性要求的C端系统、业务复杂性较高的B端系统等。
同时了解到大型重构项目风险高、难度大、易流产，因此总结了本文供大家参考学习交流。
重构挑战大的4个原因
任何系统在持续的演进迭代的历程中，都难免因各类因素导致迈向重构，比如：系统可塑性与业务需求无法匹配、扩展性无法支撑业务体量的膨胀、技术债务引发研发效率的严重下滑等。
笔者收集了20余个失败的重构案例并深度交流，普遍感受到重构是一个难度很大的事情，总结原因有4个：
1. 重构比从零建设更复杂。
业务兼容、基础设施兼容、在线不影响服务前提下完成架构替换等，挑战性都非常高。
2. 深度！重构需要对系统有全面、深入的认识。
深度是对问题剖析的是否准确，见过有所谓“架构师”绘制几张架构图就开干（个人对架构师这个职位是非常尊重的，身边很多优秀的架构师对系统的认识及演进决策拿捏的非常准确，另外很多项目的流产并不是架构师的责任,但确实不乏一些空谈架构不考虑落地的“架”存在）。
对系统有深刻的认识是重构项目成功落地的必要条件，这里的“认识”包含 (1)困境与根因的因果关系、(2)技术如何支撑复杂的业务场景、(3)多方位的评估等等诸多因素。
3. 广度！重构需要对系统周边情况、业界优秀方案有较好的把握。
对周边系统的了解程度往往能决定项目的下限（能否避免流产）；
对业界方案的把握往往能决定上限。
4. 重构周期较长，不可控因素较多。
重构对技术负责人的综合能力要求是非常高的。因为领导重构并不是一项仅依靠技术能力的工作，同时要求对目标及进度管理、跨团队协作、工程规范等诸多方面也必须能较好把握。
系统性的重构方法
下面是笔者总结的一套较完善的重构流程方法，可以针对大部分场景下的重构项目。包含应遵循的10个准则及各个准则的解释或分析，归纳如下：
1. 问题梳理，原因必根究。
首先明确矛盾与问题，务必确定待解决问题的必要性；
其次清晰的说清楚根因与待解决问题间的逻辑关联；
最后确认覆盖全部问题。
2. 旧系统足够深度了解。
首先完成所有业务（中间件或平台就是能力）的梳理；
其次梳理业务与工程的关联（如业务架构图、数据流转图、数据表关联等）；
最后梳理重构期间需整合的新需求，思考与重构同步落地的计划。
注：如果1、2无法顺利完成，建议停止重构，不论出于人力、新接手或其他原因，重构成功率会非常低。
3. 目标导向、目标可量化。
明确并量化目标，这是方案选型的基础，也是确保演进路径清晰的必要条件。
如果目标无法量化（比如：具备理论无上限的水平扩展能力），应该做到可推导。
4. 业界调研、技术选型。
业界调研尽量覆盖国内外大厂、公司内部的同类产品的情况（比如在不了解某领域业界最优能力是 T 的情况时，目标随意定为 T+，就很不现实。
新业务线从头建设订单系统，可以参考内部成熟业务的相关方案，少走弯路），同时根据系统及团队情况确定选型。
5. 方案设计，充分认识方案的优缺点。
首先，技术术方案多次review，方案多次review，多次review，review
其次，判定重构是否对业务无损，有损需完成影响面评估，并对管理层达成一致；
再次，对新方案的可支撑容量做评估（如有新组件引入等不确定因素，先对组件做压测，确保心中有底而不是贸然拍数据）；
最后是全方位的风险预估（如：第三方依赖可行性及排期评估、人力成本、异常定位成本、兼容性、安全、可用性、可靠性等）。
6. 提前规划系统切换方案。
必须定制小流量方案；稳定性要求高的系统必须可回滚，无法回滚等于飞蛾扑火（笔者职业生涯至今所经历的重构项目，上线完全符合预期且不需优化的情况，都没达到 ...）。
7. 接口定义清晰，方案不过于复杂；测试驱动（视情况选择）。
建议问题暴露周期长的系统使用测试驱动方式；
基于脚本测试的，脚本高度复用可以大幅提效。
8. 方案调整趁早回归。
很多时候调整方案不可避免，早回归整体效率更高。
9. 架构迁移监控先行、日志先行。
重构改动范围大，很难不出BUG，好的监控体系下，系统可以比人更早发现问题，风险也更加可控；
新架构发布时，日志往往是定位问题最便捷的工具。
10. 上线后再次做容量、扩展性等多方面预估。
可能（或者说经常）发现做方案时的评估并不准确，可靠的数据对后续工程迭代及业务发展是至关重要的。
1个月后后头做这个事情，效率大概率骤降！
总结简化为一个图，方便保存复习
欢迎转发、关注微信公众号：Q的博客，不定期发送干货，实践经验、系统总结、源码解读、技术原理。
