管理成千上万台服务器上的定时任务，一直是运维团队的痛点——脚本散落各处、执行结果难以回收、任务之间缺乏编排。Jiascheduler 用 Rust 从头解决这些问题：一个控制台把命令推到万个节点，结果实时收回来。拖了半年的 2.0.0 版本终于发布，最大的变化是加入了 Workflow，让多步骤任务可以串起来跑。
为什么用 Rust 写调度器
任务调度系统的瓶颈不在单次执行的耗时，而在并发吞吐——当你同时向 5000 台节点推送一条命令，控制端要扛住 5000 个并发连接、5000 条结果回传，还要在超时和断连中做容错。Rust 的零成本抽象和所有权模型在这里很合适：
- 内存安全无 GC 停顿：长时间运行的调度服务不会因为垃圾回收卡住关键路径。
- 轻量线程（async runtime）：tokio 或类似异步运行时可以同时维护大量连接，不靠操作系统线程堆内存。
- 编译期防竞态：
Send/Sync标记让多线程数据共享的错误在编译阶段暴露，而不是在凌晨三点的生产环境里崩溃。
对调度器这种"跑起来就不能停"的基础设施，这些特性不是锦上添花，是刚需。
核心能力：中央推送 + 实时回收
Jiascheduler 的架构很直接：
| 角色 | 职责 |
|---|---|
| Server | 中央调度引擎，接收任务定义，分发到目标节点 |
| Agent | 部署在每个目标节点，接收命令、本地执行、回传结果 |
| Console | Web 控制台，可视化管理任务、节点、结果 |
一个典型场景：你写了一条 Shell 命令检查磁盘使用率，在 Console 里选中 3000 台节点，点击执行。Server 把命令推给 3000 个 Agent，Agent 在本地跑完把 stdout/stderr 和退出码回传，Console 实时展示进度和结果。不需要 SSH 轮巡，不需要 Ansible 扫一遍。
2.0.0 的新主角：Workflow
单任务调度解决的是"在什么时候、哪些机器上跑什么命令"。但真实运维流程往往是多步骤的：
- 先在所有 Web 节点拉出服务注册
- 等注册全部完成后，执行版本更新脚本
- 更新成功后，逐批健康检查
- 全部通过后，重新注册服务
以前这些步骤要拆成多个独立任务，靠人盯进度手动触发下一步。Workflow 让你把它们定义成一个有向图，节点之间可以设依赖关系和条件分支——上游成功才跑下游，失败则走另一条路径。
这是 2.0.0 拖了半年的主要原因：Workflow 的状态机、依赖解析、失败重试策略、部分节点失败时的全局决策，每一层都有边界情况要处理。个人开发者在这个规模的功能上磨半年，不算慢。
实战：从安装到跑一个 Workflow
下面用一个最小示例演示 Jiascheduler 的使用流程。假设你有 3 台目标节点，想跑一个两步 Workflow：先检查磁盘，磁盘正常才执行日志清理。
1. 部署 Server 和 Console
# 从 GitHub Releases 下载最新 2.0.0 二进制
# https://github.com/jiascheduler/jiascheduler/releases
wget https://github.com/jiascheduler/jiascheduler/releases/download/v2.0.0/jiascheduler-server-2.0.0-linux-amd64.tar.gz
tar xzf jiascheduler-server-2.0.0-linux-amd64.tar.gz
# 启动 Server（默认监听 8080 端口，Console 嵌在同一进程）
./jiascheduler-server --config server.toml
server.toml 最小配置：
[server]
bind = "0.0.0.0:8080"
data_dir = "/var/lib/jiascheduler"
[database]
# 内嵌 SQLite，零依赖启动；生产环境可换 PostgreSQL
driver = "sqlite"
dsn = "/var/lib/jiascheduler/db.sqlite"
2. 在目标节点部署 Agent
wget https://github.com/jiascheduler/jiascheduler/releases/download/v2.0.0/jiascheduler-agent-2.0.0-linux-amd64.tar.gz
tar xzf jiascheduler-agent-2.0.0-linux-amd64.tar.gz
# Agent 连接到 Server，注册本节点
./jiascheduler-agent --server-addr "10.0.0.1:8080" --node-name "web-node-1"
在 3 台节点上重复执行，Console 里很快就能看到 3 个在线节点。
3. 定义 Workflow
在 Console 的 Web 界面可以可视化编排，也可以用 YAML 定义后导入。以下是两步 Workflow 的 YAML：
name: disk-check-then-cleanup
version: "2.0"
steps:
- id: check_disk
command: "df -h / | awk 'NR==2{print $5}' | tr -d '%'"
targets: "web-node-1,web-node-2,web-node-3"
# 期望输出：磁盘使用率数字，如 45
output_as: disk_usage_percent
- id: cleanup_logs
command: "find /var/log -name '*.log' -mtime +7 -delete"
targets: "web-node-1,web-node-2,web-node-3"
depends_on: [check_disk]
# 条件：只有上游所有节点的磁盘使用率 < 80 才执行
condition: "all(step.check_disk.result < 80)"
on_failure: "skip" # 条件不满足时跳过而非失败
导入方式：
# 通过 Console API 导入 Workflow 定义
curl -X POST http://10.0.0.1:8080/api/v2/workflows \
-H "Content-Type: application/yaml" \
--data-binary @disk-check-then-cleanup.yaml
4. 触发执行并查看结果
# 手动触发一次 Workflow 运行
curl -X POST http://10.0.0.1:8080/api/v2/workflows/disk-check-then-cleanup/run
# 查询运行状态
curl http://10.0.0.1:8080/api/v2/workflows/disk-check-then-cleanup/runs/latest
也可以在 Console 界面直接点击"执行"，实时观察每个步骤在每台节点上的输出。如果 check_disk 某台节点返回 85%，那台节点会被标记为条件不满足，cleanup_logs 在该节点上自动跳过——其他正常节点继续执行。
注意：以上 YAML schema 和 API 路径基于 Jiascheduler 2.0.0 的设计思路编写，具体字段名和接口格式请以项目官方文档为准，正式使用前建议对照 GitHub 仓库 的 README 和 examples 目录确认。
选用建议与边界
Jiascheduler 适合的场景很明确：
- 大规模节点命令推送：几百到上万台，需要集中管理和结果回收。
- 运维编排：发布、巡检、故障恢复等多步骤流程，用 Workflow 串起来。
- 轻量部署偏好：不想引入 Ansible 的 YAML 丛林或 Kubernetes CronJob 的集群依赖，一个二进制加一个 Agent 就能跑。
但它也有边界要认清：
- 不是 CI/CD 工具：它调度的是节点上的命令，不是代码构建流水线。复杂构建流程还是 Jenkins / GitHub Actions 更合适。
- Workflow 刚上线：2.0.0 的 Workflow 是第一个正式版本，条件表达式、子流程嵌套、超时策略等细节可能还在迭代，生产使用前要在小规模环境充分验证。
- 个人项目节奏：一个开发者维护的调度器，响应速度和功能路线不可能和商业产品比。如果你需要 SLA 保障和 7×24 支持，要考虑社区规模是否够用。
上手清单
- 在一台测试机上部署 Server + Console，SQLite 模式零依赖启动。
- 在 2-3 台虚拟机上装 Agent，跑一个单命令任务验证推送和回收。
- 写一个两步 Workflow YAML，测试依赖和条件分支。
- 模拟一台节点失败（Agent 断连或命令返回非零退出码），观察 Workflow 的容错行为。
- 确认满足需求后，逐步扩大节点规模，切换到 PostgreSQL 后端。
Jiascheduler 2.0.0 把"万人节点推送"和"多步编排"合到了一个 Rust 二进制里，部署成本极低。如果你正被散落的 Cron 和手动接力折磨，值得花一个下午试一下。