简单分析下阿里云此次秒杀活动失败，细节上的客观因素

1.无用的的 Cookie埋点太多，浪费额外带宽流量。

阿里巴巴旗下有款产品，估计是做数据分析的，这款产品会在页面所有链接URL加上一个spm标签，并会加Cookie埋点。
这样，就会直接或者间接地导致服务器带宽、资源压力加重，因为url参数的变化、Cookie的变化，会直接影响到页面元素的加载的。
比如，/a.jpg?a=1，与/a.jpg?a=2是两个不同的请求，两者将不能互相共用缓存，当然阿里云目前未做页面缓存优化，所以这造成的影响可能并非造成平台响应迟顿的直接原因。而Cookie的变化，则会直接突破前端或者CDN的缓存，节点将会直接请求源服。

2.订单页面绝大多数静态元素未考虑缓存机制。

上图是订单页面的一个CSS，可以清楚看到，响应头，连缓存过期时间都未设置。“现代一点”的浏览器或者会勉强进行缓存，
而死遵循w3c标准的浏览器，则不会对未设置过期缓存头的请求进行缓存。这，是造成刷新后页面样式破掉的最根本原因。（瞬间
猛增的访问量带来巨大流量，让apache拒绝响应）。

3.订单页面包含近5个来源于static.aliyun.com的js请求，和12个来源于static.aliyun.com的css请求。
static.aliyun.com的伺服器是apache，apache能同时建立的连接个数相对巨大访问量相对来说，非常有限。
纵使有集群，也仅仅是成倍地增加响应能力，并未能性能、体验有所提升。
阿里巴巴负责中国区业务的雅虎的前端优化军规里，第一条就是“减少、合并HTTP请求”。
对于JS、CSS这类静态文件，完全可以将同类型合并成一个文件，以减少连接数、流量和资源开销。
可是，阿里云没有这样做。

4.资源预算准备得不充分。
不知道大家有没有注意一个细节，在阿里云订单系统拒绝服务后，已完全无法进入后，统计已购买的主机的页面正常工作的，数据一直保持在更新。
这可以充分说明阿里云事先并未考虑到巨大用户涌入给订单系统和后端DB集群带来的压力，也侧面说明阿里云对自身订单系统并未实现Auto Scale.

当然，其它原因肯定也有。大家一起归纳总结下吧。。。