跳转到内容
类型解锁
阶段船队
难度高级
工作多租户 SaaS
用于开发团队
用于后端开发者
服务Cron
服务容器
为何选 Hoody容器经济学
为何选 HoodyHTTP 原生
行业SaaS
类型解锁
阶段船队
难度高级
工作多租户 SaaS
用于开发团队
用于后端开发者
服务Cron
服务容器
为何选 Hoody容器经济学
为何选 HoodyHTTP 原生
行业SaaS
类型解锁
阶段船队
难度高级
工作多租户 SaaS
用于开发团队
用于后端开发者
服务Cron
服务容器
为何选 Hoody容器经济学
为何选 HoodyHTTP 原生
行业SaaS
类型解锁
阶段船队
难度高级
工作多租户 SaaS
用于开发团队
用于后端开发者
服务Cron
服务容器
为何选 Hoody容器经济学
为何选 HoodyHTTP 原生
行业SaaS
BYO cron / 每租户调度

让客户自带自己的 cron 调度。

客户输入 cron 表达式。你 POST 到他们容器的 crontab。不需要做共享队列的公平调度,不需要强制最小间隔,不需要处理「为什么我的任务在周一高峰没跑」的工单。

阅读 Cron API 文档

客户在你的 UI 里输入。你 POST 到他们的容器。

你的设置页渲染一个输入框。他们的租户容器暴露一个 Cron API。表单提交转发一次 POST。没有全局调度器、没有按租户过滤的逻辑、没有「全体客户最多 100 条任务」的硬上限。

你的后端 → 租户容器
POST /users/root/entries
// 表单提交把客户的表达式原样转发
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
}
租户容器 → 你的后端
201 Created
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 服务跑在每个租户容器内部,提供托管条目和按用户隔离。调度活在它要执行的位置。

BYO cron 给你共享调度器给不了的东西。

调度紧挨着工作时,多租户调度的规则改变了。约束是本地的。影响半径是本地的。功能也是本地的。

无共享队列

没有公平排队的开销

没有要争抢的全局线程池。最难缠的租户每分钟跑一次也饿不到安静的租户——他们根本不在同一份 crontab 上。

自助

客户自助,你不做校验

你不再是「*/1 * * * * 在你这个档位允许吗」的看门人。他们的容器、他们的 cron、他们的 CPU 账单。你的工单收件箱清空了。

随容器走

调度跟着租户一起发货

对租户容器做快照,crontab 也被快照。回滚、恢复、fork——调度一起带走。不需要外部调度器状态去同步。

共享多租户调度器 vs 容器绑定 cron。

差别体现在三个地方:客户体验、你的工单负担、工程面积。

维度共享调度器BYO 容器 cron
客户能选什么
最少 5 分钟、仅工作日、不能并发按档位限流、公平规则、高峰延后
他们容器扛得住的任何 5 字段 cron 表达式想 */1 * * * * 就 */1 * * * *;他们的 CPU 自己付账
校验在哪里发生
你的代码,在持久化前对全局队列模型校验正则 + 容量检查 + 档位检查 + 重叠检查
容器里的 cron 守护进程解析表达式只校验语法;容量是单个容器的,不是整支舰队的
故障影响半径
一个租户的慢任务把队列堵给所有人嘈杂邻居事故,按队列深度告警
一个容器的 cron 只拖累一个租户内核级隔离;舰队的其他部分毫无察觉

共享调度器版的这个功能是一片注意事项的海洋。BYO 版只是一个 5 字段输入框。

cron 变成每租户后消失的东西。

停止运营全局队列那天起会变化的三个数字。每一个都对应一类你不再需要写或运维的功能。

  1. 需要维护的校验规则0

    不再有按档位的最小间隔、按租户的最大任务数、公平调度旋钮。容器就是上限。

  2. 每次创建一个调度只 POST 一次

    客户输入,你转发,容器解析。设置页提交是单次 REST 调用,不是编排。

  3. 客户拥有的字段5

    分钟 · 小时 · 日 · 月 · 周几。再加宏(@hourly、@daily)。标准 POSIX,不是你的 DSL。

数字反映 BYO 容器绑定模型——实际 cron 条目随每个容器的 CPU 与客户套餐扩展。

客户的 cron 表达式归客户,不需要你对照全局队列去校验。

共享调度器BYO 每租户 cron
之前if (tier !== 'enterprise' && interval < 5min) reject()校验税:每个客户都为最差的客户买单
之后POST /users/root/entries → 201 Created调度活在他们的容器里;他们的 CPU、他们的规则
查看 Cron API

它替代了什么。

BYO 容器绑定 cron 悄悄淘汰的基础设施。

  • 共享多租户调度器没有可公平调度的全局队列
  • 带租户过滤的 Quartz每行任务上不再有 tenant_id 列
  • 自建的 cron-as-config UI客户输入,容器解析
  • 厂商托管的 Airflow为一个 5 字段表达式不用上 DAG 服务
  • 带限流的共享 Sidekiq不再有跨租户的全局速率限制
  • 带租户队列的 BullMQ不必为每位客户照看一份 Redis

别再当别人调度的看门人。把 cron 字段交给他们,把工作交给他们的容器。

阅读文档

阅读其他内容