设备申请分层调度：优先复用离线集群、低负载集群、错峰空闲的存量资源

弹性扩容任务的第一步是”设备从哪里来”，微博DCP的做法延续了[[用银行储蓄机制类比混合云资源共享池的核心设计思想]]的思路，优先从内部已有的、暂时没被充分使用的资源里找，而不是第一时间就去申请全新资源或调用外部公有云。具体来说，可用的存量资源来自三类：离线集群——离线计算任务本身不是任何时刻都在满负荷运算，即使临时减少分配给它的计算资源，通常也不会对业务造成重大影响；低负载集群——如果某个业务当前处于负载较低的时段，它多余的资源同样可以被临时调度出去支援别的业务；错峰空闲的设备——因为微博内部有上百条业务线，各自的流量高峰时间点天然错开（有的业务高峰在晚上、有的在中午），这种时间错位本身就意味着任意时刻总有一部分设备处于相对空闲状态，可以被临时调剂支援给当下真正处于高峰的业务。只有当这些内部存量资源（先看集群自己的Buffer池，再看跨集群配额是否允许）都不足以满足需求时，才会真正触发向外部申请新设备。这个分层调度顺序体现了一条成本控制的通用原则：应对资源需求波动时，永远优先审视”内部有没有已经存在但暂时闲置的资源可以复用”，只有确认存量资源确实无法满足需求，才升级到”申请全新资源”这个成本更高、响应更慢的路径——这个”先复用、后新增”的优先级顺序，本质上是把[[用银行储蓄机制类比混合云资源共享池的核心设计思想]]里”资源池化提升利用率”这个抽象原则，落实成了扩容流程里一条具体、可执行的调度规则。