
一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
客户输入 cron 表达式。你 POST 到他们容器的 crontab。不需要做共享队列的公平调度,不需要强制最小间隔,不需要处理「为什么我的任务在周一高峰没跑」的工单。
一个真实的客户设置页面——调度由租户编辑,由他们的容器解析。
你的设置页渲染一个输入框。他们的租户容器暴露一个 Cron API。表单提交转发一次 POST。没有全局调度器、没有按租户过滤的逻辑、没有「全体客户最多 100 条任务」的硬上限。
// 表单提交把客户的表达式原样转发
POST https://acme-cron.hoody.com/users/root/entries
Content-Type: application/json
{
"schedule": "0 9 * * 1-5",
"command": "/jobs/sync_crm.sh",
"comment": "Sync Salesforce contacts",
"enabled": true
}HTTP/1.1 201 Created
Content-Type: application/json
{
"id": "sch_8a3f1c",
"schedule": "0 9 * * 1-5",
"next_run": "2026-05-04T09:00:00Z",
"enabled": true
}
// 调度现在只在这个租户的 crontab 里,别处都没有Hoody Cron 服务跑在每个租户容器内部,提供托管条目和按用户隔离。调度活在它要执行的位置。
调度紧挨着工作时,多租户调度的规则改变了。约束是本地的。影响半径是本地的。功能也是本地的。
没有要争抢的全局线程池。最难缠的租户每分钟跑一次也饿不到安静的租户——他们根本不在同一份 crontab 上。
你不再是「*/1 * * * * 在你这个档位允许吗」的看门人。他们的容器、他们的 cron、他们的 CPU 账单。你的工单收件箱清空了。
对租户容器做快照,crontab 也被快照。回滚、恢复、fork——调度一起带走。不需要外部调度器状态去同步。
差别体现在三个地方:客户体验、你的工单负担、工程面积。
共享调度器版的这个功能是一片注意事项的海洋。BYO 版只是一个 5 字段输入框。
停止运营全局队列那天起会变化的三个数字。每一个都对应一类你不再需要写或运维的功能。
不再有按档位的最小间隔、按租户的最大任务数、公平调度旋钮。容器就是上限。
客户输入,你转发,容器解析。设置页提交是单次 REST 调用,不是编排。
分钟 · 小时 · 日 · 月 · 周几。再加宏(@hourly、@daily)。标准 POSIX,不是你的 DSL。
数字反映 BYO 容器绑定模型——实际 cron 条目随每个容器的 CPU 与客户套餐扩展。
客户的 cron 表达式归客户,不需要你对照全局队列去校验。
BYO 容器绑定 cron 悄悄淘汰的基础设施。
别再当别人调度的看门人。把 cron 字段交给他们,把工作交给他们的容器。