注册 / 登录

快狗打车(原58速运)订单重构之路

分会场:  爆款架构/数据平台/工程实践

 

案例来源 :

案例讲师

张凯

快狗打车 Java专家

曾任职58同城,58到家。现任快狗打车司机端负责人。8年一线开发经验,涉及过CRM系统、到家微信钱包入口、卡券系统等项目。

扫描二维码分享案例

 

案例简述

 

快狗打车(原58速运)是覆盖中国及东南亚的货运打车品牌。在业务的发展过程中,订单系统随着业务的发展,经历了一些列的改变。由最初的一个简单服务最终演变为支撑日均几十万订单系统,在订单系统的发展过程中,我们经历了单表到多表,单服务到多服务的一个演进过程。此次分享,主要介绍我们在快狗订单服务重构过程中,遇到的问题及我们的解决方案。

 

案例目标

 

随着快狗打车业务的发展,尤其是平台化之后,订单服务已经明显不适用于目前的业务,重构订单服务迫在眉睫。目前的订单服务,因为业务的迅速发展,有很多不合理的地方,比如单表80+字段,单库,没有完善的缓存机制等。本着优化要趁早的思想,在平台化的版本中,我们启动了对订单服务的重构。

 

成功(或教训)要点

 

1)设计尽可能详细到每一步,方案多评审。

2)对老的代码要认真梳理,心存敬畏。

3)规划好要做的每一步,制定责任人跟进。

4)万无一失的回滚方案,确保回的来。

 

案例ROI分析

 

订单服务横向可扩展,订单库横向可扩展,订单服务不再是系统瓶颈。

 

案例启示

 

1)系统架构设计要考虑扩展性,不能仅限于解决目前的业务。

2)如果系统可能是瓶颈,如果可能,要尽可能早的通过各种方法解决。

3)对于历史代码,认真梳理,心存敬畏。

4)要有万无一失的回滚方案。

 

案例在团队中的意义

 

从日均几千单到几十万单,再到可支持百万级订单的订单中心。本次分享详细的诠释了快狗打车订单中心的演进过程、一个典型电商类订单系统的整体架构、我们踩过的那些坑,以及我们的解决方案和一些思考。

 

领取大会PPT

我要参会

大会全套演讲PPT

立即领取

大会即将开幕,点击抢票!

我要参会