在以往菜鸟整体资源使用率都处于一个比较低的水平，其原因有以下两点：在线应用一般是通过单机性能压测，并且结合经验预估业务流量的方式来确定所需容器数量。这种方式很大程度上会受到评估者主观因素的干扰，在估算业务流量时也通常会保留较大的冗余。 还有就是以往的模式下，一个应用分组的扩缩容操作频率很低，这使估算业务流量时，需要以每天的峰值流量以及未来一段时间（通常以月为单位）内业务的发展情况来作为评估标准。而一般峰值流量出现时段可能只占全天时间的一小部分，非峰值时段就出现大量的资源浪费。
之后菜鸟便引入了菜鸟方舟，菜鸟方舟是面向菜鸟所有研发的资源管理和运维平台，负责对菜鸟的基础设施资源进行管控，以支撑日常和大促的资源需求。弹性调度是菜鸟方舟的一个重要组成部分，也是方舟的一个重要的功能特性。通过弹性调度，能够使应用在业务压力上升时及时扩充资源，而在业务压力下降时对资源进行释放，从而实现在保证稳定性的前提下尽可能地提升资源使用效率。在未来引入离线任务进行混部，或者细粒度资源计价方式后，这种模式将会大幅度降低菜鸟整体IT成本。
不仅如此，菜鸟弹性调度所期望覆盖的应用范围是菜鸟所有的无状态核心应用，这些核心应用所涉及的业务链路、逻辑特性、资源倾向性、业务流量特性等都存在非常大的差异性，很难抽象出一种通用的业务模式来描述这些应用。因此，不同于针对某个特定的业务域的弹性调度，菜鸟弹性调度在进行设计时不能进行过多的业务假设，在设计调度算法和策略模式时必须考虑到足够的通用性；在配置上需要给予使用者充分的个性化能力以应对不同的业务场景；在系统结构设计时，需要考虑到策略横向扩展能力，当有新的特殊业务场景出现时，能够进行快速线性扩展。
截止到目前为止，菜鸟已经基本实现了对容器数量15台以上（接入前）的无状态应用分组进行弹性接入，接入应用分组的整体全天CPU平均使用率达到20%以上（计算方法为取分组CPU使用率与分组容器数的加权平均值）。每天扩缩容总容器数在3000台以上。在2017年双十一时，弹性调度作为辅助手段从11月12日0点起对部分应用分组进行缩容，使菜鸟占用物理CPU核数与包裹数的比例得到显著下降。
在阅读了菜鸟方舟的弹性调度的架构设计之后，我们可以看出，菜鸟通过弹性调度解决了菜鸟整体资源使用率较低的问题，而该弹性调度之所以能在菜鸟站稳脚跟，在我看来其根本原因是菜鸟采用决定系统是协调商家的业务特点以及其完成了资源管理从“面向机器”到“面向应用”的转变，这些都为弹性调度的落地创造了充分的技术基础。 但是方舟的弹性调度还处于一个发展成长的过程中，对于一些应用的调度效果还要进行进一步的提升。
文章来源：
https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=1&ch=1&tn=25017023_7_dg&wd=%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E7%9A%84%E5%BC%B9%E6%80%A7%E8%B0%83%E5%BA%A6&oq=%25E5%25BC%25B9%25E6%2580%25A7%25E8%25B0%2583%25E5%25BA%25A6&rsv_pq=ee37e1540008748a&rsv_t=bc44Psn04RJOVJ8HAm2YZiYr1mq6ROEa7lBoANNzdFGYKygAMq3bz8mgAk9Ueb1qN9sHlw&rqlang=cn&rsv_enter=1&inputT=7471&rsv_sug3=67&rsv_sug1=10&rsv_sug7=100&rsv_sug2=0&rsv_sug4=7984