原地址：https://www.cnblogs.com/fundebug/p/10734209.html
前言
随着公司业务的爆炸式的增长，需求规模和用户规模也迅速地膨胀起来，这样给系统的三高(高性能、高并发、高可用)以及扩展性、可维护性都带来了考验。而旧系统因为早期设计的各种局限性（如早期参与人员的水平、架构设计的前瞻性、老板的急性子等等），逐渐满足不了现状和未来的新需求，暴露出各种问题。开发人员们像是拖着老破车上高速，苦不堪言。（说人话：老系统代码的坑太深了，开发们填不住了，要么被坑埋了，要么弃坑逃跑了…）
那么这个时候，通常要面临一个问题：是继续填坑还是跑路走人 选择重构。填坑是不可能的，这辈子都不可能的。而选择重构是需要壮士断腕的勇气，因为重构是一项老大难、一件耗时耗力的事情，且多少会对现有业务开发造成影响，甚至是停滞。因此大多时候得不到产品经理和老板的支持，他们关心的只有一个：下个需求什么时候能上！至于其他的，都是你们研发该操心的。
自己选择的重构路，跪着也要走完。如何来一次就干就干的重构呢？根据互联网常见项目重构流程，以及我的亲身参与的重构项目经历，梳理大中小型系统的常见重构流程如下：
零：说服业务方
重构不单是研发团队的事情，更是整个项目团队的事情。重构可以提升系统的三高，也可以优化改善业务流程，满足新的业务诉求等等。重构需要投入大量资源，必须要得到业务方的支持。通常这个时候需要对他们晓之以理，动之以情，阐述清楚重构的利弊，以及不重构的要害。在得到他们的支持后，重构的工作便正式开展。
参与人员：技术 Leader
一：树立重构目标，有的放矢
重构是一项工程，是一场持久战，它不是一两个迭代、甚至一两个月能做好的事情，需要投入大量的人力、物力、时间精力等。那么在这场旷日持久的战斗中，我们的目标是什么？是通过更优秀更合理的架构来满足系统三高的需求，还是想通过重构来提高代码质量，或者引入新的技术和框架来升级整个系统，抑或通过重构来优化业务流程，实现原来实现不了的需求。有了目标后，才能做到有的放矢。
参与人员：技术 Leader，架构师
二：确定重构的范围，并对重构作出预测
重构通常有以下几个级别的重构
平台级别重构。针对整体平台的重构，如阿里早期是 LAMP 架构，后来整体迁移到了 Java 平台。
系统级别重构。针对业务系统的重构，如通过引入微服务架构或者 SOA 架构，分解单体应用。
架构级别重构。如通过架构的调整和重新设计，改善原有架构的不合理之处。如通过分层使业务解耦，引入缓存设计提升系统高并发等。
业务级别重构。常见为某些业务需求因为系统设计的不合理性导致无法满足或有缺陷满足，需要通过业务系统的重构调整或数据库的重构来解决。
模块/代码级别重构。这是最常见的重构。通常指使用设计模式、封装继承、优化拆解代码，使得代码的结构更良好，运行效率更高。
确定这次重构是属于什么级别，确定重构的整体范围的大小，确定重构的技术选型，进而对重构工作进行科学的评测和预估。比如需要投入哪些成本，需要投入的人力和时间是多少，在重构的过程中能否支撑正常业务需求等等。在有了这些预测后，也对业务方有个交代，尤其是当他们追在后面问什么时候能上新需求。
参与人员：技术 Leader，架构师，研发人员
三：旧系统的熟悉和业务梳理
重构不是和旧系统说散就散，而是要不断和旧系统战斗的过程。知己知彼，百战不殆。重构不仅需要清楚新系统的目标和未来，更需要对旧系统非常熟悉(尤其是坑)。此时需要参与重构的人员(尤其是参与旧系统的人员)来对旧系统业务和系统进行梳理，对原有资料信息进行收益和整理的工作，对旧系统的关键代码和数据库设计进行 Review 等等。
以下是重构旧系统前需要准备的常见工作：
旧系统资料和信息的收集，包含且不限于系统相关的设计文档和技术文档等文档资料，架构图、UML 图，数据库设计 ER 图等图形化资料
业务线和业务流程的梳理，整理业务线上的各大项目、业务流程，并输出为文档
旧系统关键代码的 Review
有相关疑难点及时与相关与业务线上的人员沟通，将问题解决在”襁褓”中。
参与人员：技术 Leader，架构师，研发人员
四：数据库重构
如果在重构中需要涉及数据库的重构，数据库的重构一般是最先开始的一步。系统需要重构的直接原因，也大多和数据库有关。在数据库重构时，我们清楚旧系统中数据库的各种设计缺陷和使用障碍，那么就可以对症下药，如通过三大范式或反范式来设计表，是否需要分库分表等等。
参与人员：DBA，架构师
五：后台系统重构
后台系统重构前，必须需要依照前文所述的一些设计和技术文档。这些文档输出后并经讨论成型后，架构师进行系统架构设计，后台开发人员进行具体编码工作。通常这个过程是耗时最长的，也是非常重要的一环。后台的架构设计水平，决定着系统重构的水平，业务代码的质量，决定着系统重构的质量。
因为这个过程比较漫长，且成果无法立竿见影。所以通常采用敏捷开发的模式，通过迭代的方式来进行后台系统重构。迭代的方式有几个好处：
需要将整个重构过程进行有效规划和量化，做到胸有成竹
每个阶段能有可见的成果，确保团队在长时间的重构过程中不陷于泥潭
对已重构好的部分可以及时进行联调测试或观察，不断在迭代中总结、在总结中迭代
另外在后台系统重构时，也需要有明确量化的目标和标准，比如各系统和业务模块支持多少 QPS，接口响应时间多长时间等，这样团队才能在重构的过程中不至于为了重构而重构。
在重构过程中，定期进行 Code Review，及时发现重构的问题和质量的问题，避免出现破窗效应，引入拙劣的设计或垃圾代码，进而破坏整个系统。
参与人员：技术 Leader，架构师，研发人员
六：数据迁移与检查
如果涉及数据库重构时，在新的数据库设计好后，就会有面临数据迁移的问题。一般分为全量迁移和增量迁移，全量迁移是将旧系统的数据一次性迁移到新的数据库中，增量迁移是在实行全量迁移后旧系统新产生的数据迁移到新系统上来，增量迁移一直到旧系统下线不再产生新数据后。通常迁移都是通过编写脚本或程序来实现，拒绝人工操作。
迁移后自然需要对比新旧系统的数据，同样可以通过脚本或程序来进行对比，查缺补漏，定位分析。
参与人员：DBA，研发人员
七：系统检查、联调与测试
在后台系统重构到一定程度时，同样也需要编写脚本和程序来对新旧系统的业务接口进行检查，及时发现重构中的问题，必要时候进行架构调整和数据库调整。当然，在重构时，开发人员能提高单元测试覆盖率当然是更好不过。当各系统和模块的依赖解决的差不多时，可以开始联调工作。
当然最后还需要系统性的测试，如功能性测试、稳定性测试、性能测试，本地测试、模拟线上环境测试等。测试中发现的问题经验证修复后，达到上线的标准，即可灰度上线。
参与人员：架构师，研发人员，测试人员
八：灰度发布与观察
万里长征已经走到最后，也到了最紧要的关头。灰度发布时，只接入一小部分流量，并及时跟踪和分析线上的 log 与监控告警，一有问题及时解决。当新系统趋于稳定时，可以逐渐加大灰度发布的范围和接入的流量，同时继续跟踪线上 log 与监控告警。
参与人员：运维人员，测试人员，研发人员
九：系统切换
在系统切换时，需要提前制订系统切换方案，包含相应的规划与流程，甚至是应急预案与回滚方案，避免走一步看一步。切换完成后，新系统完全替换旧系统，旧系统下线，完成重构。
参与人员：运维人员，测试人员
结语
通过上述几个步骤后，我们成功对系统进行重构。
重构是一项大工程，但经历重构后的系统也并非完美无缺。重构不是终点，更像是起点。
网友评论