关于重构:浅谈订单系统重构之路线上真实案例分享

前言

最近负责了订单重构我的项目，从技术方案设计，到人员安顿，到最终落地，我的项目圆满完成。
尽管重构我的项目做了很屡次，每次都是在挑战极限，在工夫紧工作重的状况下，井井有条的推动。最终提测品质高，安稳上线，此文章记录一下。

背景

1. 原订单单库单表，数据量大，已达到性能瓶颈，且无奈程度扩容。
2. 订单增长迅速，重构火烧眉毛。

指标

1. 订单分库分表，不便前期程度扩大
2. 订单流程革新，并且平滑过渡到新流程。

重构计划

注: 所谓重构计划，肯定是基于特定场景的，没有对立计划，但核心思想是一样的。

场景: 网约车场景，下单量大，然而大部分订单会派不上司机勾销。

计划: 减少派前订单表，派前订单表分库分表，派上司机后，订单进入派后表(老表)

此计划劣势: 不影响派后订单流程(例如，司机端流程，计费流程)，压力集中在派前表，同时派前表数据无需长时间保留(例如 7 天归档)。派前订单表数据量极小，查问写入效率高。

分库分表计划:

灰度计划

按流量灰度，分为 5 个阶段，平滑过渡到新流程

工夫安顿

开发人力: 4 人 7 个工作日

测试人力: 6 人 3 个工作日

灰度工夫: 2 周

注: 尽管工夫紧，工作重，该有的流程不能漠视

重构收益

本次重构如期上线，并且测试阶段 bug 极少，能够说超预期。

1) 资源不变状况下，下单接口性能晋升 N 倍(N>4)。

2) 重构后下单接口 RT<50ms, 根底服务 (dubbo 服务) 下单接口 RT < 5ms。

3) 订单分库分表，分了 256 张表，8 个库，目前在一个数据库集群，最多反对 8 个数据库集群程度扩大。

4）订单架构分层，分为业务层和数据层，订单外部通信改为 RPC 通信。

舒适提醒

欢送关注“浅谈架构”公众号，不定期分享原创文章。