从我们的调度器中剥离出调度器
内容提要
Fly.io开发了一种新的调度器flyd，旨在提高处理大量小型应用的效率。flyd采用市场模型，快速匹配资源请求，减少任务的延迟。该系统通过分布式状态管理和简化的API，提升了应用部署的灵活性和响应速度。
延伸解读
从集中式调度到市场模型：flyd 的设计动机
Fly.io 的调度需求与主流编排器不同：它需要处理大量小型应用，且要求同步快速响应。Nomad 等基于集中式调度和异步共识的系统，在应对频繁变化的 Docker 镜像缓存和即时伸缩请求时显得迟缓。flyd 将调度视为市场交易，请求是出价，worker 是供应商，由 flaps 作为经纪商快速匹配，匹配失败则立即取消，避免了任务在“pending”状态中等待。这种设计牺牲了全局最优，换取了低延迟和可预测性。
每个 worker 都是自己的状态源：flyd 的分布式状态管理
flyd 不在集群中缓存全局资源视图，而是让每个 worker 维护本地的 boltdb 数据库，记录所有操作日志。状态机结构清晰，重启后能恢复。跨 worker 的全局视图通过 Corrosion 实现——一个基于 SWIM gossip 和 SQLite 的复制系统，而非共识协议。这种设计避免了 Raft 的复杂性和单点故障，但意味着调度决策基于可能过时的局部信息，适合对一致性要求不高的场景。
将复杂策略移出平台：flyctl 与客户端的角色
flyd 和 flaps 只负责基本的资源预留和启动，不处理崩溃恢复、多区域部署、回滚等策略。这些功能被移到 flyctl 等客户端。例如，部署时 flyctl 会在不同 worker 上预创建多个机器，仅启动一个，故障时由 fly-proxy 触发备用机器启动。这种“客户端编排”策略将策略逻辑与执行引擎解耦，使平台核心保持简单，但要求客户端承担更多责任，也增加了用户理解成本。
flyd 的局限与适用边界
flyd 的市场模型适合大量小型、无状态或状态可快速重建的应用，且对调度延迟敏感。但它不保证全局最优放置，可能造成资源碎片；依赖客户端处理故障转移和部署策略，增加了客户端复杂性；Corrosion 的最终一致性可能导致短暂的状态不一致。对于需要强一致性调度或复杂约束的大型应用，传统编排器可能更合适。Fly.io 自身也承认，flyd 是权衡后的选择，而非通用方案。
Q&A
flyd调度器的主要目标是什么？
flyd调度器旨在提高处理大量小型应用的效率。
flyd是如何减少任务延迟的？
flyd采用市场模型，快速匹配资源请求，从而减少任务的延迟。
flyd与传统调度器的主要区别是什么？
flyd的设计使得每个worker都是自己的状态源，避免了集中式调度的复杂性，而传统调度器通常依赖于集中式调度。
flyd如何提升应用部署的灵活性？
flyd通过分布式状态管理和简化的API，提升了应用部署的灵活性和响应速度。
flyd的调度过程是怎样的？
flyd的调度过程类似于市场交易，快速决策以满足资源请求。
flyd的状态管理是如何实现的？
flyd的每个worker保持自己的状态源，使用本地数据库记录当前状态，避免了集中式状态管理的复杂性。
