一次订单系统重构实践

​在我们的工作中，经常会遇到系统或模块重构工作，今天就来聊一聊我曾经经历过的一次系统重构经历。

01 背景‍

重构发生的背景是，原有的系统架构采用all-in-one的方式，随着业务的快速发展，用户访问量急剧上升，系统请求流量成倍增长，陆续出现了各种问题。当时的系统架构的示意图如下

02 痛点

当时遇到的典型问题有

• 系统模块耦合严重，访问量上涨无法快速扩容

• 数据库表混杂，定位不清。比如支付订单和商品订单在一张表，一个状态字段代表两种不同订单的状态流转含义，经常会出现各种状态异常单据。

• 复杂SQL和跨表join横行，SQL慢查多，数据库频频告警

• 无服务和领域划分，系统和接口耦合严重，经常是单点出问题，全系统宕机

• 接口响应慢，系统稳定性差，数据丢失、错乱情况经常出现

• 产品需求版本庞杂，业务需求场景多，业务逻辑分散，需求迭代速度慢

• 客诉问题高发，排查问题困难，研发疲于奔命在查问题的道路上

面对着这些问题，当时摆在眼前的方案有两个

• 继续按照原有系统迭代，但可能要付出更多的人力、精力来维持系统的稳定性和需求迭代速度

• 完全重构系统，但需要投入一定的人力，并且可能会在短期影响业务的需求迭代进展

考虑到产品会长期迭代，而眼前系统已经成为巨大的瓶颈，因此决定对系统做完全的重构。

当时我被领导安排作为这个重构项目的负责人。但领导也提出了要求

• 公司业务在快速发展中，系统重构期间，需继续保持业务需求的迭代速度，可以适当增加人员

• 新系统设计和规划，需考虑到3年后可能的用户访问量的上涨和数据量的上涨

• 新老系统切换期间，需要保证不影响用户和业务方的正常使用，不出现数据的丢失和错乱

任务既然已经确定了，接下来就是考虑如何做的问题了。

03 方案

系统重构是一个复杂的工程，而在一个业务高速发展的背景下做系统重构，无疑于给飞行中的飞机换引擎，需要考虑周全，计划缜密，才能保证万无一失。

针对面临的问题和目标要求