提前对双11进行模拟听起来就不简单，毕竟双11的规模和复杂性都是空前的，要将双11提前模拟出来，难度可想而知：
阿里巴巴有着非常丰富的业务形态，每种业务都由一系列不同的业务系统来提供服务，每个业务系统都分布式地部署在不同的机器上。
随着业务的发展，特别是在大促营销等活动场景下（比如双11），需要为每个业务系统准备多少机器对于阿里巴巴技术团队来说是一大难题。
“容量规划”正是为解决这个难题而诞生，容量规划的目的在于让每一个业务系统能够清晰地知道：什么时候应该加机器、什么时候应该减机器？
双11等大促场景需要准备多少机器，既能保障系统稳定性、又能节约成本？
系统容量评估阶段：初步计算每一个系统需要分配多少机器；
容量的精调阶段：通过全链路压测来模拟大促时刻的用户行为，在验证站点能力的同时对整个站点的容量水位进行精细调整；
流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务。
在第一个阶段当中，通过合适的预测算法和丰富的历史数据，通常能够比较准确地预估业务的访问量。
即使在第一阶段预估的业务访问量跟实际的存在误差，通过第四阶段的流量控制也能够确保站点始终处于良好的服务状态。
做完业务访问量的预估之后，容量规划进入第二阶段，为系统进行容量的初步评估。如何通过精准的容量评估，用最小的成本来支撑好预估的业务量是这个阶段的核心问题。
要计算一个系统需要多少台机器，除了需要知道未来的业务调用量之外，还有一个更重要的变量，就是单台机器的服务能力。
获取单台机器的服务能力在阿里巴巴是通过单机压测的方式来获取。在阿里巴巴，为了精准地获取到单台机器的服务能力，压力测试都是直接在生产环境进行，
这有两个非常重要的原因：单机压测既需要保证环境的真实性，又要保证流量的真实性。否则获取到的单台机器服务能力值将会有比较大的误差，影响到整个容量规划的准确性。
模拟请求：通过对生产环境的一台机器发起模拟请求调用来达到压力测试的目的
复制请求：通过将一台机器的请求复制多份发送到指定的压测机器
请求转发：将分布式环境中多台机器的请求转发到一台机器上
对于系统调用量比较大的场景，我们有更好的处理办法。其中的一种做法我们称为请求的引流转发，阿里巴巴的系统基本上都是分布式的，通过将多台机器的请求转发到一台机器上，让一台机器承受更大的流量，从而达到压力测试的目的。请求的引流转发方式不仅压测结果非常精准、不会产生脏数据、而且操作起来也非常方便快捷，在阿里巴巴也是用的非常广泛的一种单机压测方式。当然，这种压测方式也有一个前提条件就是系统的调用量需要足够大，如果系统的调用量非常小，即使把所有的流量都引到一台机器，还是无法压测到瓶颈。
调整负载均衡：修改负载均衡设备的权重，让压测的机器分配更多的请求
与请求引流转发的方式类似，最后一种压测方式同样是让分布式环境下的某一台机器分配更多的请求。不同的地方在于采用的方式是通过去调整负载均衡设备的权重。调整负载均衡方式活的的压测结果非常准确、并且不会产生脏数据。前提条件也需要分布式系统的调用量足够大。
因为是在生产环境进行压测，我们必须非常小心，保障压测过程不影响到正常的业务。在单机压测平台上，每个月将进行5000次以上的压测，系统发布或者大的变更都将通过单机压测来验证性能是否有变化，通过单机压测获取的单机服务能力值也是容量规划一个非常重要的参考依据。
有了预估的业务访问量，也知道了系统单台机器的服务能力，粗略的要计算需要多少台机器就非常简单了。
最小机器数＝预估的业务访问量／单机能力。
通常情况下，我们会预留少量的buffer来防止评估的误差和意外情况。