数据库重构-数据重构商业,流量改写未来

概述

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

评论：

以下部分步骤和方法是根据我自己项目的实际情况列出的。

业务梳理

要了解原来的业务流程，如果有不合理的业务流程，就要进行业务流程优化。 这通常由公司的业务架构师处理。

数据库重构

项目前期，由于进度匆忙，没有来得及设计表，导致出现各种冗余表，大表，大量冗余字段，扩展性差的表。 因此，在重构系统时，可以先从表入手，通过对当前业务的梳理，对表进行重组。

1、字段过多的表，可以根据部分字段的业务属性抽取新表；

2.删除不再使用的表字段；

3、可以合并的字段尽量合并。 例如，如果你想表明一个产品是旅游产品，就不需要添加类似is_travel的字段。 可以直接给产品类型product_type增加一个枚举值；

4、根据当前业务，将部分表字段下沉到其他表中，从另一个维度输出；

5.如果一张表的扩展属性过多，可以另建一张表存储。

ETC。 。 . .

数据库重构通常由专门的数据架构师处理。 数据架构师必须与业务架构师密切合作。

数据迁移

由于数据库的重建，旧数据库中的数据必须完全迁移。

全量迁移：需要做一个只运行一次的全量迁移程序，一次性迁移旧数据库； 增量迁移：在新系统上线之前，旧系统还在工作，所以新增的数据也必须经过增量迁移。 大规模迁移程序将数据迁移到新数据库。 这个增量程序必须运行到旧系统下线，不会产生新的数据。

db数据自测程序

为了验证迁移程序是否正常工作，还必须编写一个自检程序，不断地比较新旧数据库中的数据，看是否有缺失数据或不等值数据。

业务界面设计

对新设计的表和新梳理的业务重新设计对外业务接口。 当然，由于接口的重新设计，方法的输入输出参数可能会有所不同。 在这种情况下，当连接其他系统时，会产生一些阻力。

业务接口自测程序

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

同步新需求

既然老系统还有新的需求要处理，那么新系统也要考虑是否需要做。 当然，并不是所有老系统的需求都要同时更新到新系统，因为新系统已经做了业务梳理，一些所谓的新功能其实已经支持了。

读制服

数据迁移正常后，通过自测程序发现新界面的输出与旧界面的输出相同。 这时候，如果外部系统，比如A系统，只需要读取这个接口，那么A系统就可以完全使用新的接口了。 逐步让只需要读取接口的系统陆续上线。

写统一

为了方便系统接入，可以开发一个网关系统，让外部系统先透明连接到网关上。 网关系统收到写入请求后数据库重构，先将数据写入旧DB数据库重构，成功后再写入新DB，实现数据双写。 这样做的好处是，系统上线后，如果新的写接口或读接口出现问题，可以立即切换到旧接口。

写unity的难度比较高，需要非常小心。

开发联调

新接口SDK发布后，其他系统可以通过SDK调用新接口，实现开发者之间简单的接口联调。 在此期间，如果遇到业务问题，一定要及时联系业务架构师和数据架构师。 在适当的情况下，可以对业务和时间表进行调整。

上面说了，由于业务接口变化比较大，其他系统接入的时候，会遇到很大的阻力。

测试人员介入

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

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

访问流量

大家可以先切出万分之几的流量到新界面试水。 有问题及时改正。 只要有流量接入，就必须借助各种监控系统进行实时监控，出现问题第一时间报警。 此外，开发人员还必须经常检查日志系统，及早发现问题。 新接口稳定后，所有流量都可以切换到新接口。

观察系统

–

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