「头条关注【Java思享汇】，面试、各种技术栈、架构设计持续更新中～」

分享初衷：工作几年之后基本都会经历过大大小小的系统重构，笔者经历过单体应用拆分微服务的系统重构，数据异构，业务系统重构。借助此次分享把之前重构的经验进行系统化整理，希望可以形成一份系统重构的SOP。还有就是“以史为鉴”，将重构过程中总结的经验应用到新系统设计开发中，使新系统扩展性更强，可维护性更高。

什么是系统重构

重构背景

系统在经过多年需求迭代后基本上会面临一种“后有追兵，前有悬崖，进退两难”的境地。
后有追兵：面对维护了数年之久的大型遗留系统，我们到底改还是不改？不改，面对越来越多的需求变更，我们维护的成本越来越高，变更变得越来越困难；面对不断涌现的新技术，使我们的系统显得越来越丑陋与落后。
前有悬崖：原本运行得好好的系统，凑合一下还可以运行几年。一不小心改出问题了，系统可能立马就歇菜儿了，面对大量的用户投诉，需要到处救火，其中将要承受的巨大风险。
难道真的“熊掌和鱼不能兼得”吗？有没有一种方法，能够既保证我们系统可以技术改造，又能有效地避免改造过程的风险吗？有，那就是系统重构。

重构定义

在不改变软件外部行为的基础上，改变软件内部的结构，使其更加易于阅读、易于维护和易于变更。定义中非常关键的前提就是“不改变软件外部行为”，这个前提非常重要，它保证了我们在改造原有系统的同时，不会为原系统带来新的BUG，以确保改造的安全。比如我们重构了一个接口，那么我们重构完后的接口需要保证在入参相同的情况下，出参也是一致的。

重构分类

重构分类大致分为如下4类：
1.平台级别重构：针对整体平台的重构，比如阿里早期采用的LAMP（Linux Apache Mysql PHP）架构，后面整体迁移到了Java平台。
2.架构级别重构：通过架构的调整和重新设计，改善原有架构的不合理之处，比如我们对单体应用的拆分，引入微服务架构，进行系统拆分；引入缓存设计提升系统整体性能；引入消息中间件对系统进行异步解耦；引入分布式事务框架解决系统间分布式事务场景等。
3.代码级别重构：使用设计模式、封装继承、抽象代码，使得代码扩展性、易读性更好，执行效率更高。如审核系统在重构过程中应用了模版方法、策略模式、工厂模式、观察者模式等。
4.数据层面重构：1.针对数据量较大的业务，采用分库分表存储；2.数据查询分析等实时性要求不高的场景，将实时计算切换为离线计算，如业绩重构过程中，将之前依赖Redjob进行多表Join实时计算的逻辑迁移到Rugal通过Hive进行离线计算，慢查询由最慢超过20S优化到1S内完成，性能和代码可读性有了极大提升；3.利用OLAP数据库，如Doris或者ES替代直接查询Mysql场景提升查询性能。

为什么要系统重构

找痛点，重构的原因是多种多样的，但无外乎以下这几个：
1.业务增长太快了，老系统之前的设计无法承载过高的请求压力（性能差）。
2.系统稳定性差，漏洞很多，有时候经常要靠重启解决。
3.经过多年的发展，充斥着大量的不合理的代码，杂乱，难以维护。
4.业务需求满足起来很困难或无法满足 。
5.老系统使用的语言无人维护了。

如何进行系统重构

重构的过程是复杂的，我们分步骤按照顺序总结。

说服业务方

业务最关注的是什么时候上线他们的新需求，满足当初定下的OKR。而会觉得系统内部的改造和他们关系不大，一般他们不会主动来推动进行系统重构的。而重构又是一个费时费力的工作，还有可能导致现在的业务需求迭代暂停，影响业务的开展。所以，我们需要极力的说服业务，陈述利弊。不去重构有可能导致系统瘫痪，需求迭代慢等。
而系统重构后的好处就太多了，比如，页面交互更加友好，可以快速满足新需求上线，趁着重构的过程可以解决现有不合理的业务流程，还能使系统高可用、高性能等。

确定重构目标

本次重构达成的最终目的是什么？
●引入合理的架构
●新的技术和框架
●提高代码质量
●系统预期的性能指标

老系统熟悉与梳理

重构是基于老系统，而不能脱离老系统，这就需要对老系统了如指掌，特别是关键的环节步骤不能有任何差错。
●旧系统资料和信息收集
●业务流程梳理
●旧系统关键代码Review
●疑难点及时沟通

任务优先级拆分和时间预估

系统重构往往是复杂、繁琐的，涉及到功能点很多，我们不可能“一口吃完”，所以重构过程中需要对任务进行拆分，确定好优先级，并做好重构里程碑（阶段时间点），申请到需要的资源（产研、测试等），采用“小步快跑”方式进行。

系统整体设计

技术选型

一般老系统技术栈都相对落后，在系统重构的过程中，可以结合公司当前的技术栈甚至行业流行的技术栈进行技术选型，选择系统应用后性能更好、使用更便捷，接入成本更低的技术来满足我们的需求。列举几个之前选型的case：
注册中心选型

背景：在单体应用拆分微服务过程中，拆分出来的微服务多达十几个，其中涉及到解决前端跨域、服务鉴权、请求审计日志统一记录、接口限流熔断等问题，因此搭建应用网关来解决上述问题，网关在做服务发现过程中涉及到使用注册中心，基于此对业内注册中心进行技术选型，最终选择了通过Nacos来作为注册中心使用，选择主要原因是注册中心在一致性协议上选择AP模型，同时Nacos支持配置中心，还有比较友好的管理界面。
消息中间件选型

