生产环境全链路压测建设历程 17:某快递 A 股上市公司的生产压测案例之前言

发布于: 2020 年 12 月 23 日

在前面16篇文章里面,主要讲了淘宝网生产环境全链路压测的从0到1的过程。



对于淘宝网来说,在2012年的时候,基础设施都是统一的,达到了类似大秦帝国那样“车同轨,书同文”的阶段。

在初期最大的难点是论证压测数据放在哪里,最后通过影子表这样一个巧妙、低成本的方式来解决了。



而在修改中间件这块,对于淘宝网来说,由于有统一自研的技术框架,难度不大,只是投入了近百人去进行修改,测试,升级,运维。随便算算是近千万的预算。



但是不是每一家大型企业,如果系统也会有流量突发的场景,也有痛点和驱动力想做生产环境的全链路压测,但淘宝网的路,是不是真的适合每一家企业?

某快递A股上市公司的生产压测建设历程

背景

某快递A股上市公司,为了阅读方便,后续简称D公司。



D公司在2017年的时候,快递业务日均订单200万以上,在双十一的时候,日订单量会超过1000万单。



IT团队的人员有接近1000人,核心系统的后端都是Java开发的,有部分核心系统是IBM来建设的,也有一些新的系统是采用开源软件来搭建微服务架构。

遇到的问题

2017年双十一前,也动用了近百人提前做各个系统的容量评估,系统优化。但在双十一零点,上游电商平台的快递订单推送突然增加到3倍以上。

OMS系统出现了MySQL死锁问题,迫不得已重启了数据库,应用大概花了20多分钟才恢复正常。

造成的影响

在D公司系统重启的时间段里面,上游电商平台已经感知到快递订单推送失败,电商平台本身对接了很多别的快递公司,订单推送的权重做了调整,D公司因为系统出现了问题,直接影响到了业务收入。



很明显,D公司面临了淘宝网2012年双十一同样的问题,按照淘宝网的成功经验,最终大招就是在生产环境上面做全链路压测。

D公司做生产压测的难点和挑战

中间件不统一

系统都是Java

有IBM实施的历史系统 (ESB,Weblogic)

微服务架构的新系统(Dubbo)

人才储备

原来并没有底层中间件的技术专家人才储备。

时间成本

对于管理者来说,自己招人做,周期长,起码3-5个月,ROI不高;

100多个应用,改起来时间周期太长;

D公司如何破局?

这个问题,留待下一篇来进行介绍:) 。。



发布于: 2020 年 12 月 23 日阅读数: 28
用户头像

还未添加个人签名 2017.12.21 加入

还未添加个人简介

评论

发布
暂无评论
生产环境全链路压测建设历程17:某快递A股上市公司的生产压测案例之前言