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

前言

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

背景

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

目标

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

重构方案

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

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

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

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

分库分表方案:

灰度方案

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

一阶段	二阶段	三阶段	四阶段	五阶段
十万分之一	千分之一	10%	50%	100%

时间安排

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

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

灰度时间: 2周

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

重构收益

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

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

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

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

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

温馨提示

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