第十个双11已圆满结束，但是技术的探索永不止步。阿里技术推出《十年牧码记》系列，邀请参与历年双11备战的核心技术大牛，一起回顾阿里技术的变迁。
“稳定，压倒一切”，如何实现双11的平稳支撑是阿里技术人永恒的目标。今天，阿里资深技术专家游骥，将围绕“容量规划的精准度与确定性”、“容量规划相关环节的效率和成本”两个因子，详细解读阿里容量规划的五次历史演进。
阿里资深技术专家游骥
2018年是双11的第十个年头。每年双11备战环节，稳定性都是最受关注的头等大事。
十年以来，稳定性相关的技术体系和双11就像DNA的双螺旋，彼此相生相长。在双11场景的锤炼之下，阿里的稳定性技术体系也成为了行业的标杆和效仿对象。
穿越10年，双11给技术留下最深的认知应该算是突发大流量的冲击。
从第一年开始，双11的0点时刻就代表了我们的历史最高业务访问量，它通常是日常流量的几十倍甚至上百倍。因此，如何让一个技术和业务持续复杂的分布式站点去更平稳支撑好这突如其来的流量冲击，是我们这10年来一直在解的题。
在双11非常多的备战环节中，容量规划是最重要也最具挑战的环节之一。在如此庞大的分布式系统架构下，该为每一个业务系统分配多少资源成为一大技术挑战。
其实，容量规划就好比是一个天平。天平的一端是成本，我们需要尽可能地用较少的资源来支撑好我们的业务；另一端是稳定性，在成本尽可能低的情况下，各个系统都能跑在一个合适的水位，既保障业务的正常运转，又不出现局部的资源浪费。
容量规划演进路线
围绕“容量规划的精准度与确定性”、“容量规划相关环节的效率和成本”这两个最核心的驱动力因子，容量规划主要经历了五次大的演进：
一、人工估算容量阶段
这个时期，双11对于系统的资源需求尚处于人工估算阶段。比如2009年的容量规划就是主要通过人工估算的方式来完成的。各个系统的负责同学聚在一起开个会，将信息汇总到excel表格上，花上半天或者一天的时间就把容量规划的机器预算给定下来了。而且，各个系统通常都留了比较大的机器冗余，业务的流量也不大，即使估算得不准也不会造成大的业务影响。
二、线下性能压测评估容量阶段
2009年的双11，虽然业务量级还不够近年双11峰值的零头，但是业务量的暴涨却直接给我们的系统来了一轮非常大的冲击。
因此，在2010年，我们开始着手开发一套系统化的容量规划平台，这个时候，容量计算的公式也被第一次提了出来。在这个公式里有两个至关重要的变量：预估业务量级与单机能力，预估业务量级代表对系统调用量的估算，而单机能力则代表单台机器最大的服务能力。
容量规划公式
其实，容量规划公式理解起来并不复杂，预估业务量级除以单台机器的服务能力得到业务系统所需要的最小机器数，最小机器数作为理论的机器数下限，加上一个buffer值确保万无一失，得出最终需要准备的机器数。
预估业务量级为双11等业务场景下的业务系统调用量的一个预计值，比如双11 0点同时会有多少人访问商品详情、有多少人访问我的购物车、有多少人下单、有多少人付款等等，预估业务量级我们通过ＢＩ（商业智能）的分析，结合相应的预测算法就能够拿到比较准确的值。
单台机器的服务能力相对就没那么好拿到，在2010年容量规划平台的1.0版本当中，单机能力的获取主要通过线下的性能测试来获取。我们当时已经拥有非常成熟的线下的性能测试环境，于是在性能测试环境对各个业务系统逐个进行性能测试，获得了每个业务系统的单机能力值。
解决了两个关键变量的之后，Csp容量规划平台正式登上阿里的技术舞台，在2010年我们完成了从人工容量规划到系统化容量规划的过度。
三、线上压测评估容量阶段
Csp容量规划平台上线之后，在当年的双11当中立刻起到立竿见影的效果，相对于之前纯人肉的容量规划模式，不但节省了人力成本，更重要的是通过数据计算的方式取代了传统的经验预估方式，大幅提升了我们在容量规划的准确性。
为了获取到更加精准的单台机器服务能力值，在线上压力测试的模式上，我们进行了非常多的探索，积累了不少经验，这些经验后续为业界的容量规划之路树立了典范：
a．线上模拟压力测试获取单机能力
线上模拟压力测试对线上应用系统发起模拟调用。模拟请求保障了环境的真实性，能够很大程度提升单机能力的准确性。线上模拟压力测试操作起来比较便捷，能够借助的工具也非常多。
b. 线上流量复制压力测试获取单机能力
线上模拟压力测试解决了压测环境的真实性问题，却没有完全解决流量真实的问题，如果能做到流量和环境都是真实的，通过线上压力测试拿到的单机能力才更具备说服力。线上流量复制通过将线上某一台机器的流量扩大N倍复制到压测的目标机器，当线上机器的流量非常低的时候，复制N倍流量还能够有效地将流量进行放大。
c. 线上引流压力测试获取单机能力
针对流量复制带来复杂性和成本问题，我们继续去探索一种既精准又方便快捷的线上压测模式。阿里的业务系统都是分布式架构，一个业务系统由若干机器同时提供服务，如果能够把分布式环境的流量比较集中地调用到某一台机器，就能起到压测一台机器的目的！于是线上引流压力测试的模式被用到生产环境。
线上引流压力测试使得阿里集团大部分业务系统能够获取到非常精准的线上单机能力，是目前使用的最广泛的一种线上单机压测模式。
四、全链路压测阶段
容量规划平台从单个点的维度解决了容量规划的问题，然而在进行单点容量规划的时候，有一个前提条件：下游依赖的服务状态是非常好的，实际情况并非如此。
此外随着分布式系统架构的技术组建越来越多，也很难将所有的技术环节从前到后都做好单点容量规划。
双11 当天0点到来的时候，从CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路上都面临着巨大流量，这个时候应用的服务状态除了受自身影响，还会受到依赖环境影响，并且影响面会继续传递到上游，哪怕一个环节出现一点误差，误差在上下游经过几层累积后会造成什么影响谁都无法确定。
所以除了进行事先的容量规划，我们还需要建立起一套验证机制，来验证我们各个环节的准备都是符合预期的。验证的最佳方法就是让事件提前发生，如果我们的系统能够提前经历几次“双11”，容量的不确定性问题也就解决了。
2013年，对双11稳定性来说是一个大的里程碑，我们在生产环境采取模式双11的方式来全方位验证容量的确定性。也就是说，全链路压测的诞生解决了容量的确定性问题。2013年之后基于全链路压测为核心，打造了一系列容量规划相关的配套生态，提升能力的同时，降低整个环节的成本、提升效率。
事实上，提前对双11进行模拟听起来就不简单，毕竟双11的规模和复杂性都是空前的，要将双11提前模拟出来，难度可想而知，全链路压测的诞生主要攻克了下面4个大的挑战：
跟双11相关的业务系统上百个，并且牵涉到整条链路上所有的基础设施和中间件，确保在整个流程中压测流量能够通畅无阻。
压测的数据怎么构造（亿万级的商品和用户），数据模型与双11尽可能贴近。
全链路压测直接在线上的真实环境进行双11模拟，保障对线上的数据和业务没有影响。
双11是一个上亿用户参与的盛大活动，制造每秒几万次用户行为的超大规模流量平台。
每年双11前夕，全链路压测都要组织好几次，不断地通过压测发现问题进行迭代优化、全方位验证业务的稳定性，我们的系统也只有在经过了全链路压测的验证之后才有信心迎接双11 那天0点的到来。全链路压测将是双11、双12等大促备战最重要的核武器，并且随着业务的发展不断进化，持续发挥着不可替代的作用。
五、“全链路压测+隔离环境+弹性伸缩”的技术生态体系
全链路压测经过几年的发展，从一开始的单一压测平台，逐步演变成一套技术生态体系。
隔离环境、边压边弹、功能预演、商家端全链路压测等技术产品都开始成为全链路压测生态家族的重要成员，协力为保障好双11的稳定性发挥重要作用。
全链路压测体系演进
全链路压测除了在能力上的不断演进外，压测效率也在不断的提升，智能化的技术能力逐步切入到压测场景。
通过“root cause”自动定位压测中出现的问题，在压测过程中，进行变压边弹，把容量配比调节至最优，系统产出详细的压测报告，希望这一切都在没有人的情况下自动完成。
“尖兵计划“项目正在朝着这个目标不断迈进，并且已经取得了阶段性的进展，在2017年和2018年全链路的首次压测成功率大幅提升。之前可能要压很多次才能压测成功，通过“尖兵计划”进行无人的常态化隔离环境压测，提前发现80%的表层问题，大型压测的阻断率大幅下降。
除了在智能压测上的突破，全链路压测的身份也有了一个大的转变。压测平台从一个阿里内部的大促备战利器，通过产品化升级，输出到了阿里云PTS：https://www.aliyun.com/product/pts
成千上万的外部互联网企业可以站在阿里的肩膀上，通过PTS完成一次精准的容量压测，轻松具备跟阿里一样的容量规划能力。在这背后全链路压测也经历了一次大的技术演进。
内外一套：用一套核心压测技术底座同时支撑了内外部的两套压测体系，意味着大部分的工作都是可以复用的，极大降低了运维成本。
压测能力升级：除了具备每秒亿级别的请求流量输出，同时具备秒级的大流量和大数据调度能力，展现出让业界惊叹的压测能力。
开放：具备了更加开放的扩展性，在支撑了更大规模的外部用户群体的同时也更好支撑了阿里愈加丰富的经济体业务形态；
开源兼容：兼容主流开源生态，让已经配置的压测需求可以不做任何变化直接跑在压测平台上；
解决方案化：在整个压测的技术上下游，打造了录制器、数据工厂、指令集、诊断专家等技术模块，从单一压测平台演变成为整个容量规划的闭环解决方案。
未来，我们将全力为全球消费者、商家、合作伙伴带来完美的体验。十年牧码，一骑绝尘！