生产环境全链路压测建设历程之十 淘宝网 2013 年的建设过程

上一篇内容为《生产环境全链路压测建设历程之九 淘宝网全链路压测的原理》



这一篇，要给大家讲讲淘宝网2013年第一次进行生产全链路压测的过程。一共是分了三个阶段

1.提议阶段，受阻，所有人都反对

第一次提出全链路压测理念的人-李津，他当时问大家：有没有可能在线上环境进行全仿真的测试？所有人的回答都是：不可能。



当然，这对于DBA团来说来是更加不可能的，最大的担心是压测流量产生的数据该如何处理，从来没听说过哪家公司敢在线上系统做压测，万一数据出现问题，这个后果将会非常严重。



2.论证阶段

虽然大家都对上生产压测有极大的不安全感，但2012年双十一的超卖，实在是太痛。

太痛导致大家都有动力去尝试新的玩法，接受新的方式。



一开始DBA极力反对压测数据直接写入到真实表，原因是数据写入容易，但清理难。

一个是因为测试数据和真实数据混在一起，很容易清理错，这是要背责任的。

第二是对于核心的数据表，本来一个表就有几百万条数据，写入大量压测数据后，就算很小心的进行清理，但性能还是会有影响的。



后来中间件团队提出，可否在MySQL同一个实例上建立和真实库一样的影子数据库。DBA团队考虑到如果建了影子库，还需要重新建一大堆用户，工作量也比较大。



到了2013年7月份或者8月份的某一天，综合了工作量和安全性考虑，最终推敲出来影子表的方式。

影子表，是对应到真实表，表结构完全一模一样。在每次压测之前，把影子表重新按照真实表来构造一遍。

3.建设阶段，中间件改造

随着影子表得到了一致的认同，最后的一个核心问题被解决。

中间件团队就开始改造鹰眼、HSF、TDDL、Notify、商品中心、订单中心等一系列的中间件和业务系统 。



从PD、研发、架构师、测试 、运维，加起来有近百人的团队，一起改了2个月 。



上线阶段

第一次生产全链路压测，以失败告终。

我还记得当时候的一个邮件，是通知2013年10月15日凌晨2点-4点，第一次进行生产环境全链路压测演练，当时候的目标是达到6w/s创建的压力。

但第一次，演练失败。。。。因为第一次要发起这么大的压力，流量引擎有bug，流量发不起来。接近100号人，从凌晨11点开始，一直熬到第二天凌晨5点半，失望而归。



我还记得当时候的全链路压测项目组的几个成员，每隔一天就要组织一次生产压测。每次遇到的问题都不一样，只能是凌晨顶着巨大的心理压力来组织大家压测，遇到短时间内解决不了的问题，只能在第二天白天顶着困意来改bug。



如此反复了近五次，终于在2013年双十一11之前的前一周，成功完成了第一次压测。



最后一次生产压测，是2013年11月2日凌晨1点。。。。