随着公司业务不断的发展，用户量不断的增加，对系统的性能要求会越来越高，而原来仓促做出来的项目，其不合理性的地方就会不断的暴露出来。大家如果接触过非常赚钱的互联网产品，一定会知道产品的一个小小的bug，公司就可能损失好几百万甚至几个亿。当产品的用户数达到一定量的时候，对系统的各个方面的要求就越高，例如qps、cpu、容灾、降级、限流、可扩展性、可维护性等等。系统除了要应付大量的并发请求，还必须快速支持各种业务需求，必须对系统进行大重构。

备注：

下面的一些步骤和方式是根据我自己的项目的实际列出的。 

业务梳理

要弄懂原来的业务流程，如果有不合理的业务流程，必须进行业务流程优化。这种一般是公司的业务架构师来处理的。 

数据库重构

前期的项目，由于赶进度，并没有充足的时间设计表，导致各种冗余表、大表、大量的冗余的字段、扩展性差的表。所以重构系统的时候，可以先从表开始，通过对当前业务的梳理，重新把表整理一下。 
1. 字段太多的表，可以根据部分字段的业务属性，抽取成一个新表； 
2. 已经不再用的表字段，删除掉； 
3. 可以合并的字段，尽量进行合并，例如，想表示一个商品是旅游商品，就没必要新增一个类似is_travel的字段,可以直接在商品类型product_type中增加一个枚举值即可； 
4. 根据当前业务，把一些表字段下沉到其他表，从另外一个维度输出； 
5. 如果一个表的扩展属性太多的话，可以另外建立一张表存储。

等等。。。。

数据库重构，一般由专门的数据架构师来处理。数据架构师必须和业务架构师紧密配合。 

数据迁移

由于对数据库进行了重构，那么旧数据库的数据必须完整的迁移过来。

1. 全量迁移：需要做一个只跑一次的全量迁移程序，把旧数据库中一次性迁移过来；
2. 增量迁移：新系统上线之前，旧系统也一直在工作着，那么新增的数据也必须通过一个增量迁移程序把数据迁移到新数据库。这个增量程序必须一直跑，直到旧系统下线，不会产生新数据。 
   
   

db数据自检程序

为了验证迁移程序是否正常工作，还必须写一个自检程序，不断的比对新旧数据库中的数据，看看有没有漏迁的数据或者值不相等的数据。 

业务接口设计

针对新设计的表和新梳理的业务，重新设计对外的业务接口。当然由于重新设计了接口，方法的入参、出参等都可能不一样了。这样的话，其他系统接入的时候，会遇到一些阻力。 

业务接口自检程序

必须通过一个业务接口自检程序，不断的比对新旧业务接口的输出是否一致。这个是一个非常关键的程序，可以帮助检查新数据和新接口的问题。 

同步新需求

由于旧系统还不断的有新需求需要处理，新系统也必须考虑是否需要做。当然不是所有旧系统的需求都要同步更新到新系统的，因为新系统做了业务梳理，某些所谓的新功能，其实已经支持了。 

读统一

当数据迁移已经正确的工作后，通过自检程序发现新接口的输出已经和旧接口输出已经一样了，这个时候，如果外部系统，例如A系统只需要读的接口,那么A系统就完全可以使用新接口了。逐步的让只需要读接口的系统陆续上线。 

写统一

为了方便系统接入，可以开发一个网关系统，让外部系统透明的先接到网关上。网关系统接收到写的请求后，先把数据写入到旧的DB，成功后，再把数据也写到新的DB，做到数据双写 。这样做有个好处，就是系统上线后，如果新的写接口或者读接口有问题，可以立刻切换到旧的接口。

写统一的难度是比较高的，需要非常的细心。 

开发联调

新接口发布SDK后，其他系统可以通过SDK调用新接口，进行开发人员与开发人员之间进行简单的接口联调。这期间，如果遇到业务问题了，必须及时联系业务架构师和数据架构师。适当的情况下，可能业务和表得调整。

就像上文说的，由于业务接口改动比较大，其他系统接入的时候，会遇到很多阻力的。 

测试人员介入

除了接口功能测试之外，必须做一个完整的性能测试和稳定性测试。同时必须搭建测试联调环境，与其他系统的测试人员进行联调，其他系统要接入到新接口。

这个阶段，最好找靠谱的测试人员，即懂测试技术技巧又懂业务的。 

接入流量

可以先切万分之几的流量到新接口，试试水。有问题的话，及时修改。只要有流量接入，就必须使用各种监控系统实时监控，有问题的马上告警。另外，开发人员也必须经常查看日志系统，及早发现问题。一旦新接口非常稳定后，则可以将全部流量切入到新接口。 

观察系统

– 
新接口接入所有流量后，除了监控系统监控接口之外，开发人员必须经常看日志系统，观察系统是否正常工作。最好定一个任务，让开发人员轮流观察系统。

重构需要注意的点