浅谈订单重构之路

前言

最近负责了订单重构项目，从技术方案设计，到最终落地，项目圆满完成。虽然重构项目做了很多次，每次都是在挑战极限，在时间紧任务重的情况下，有条不紊的推进。最终提测质量高，平滑上线，此文章特此记录一下。

背景

1. 原订单单库单表，数据量大，已到达性能瓶颈，且无法水平扩容。

2. 订单增长迅速，重构迫在眉睫。

目标

1. 订单分库分表，方便后期水平扩展

2. 订单流程改造，并且平滑过渡到新流程。

重构方案

注: 所谓重构方案，一定是基于特定场景的，没有统一方案，但核心思想是一样的。

场景: 网约车场景，下单量大，但是大部分订单会派不上司机取消。

方案: 增加派前订单表，派前订单表分库分表， 派上司机后，订单进入派后表(老表)

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

img.png

分库分表方案:

img.png

灰度方案

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

一阶段	二阶段	三阶段	四阶段	五阶段
1/100000	1‰	10%	50%	100%

时间安排

img.png

调研&方案设计: 4天

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

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

灰度时间: 2周

注: 虽然时间紧，任务重，该有的流程不能忽视

重构收益

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

1. 在数据库资源不变情况下，下单接口性能提升N倍(N>4)。

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

3. 订单分库分表，分了256张表，8个库，目前在一个数据库集群，最多支持8个数据库集群水平扩展。

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