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

 

目前正在参与公司一个核心大系统的重构工做。本文梳理一下大型系统重构的一些步骤和心得。

概述

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

备注：

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

业务梳理

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

数据库重构

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

等等。。。。

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

数据迁移

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

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

db数据自检程序

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

业务接口设计

针对新设计的表和新梳理的业务，从新设计对外的业务接口。固然因为从新设计了接口，方法的入参、出参等均可能不同了。这样的话，其余系统接入的时候，会遇到一些阻力。

业务接口自检程序

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

开发联调

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

就像上文说的，因为业务接口改动比较大，其余系统接入的时候，会遇到不少阻力的。

测试人员介入

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

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

接入流量

能够先切万分之几的流量到新接口，试试水。有问题的话，及时修改。只要有流量接入，就必须使用各类监控系统实时监控，有问题的立刻告警。另外，开发人员也必须常常查看日志系统，及早发现问题。一旦新接口很是稳定后，则能够将所有流量切入到新接口。

观察系统

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