浅谈订单重构之路

前言

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

背景

1. 1.原订单单库单表，数据量大，已到达性能瓶颈，且无法水平扩容。
2. 2.订单增长迅速，重构迫在眉睫。
3. 
   

目标

1. 1.订单分库分表，方便后期水平扩展
2. 2.订单流程改造，并且平滑过渡到新流程

重构方案

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

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

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

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

分库分表方案:

灰度方案

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

时间安排

调研&方案设计: 4天

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

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

灰度时间: 2周

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

重构收益

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

1. 1.在数据库资源不变情况下，下单接口性能提升N倍(N>4)。
   
2. 2.重构后下单接口RT<50ms, 基础服务(dubbo服务)下单接口 RT < 5ms。
   
3. 3.订单分库分表，分了256张表，8个库，目前在一个数据库集群，最多支持8个数据库集群水平扩展。
   

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