容器调度的三级分层结构与两步调度算法：先过滤再打分

微博的容器调度体系在组织结构上分为三级：应用（Application）之下有多个应用池（Pool），应用池可以按机房、用途等维度来划分（比如同一个应用在不同机房各设一个池、或者按用途分成生产池和测试池）；每个应用池下面又包含多个Docker容器形式的应用实例——这个三级结构的价值在于把”这个应用整体该怎么部署”和”具体某个实例调度到哪台机器”这两个不同粒度的问题分开管理，应用池这一层承担了按机房/用途做隔离和分组的职责，调度算法真正要解决的问题被收窄到”给某个应用池的某个实例找一台合适的宿主机”。基于Swarm的Filter机制，具体的调度过程分两步：第一步是主机过滤，根据业务指定的条件（机房、内存、CPU、端口等硬性要求）对所有候选主机做一轮筛选，只留下满足这些基本约束的主机集合；第二步是策略选择，对通过第一步筛选后的主机集合做打分，从中选出得分最合适的一台，真正在其上创建容器完成部署。这个”先硬性过滤、再打分择优”的两阶段设计，是资源调度类问题里一个常见且有效的模式：把调度决策拆成”哪些候选是合法可用的”（过滤，处理的是约束满足问题）和”合法候选里哪个是最优的”（打分，处理的是优化问题）两个独立步骤，分开处理能让每一步的逻辑都更简单、更容易验证正确性，而不是试图用一个单一的复杂函数同时兼顾”是否可行”和”是否最优”两件事。

结构图：

flowchart TB
    subgraph 组织结构["三级组织结构"]
        A["应用(Application)"] --> B["应用池(Pool)\n按机房/用途划分"]
        B --> C["应用实例(Docker容器)"]
    end
    subgraph 调度算法["两步调度算法(Swarm Filter)"]
        D["候选主机全集"] --> E["第一步：主机过滤\n(机房/内存/CPU/端口等硬性约束)"]
        E --> F["满足约束的主机集合"]
        F --> G["第二步：策略选择\n(对主机集合打分)"]
        G --> H["选出最优主机\n创建容器部署"]
    end
    组织结构 -.->|"为某个应用池的实例\n寻找部署位置"| 调度算法