在前面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公司如何破局？

这个问题，留待下一篇来进行介绍：） 。。