前言
最近负责了订单重构我的项目,从技术方案设计,到人员安顿,到最终落地,我的项目圆满完成。
尽管重构我的项目做了很屡次,每次都是在挑战极限,在工夫紧工作重的状况下,井井有条的推动。最终提测品质高,安稳上线,此文章记录一下。
背景
- 原订单单库单表,数据量大,已达到性能瓶颈,且无奈程度扩容。
- 订单增长迅速,重构火烧眉毛。
指标
- 订单分库分表,不便前期程度扩大
- 订单流程革新,并且平滑过渡到新流程。
重构计划
注: 所谓重构计划,肯定是基于特定场景的,没有对立计划,但核心思想是一样的。
场景: 网约车场景,下单量大,然而大部分订单会派不上司机勾销。
计划: 减少派前订单表,派前订单表分库分表,派上司机后,订单进入派后表(老表)
此计划劣势: 不影响派后订单流程(例如,司机端流程,计费流程),压力集中在派前表,同时派前表数据无需长时间保留(例如 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 通信。
舒适提醒
欢送关注“浅谈架构”公众号,不定期分享原创文章。