大型系统重构的步骤简单梳理

概述

随着公司业务不断的发展，⽤户量不断的增加，对系统的性能要求会越来越⾼，⽽原来仓促做出来的项⽬，其不合理性的地⽅就会不断的暴露出来。⼤家如果接触过⾮常赚钱的互联⽹产品，⼀定会知道产品的⼀个⼩⼩的bug，公司就可能损失好⼏百万甚⾄⼏个亿。当产品的⽤户数达到⼀定量的时候，对系统的各个⽅⾯的要求就越⾼，例如qps、cpu、容灾、降级、限流、可扩展性、可维护性等等。系统除了要应付⼤量的并发请求，还必须快速⽀持各种业务需求，必须对系统进⾏⼤重构。备注：

下⾯的⼀些步骤和⽅式是根据我⾃⼰的项⽬的实际列出的。

业务梳理

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

数据库重构

前期的项⽬，由于赶进度，并没有充⾜的时间设计表，导致各种冗余表、⼤表、⼤量的冗余的字段、扩展性差的表。所以重构系统的时候，可以先从表开始，通过对当前业务的梳理，重新把表整理⼀下。

1. 字段太多的表，可以根据部分字段的业务属性，抽取成⼀个新表； 2. 已经不再⽤的表字段，删除掉；

3. 可以合并的字段，尽量进⾏合并，例如，想表⽰⼀个商品是旅游商品，就没必要新增⼀个类似is_travel的字段,可以直接在商品类型product_type中增加⼀个枚举值即可；

4. 根据当前业务，把⼀些表字段下沉到其他表，从另外⼀个维度输出； 5. 如果⼀个表的扩展属性太多的话，可以另外建⽴⼀张表存储。等等。。。。

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

数据迁移

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

1. 全量迁移：需要做⼀个只跑⼀次的全量迁移程序，把旧数据库中⼀次性迁移过来；

2. 增量迁移：新系统上线之前，旧系统也⼀直在⼯作着，那么新增的数据也必须通过⼀个增量迁移程序把数据迁移到新数据库。这个增量程序必须⼀直跑，直到旧系统下线，不会产⽣新数据。

db数据⾃检程序

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

业务接⼝设计

针对新设计的表和新梳理的业务，重新设计对外的业务接⼝。当然由于重新设计了接⼝，⽅法的⼊参、出参等都可能不⼀样了。这样的话，

其他系统接⼊的时候，会遇到⼀些阻⼒。

业务接⼝⾃检程序

必须通过⼀个业务接⼝⾃检程序，不断的⽐对新旧业务接⼝的输出是否⼀致。这个是⼀个⾮常关键的程序，可以帮助检查新数据和新接⼝的问题。

同步新需求

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

读统⼀

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

写统⼀

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

写统⼀的难度是⽐较⾼的，需要⾮常的细⼼。

开发联调

新接⼝发布SDK后，其他系统可以通过SDK调⽤新接⼝，进⾏开发⼈员与开发⼈员之间进⾏简单的接⼝联调。这期间，如果遇到业务问题了，必须及时联系业务架构师和数据架构师。适当的情况下，可能业务和表得调整。就像上⽂说的，由于业务接⼝改动⽐较⼤，其他系统接⼊的时候，会遇到很多阻⼒的。

测试⼈员介⼊

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

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

接⼊流量

可以先切万分之⼏的流量到新接⼝，试试⽔。有问题的话，及时修改。只要有流量接⼊，就必须使⽤各种监控系统实时监控，有问题的马上告警。另外，开发⼈员也必须经常查看⽇志系统，及早发现问题。⼀旦新接⼝⾮常稳定后，则可以将全部流量切⼊到新接⼝。

观察系统

–

新接⼝接⼊所有流量后，除了监控系统监控接⼝之外，开发⼈员必须经常看⽇志系统，观察系统是否正常⼯作。最好定⼀个任务，让开发⼈员轮流观察系统。