背景：也是在单体应用拆分微服务过程中，需要借助MQ来进行服务间的异步解耦和流量削峰填谷，其中重点关注指标为吞吐量、开发语言和实效性，最终选择了RocketMQ，比较重要的原因是之前负责的业务为财务方向，存在分布式事务的场景，因此正好借助RocketMQ的事务消息来处理分布式事务。
OLAP引擎选型

背景：最近在审核系统重构过程中，需要将物料审核数据由Mongo（1608万）迁移到Mysql数据库中，但是物料审核列表查询条件有很多，数据量也很大，不可能将这些查询字段都建索引，计划将物料数据实时同步到OLAP数据库一份，目前也是在调研选择Doris或者是ES，如果Doris实时性满足的话，优先选择Doris，因为其查询语法和Mysql基本一致，后期开发维护成本非常低。

数据迁移

在系统重构过程中，如果涉及到对数据进行处理，一般分为以下3种情况：
1.对历史数据库中的表按照业务进行拆分（单体->微服务）该场景对表结构没有太大改动，基本上是将数据由之前的老库迁移到业务划分后的新库，但在业务划分阶段需要重点考虑数据表迁移后造成的分布式事务问题。
2.为了提升系统性能，将数据同步到OLAP引擎数据库中，该场景也不会对表结构有太大改动，核心点是关注数据变更的实时性和数据同步的check工作。
3.数据库重构，比如数据由Mongo迁移到Mysql；数据容量变大需要分库分表处理。以上2中场景是相对比较复杂的，因为要保证系统运行的稳定性，支持可回滚，需要进行数据双写，所以在重构前期需要考虑以下几点：
a.双写过程中保证数据不丢失（监听binlog同步支持重置位点或接口回刷）
b.如果监听binlog同步数据，需要保证消费数据的顺序性
c.双写过程中保证数据不重复（找到数据联合唯一索引）
d.数据双写需要对数据进行染色，避免数据双写死循环问题
e.分库分表需要确定好数据分片策略（分片键）
f.做好数据校验和数据修复方案

流程图梳理

重构过程中对系统间交互流程的梳理是很重要的，这样能够清晰、直观的了解整个系统。画流程图可以使用processon网页版即可。以物料审核入库流程为例：

UML设计

下面是代码（类、接口）层面的设计，主要还是通过UML来展现，画图也可借助processon进行，UML的价值是便于研发内部沟通和理解。帮助沟通设计思想，理解系统或业务流程。特别在新系统中运用一些设计模式来增强系统扩展性的时候，显得会更加直观。以审核系统重构为例：

系统灰度和回滚方案

系统重构进行切换是一个非常重要的一个环节，在最初做设计的时候就要考虑到如何进行切换，而且这个灰度设计需要贯穿重构始终，避免因为切换方案引起服务不可用或是引入系统BUG。
平时工作中比较常用的方式是通过配置中心设置灰度开关进行系统切换，这种方式优势：成本比较低，回退速度比较快。比如我们以城市编码作为灰度开关参数，重构系统上线后可以先打开一个城市，进行小部分流量灰度，运行一段时间没问题再逐步打开其他城市灰度，这样如果出现问题，范围可控，并且可以及时通过灰度开关进行回滚，保证系统高可用。不足：对代码有侵入性。
其他灰度方式相对复杂，比如：
●蓝绿发布，需要两套服务集群，核心是利用负载均衡组件进行分流，和上面说的灰度开关原理类似。优势：升级切换和回退速度非常快，不足：需要两倍机器资源。
●金丝雀发布，只需要一套服务集群，发布时先发布一小部分机器进行验证，确认符合预期再逐步将剩余机器更新。优势：相对蓝绿发布只需要一套集群，不足：发布过程中出现问题需要一定回滚时间。

数据监控和报警

系统重构后我们需要对新系统或者新功能的运行情况进行整体把控，可以配置一些指标看板或者通知告警，一旦不符合预期，我们能够及时接收到通知进行快速干预。不只是系统重构，在日常开发中也需要增加监控和告警，对异常情况进行通知。

技术方案评审

正是因为系统重构的复杂性，所以通过技术方案评审可以解决以下问题：
●发现重构系统在功能、逻辑、实现上不合理的地方。
●确认新系统重构过程中是否符合当前的开发规范。
●便于进行项目管理，方便日后查阅。

系统联调测试

联调测试也是系统重构非常重要的一环，核心有以下3点：
1.系统检查：对比新旧系统的业务接口出入参，对比新旧系统新产生的数据是否符合预期。
2.联调：包含内部、外部的系统联调。并约定好上线先后顺序和时间点。
3.测试：主要包含功能性测试，性能测试（核心高QPS接口需要进行压测），针对非常核心的系统可以借助工具录制线上流量，记录接口出入参数，进行流量回放测试。

上线清单

在上线之前做好准备工作，将核心check事项罗列清楚，涉及到多方一起上线，需要协调好上线顺序和时间点，做好数据库表、配置中心等初始化工作。举例如下：

复盘文档

重构系统上线后，特别是上线效果没有达到预期的情况，需要进行复盘，主要有3方面价值，1.发现问题；2.总结经验；3.促进成长。举例如下：