正文
容量规划这个事情，整个过程大概经历了7-8年的时间，第一个阶段就是非常早期的阶段，我们当时的评估手段就是拍脑袋，就是根据一些负载情况，系统响应时间等各种各样的表现去拍一个数字出来。比如说当时我问一个技术高管，我们一台服务器是怎么去判断是不是够负载够高，要支撑多少流量？他告诉我一个经验值，你每台服务器支持100万的PV。下面这个流量曲线是当时一天的流量曲线，会有三个峰值，早上九点到十点，中午两三点到五点，晚上八点到十点之间都是峰值。为什么说是100万呢？这就是一个经验值，我们希望做到一半的服务器停下来之后去做发布，这个时候能够去支撑线上的流量，同时我们要看峰值的情况下，我们全部能够支撑住。这样去算的话，实际上单机支撑是320万的PV，这是一个当时的经验值。
当然这个经验值是有效的并起作用的，原因是当时的系统架构相对简单，你可以理解为把整个淘宝所有的逻辑和模块都集中在一个系统里面，所以各个模块之间的热点是有时间差的，这个时间差可以让系统的资源被充分利用服务器可以自己调度来各个资源的分配。后面到了第二个阶段，系统进行了分布式改造，这个时候就会出现问题，以前会员的调用和交易的调用都是在一台服务器上，交易处理需要调用会员的信息，系统分开之后，交易系统和会员系统之间调用其实是有一个比例的，比如1次交易要10次会员的调用，这个比例是多少？当系统多了之后这个比例是比较难搞清楚的，所以必须要引入一些压测机制。总结一下：第一阶段就是什么都没有，就是拍脑袋；第二个阶段引入压测机制，像一些商业的压测工具我们也引入进来了。当时有两个目的，第一个是我们的系统上线之前要做压测，你的响应时间，你的负载要能够达到上线的要求；第二个目的，希望我们能够根据线下的压测情况，能够准确的评估出线上大概需要多少服务器。第二个目的是怎么也达不到，我记得当时性能压测团队还做了一个项目，我记得叫做线上线下容量的关系，做了这些事情其实没有任何结果。因为大家可以想一下，线上的环境和数据和线下完全不一样，这里面没有规律可寻，你没办法通过线下压测的指标能反馈到线上去。这时候怎么办？我们又换了一下思路，直接在线上压测，当时来看这个决定非常疯狂，因为没有一家公司，包括阿里巴巴之前也没有人在线上直接做压测。我们直接选了一些工具，通过前一天的日志大概拉出所有的日志做回访，直接在线上做，压出来之后其实可以知道每个系统大概的一个容量需求，比如说根据它的响应时间和负载设定一个的阀值，看它的QPS多少，然后把它做出来。
第二件事情我们做了一个分流压测，系统架构全部是基于一整套的中间件，所以只要简单的通过软负载调整服务器的流量配比，就可以实现单机单系统的容量评估，简单点说就是把线上的流量调整到一台服务器上，通过调整应用端或者服务端的流量配比，增加服务器的流量的权重，这时候它的负载和QPS也会上升，我们把这个过程记下来。这里已经是两种场景了，一种是回放日志，这是模拟流量进行压测；第二种是一种真实的流量压测，我们让它每天线上跑并产生数据。这个事情做完之后意义很明显：替代了线下性能压测的过程，因为它可以让每个系统每天能够跑出来它的数据情况，比如实际生产中性能表现情况，比如某个项目发布有没有影响它的性能等等，这些指标都可以看出来。。
第三个，做到这里，我们发现这里面其实还有个问题，那就是它没有基于场景化。比如我买件衣服，在平时我买东西的流程可能是从购物的搜索框里面搜索，或者是从一些类目的导航里搜索，从搜索再到购物车，再到下单。双十一推的商品具有确定性，很多的频道会把卖家比较好的促销的商品直接拿出来，作为一个频道页；而双十二的时候推的是店铺，KPI不一样，因而推的东西也不一样。比如说双十一商品相关的服务器系统流量会高，它所需要的服务器也会更多一些。双十二的时候就是跟店铺相关系统的服务器需要会更多一些。它跟你平时的流量表现是不一样的，你用平时的流量去计算你的场景化流量，这也是不准确的，所以接下来我们又做了下面这个事情，就是场景化的压测。
场景化压测，这是在我们从2013年开始做的事情，就是之前都没有对外讲过的核武器。09年是最顺利的一次双11，但是没有什么流量。10年、11年、12年，其实这三年的双11总是有些问题，那就是心里没底。就像刚才讲到了，其实峰值的时候，你没办法得出做出响应的这么一个临界点。当然在13年的时候，我们做了这个场景话压测之后，有了一个本质的变化，13年的表现非常的好，包括14年也非常好，这就是我们内部称之为核武器的场景化压测。这个对于营销和促销类的活动，就是那种有峰值的，在这个时间点之前峰值非常低，这个时间点之后峰值突然上去了的场景，这种压测是非常有效的一种方法。
