一、 写在前面
最近重构项目比较多，写了好几个系统重构方案，很多朋友问，写重构技术方案，有没有什么套路或者框架，都需要做哪些调研和准备工作，这篇文章就重点聊一聊，如何设计可落地的重构方案。
二、重构有没有套路
有套路，多年重构经验表明，我重构已经形成了自己的一套固定模式，然后在这套模式之上，根据业务场景不断的变通，可以说，重构是经验的积累。所以在设计重构方案阶段，就能够避免一些后续的坑。当然也不能完全避坑，因为总有你没有考虑到的地方，这个时候我们要做的，就是如何把风险降到最低，这个也是重构方案的一部分(灰度方案)。
三、什么是重构
想必每一个技术开发都深有感触，很多人到一个新的团队，都会吐槽原来的代码写得乱，扩展性难，历史包袱重。想要重构，却不知道如何下手；也有一些说要重构，但是很多在我看来对于重构没有一个正确的认识。
下面我说几点解释一下:
1. 重构不是重写
做过开发的同学都知道，重写很简单，按照产品的需求，实现需求就好了，没有历史包袱。但是重构是在原有的基础上改，有很多限制性，大框架不能改，对外接口不能变，存储结构设计限制等等。
2. 不要轻易批判前人的代码
大家要相信一点，存在即合理，原来这么设计，一定有它的原因。可能当初调用量不大，可能当初业务场景限制，可能当初资源限制等等，你没有经历过，就不能感同身受。所以不要轻易去批判， 既然直到现在，这个业务场景还在迭代，甚至要面临重构，至少说明该业务场景，甚至是商业场景是成功的。
3. 重构方案先行，落地可分期进行
有时候，我们面临的系统大庞大，历史包袱重，不知道从何处下手，或者说做完重构需要很长的时间。即便是这样，我们的方案也一定是设计完备的(甚至要和产品沟通以后可能增加的业务场景)，不仅要考虑到如何解决现在的问题，还要考虑到之后的扩展性问题，然后再任务拆分，分期进行，一期做哪些，二期做哪些。另外一期重构时间不宜过长，要考虑到投入产出比问题。
4. 不要过度设计，不要为了重构而重构
有时候，我们通过调整参数，调优就能解决的问题，就不需要大动干戈。重构一定是在最后一环，万不得已的情况下进行的。例如: 1、性能瓶颈，无法扩展，2、无法满足现在的业务迭代
四、 写重构技术方案需要做哪些调研
调研可以说是写重构技术方案非常重要的一个环节，往往能够避免很多不必要的坑。
1. 历史痛点在哪里
我们先要通过一定手段，比如：压测，监控等等， 先找到影响原来性能和问题的原因是什么，痛点是什么。只有知道原来的痛，才能知道如何对症下药。
2. 调研新的技术方案
例如原来的存储用的Redis，现在想引入Mysql，那么Mysql能不能支持现在的业务场景(可能需要通过写demo压测)，它又有哪些优势(和原来对比)。亦或者本次要引入新的组件，那么组件可能选择性有很多，选择哪一种比较合适需要有横向对比等等。
3. 梳理业务&影响范围
例如需要梳理出所有的对外接口，这些接口目前线上的高峰期QPS，RT，995耗时是多少，都有哪些调用方。目前系统相关的表是否是独立可控的，SQL语句都需要汇总统计(这个主要是分库分表的时候考虑，因为要考虑到SQL拆分，分库分表的ShardingKey 和 分库分表之后的查询问题)
五、设计技术方案
- 先画出整体架构图[重构前(可选)、重构后]，再画出核心流程图
- 表结构设计(分库分表)，分表情况下要根据目前线上使用场景对分表shardingKey做一个离散度分析。
六、设计灰度方案
技术方案明确之后，再考虑如何灰度，按流量灰度，还是城市，还是开关控制。
七、核对方案
调研阶段梳理的对外接口派上用场了，需要针对每一个对外接口，job脚本，consumer任务等，标注重构改造方案。这个过程也会发现一些细节上的问题，从而完善技术方案。
八、数据校验方案
- 可以利用目前线上请求的log，流量回放的方式请求新接口，然后对比一下返回数据是否和老的一致。
- 如果对表结构有改造，需要对比新老数据是否一致(排除不需要对比字段)
- 灰度阶段可以同时请求新老接口，对比返回数据是否一致。
九、任务拆分
对本次改造需求进行拆分，一期做哪些列举出来 和 二期大概规划。
十、技术方案评审
可以先组内小范围评审，先解决内部可能存在的问题。内部沟通完之后，再组织跨部门技术评审会议。
十一、总结
这篇文章主要讲一下写重构技术方案理论篇，很多都是大家知道的一些道理，但是我想说，这其中有很多细节需要确认，还需要和产品，或者其他组同学沟通。方案是否可落地，除了经验之外，还需要各种测试和调研。
下一篇文章将给大家讲一讲重构技术方案——实战篇，以我们线上真实重构——乘客排队系统重构场景为例，我是如何一步步写重构技术方案以及后续如何落地的。
欢迎关注、不定期分享原创文章。
