仅仅为了满足业务突发需求而储备大量的资源，成本太高，会造成资源极大的浪费。所以一般会通过复用资源来应对业务突发。但是直接复用资源，存在两个问题：

a) 只能复用部分资源：CDN业务，一般按业务类型来区分平台和资源使用，主要原因是不同业务类型对资源需求不同，比如点播类需要更多的存储；有较多https请求的静态页面类，则需要更多CPU资源。这种限制使得资源无法充分利用，加大了资源准备的难度。比如视频突发主要使用视频Buffer，而下载类和网页类Buffer无法直接使用，这限制了Buffer的大小。即使复用同类型资源，因为涉及多个业务资源的协调，准备时间一般会超过两天，无法应对临时突发；

b) 无法降低成本：另外针对部分突发业务，比如游戏应用下载，带宽高峰期在上午和中午，如果只使用本平台资源，会导致结算带宽明显上涨，从而增加成本。无法利用同其他业务错峰的特点来降低结算带宽。

二、解决方案

1、 突发池系统架构

虚拟机和物理机部署了上报Agent，业务信息和服务器负载每分钟都会上报到监控系统。监控系统会根据历史带宽预测一个值，并与当前带宽比较，如果当前带宽超过预测值的50%，则认为有突发。根据带宽上涨的比例，系统会自动从突发池中扩容相应数据的设备。针对提前准备的突发活动，运维可以指定带宽需求量，之后系统便会自动计算设备需求并扩容。

2、技术优化

使用虚拟化技术复用资源的重要前提是，不影响现有业务。这就要求对资源有充分的隔离，比如CPU／磁盘，以及对带宽的使用。下面是实现过程中存在的几个问题及解决方案：

精准控制单机负载：负载过高会影响业务质量，需要对单机负载进行精准的控制。

解决方案：

a) 配额系统：直通车中有配额系统，对每个虚拟机可使用的资源做了限制，包括CPU／IO和带宽。监控系统中上报的信息，结合配额系统，可以确保服务器负载被限定在制定的范围内，粒度为分钟级。

b) 部分请求返回302：对CPU／带宽／IO等做了限制后，应用程序能根据母机当前负载，实时判断是否处理一个请求。如果负载在限制范围内，直接处理；如果负载超出限制，则返回302，使用户跳转到直通车的调度地址，这样能在尽量不影响业务质量的情况对负载做精准控制。程序层面对负载的实时控制，是配额系统的有效补充。

c) 网卡流量控制：在极端情况下，业务带宽超过设定阈值，这时虚拟网卡会主动丢包，避免对母机造成影响。