这是一个创建于 144 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景：手里的项目是 Django 项目，定时任务是用的 Celery 库来集成到 Django 中，随着定时任务的增多，变得不太好管理（可视化监控、异常重试、报警等），并且有些定时任务并非使用 Python 编写，无法集成到 Celery 中，因此想用专门的定时任务管理的系统来解决这个问题。
思路：部署一套 Airflow 系统，然后 Django 项目（或者其他编程语言的项目）打包为 Docker 镜像，每次定时任务运行 docker run --rm ... 来启动一个容器，并在运行完成后删掉。
请教大家这个方式有没有什么坑？有没有过来人说一下？
回帖后必回感谢红心，谢谢 ！
思路：部署一套 Airflow 系统，然后 Django 项目（或者其他编程语言的项目）打包为 Docker 镜像，每次定时任务运行 docker run --rm ... 来启动一个容器，并在运行完成后删掉。
请教大家这个方式有没有什么坑？有没有过来人说一下？
回帖后必回感谢红心，谢谢 ！
14 条回复 • 2024-07-08 22:29:23 +08:00
 |
1
PeiXyJ 144 天前  1
直接用 XXL-job 做定时任务管理不行么? 为什么还要引入 Docker ？
|
 |
2
David1119 144 天前 1
airflow 挺好的，就是不太轻量，感觉有些占资源。还有个 perfect 可以看看，没具体用过，可以都搭一下对比对比。https://github.com/PrefectHQ/prefect
|
 |
3
ddkk1112 144 天前 1
airflow 挺好的，但是稍微有点重
重要一点，airflow 用 postgres 做管理数据库，mysql 会不定时崩溃 |
 |
4
lvhuiyang OP @PeiXyJ 感谢回复，引入 Docker 是为了方便运行不同语言环境的项目，这些项目本身是 Docker 部署的，有对应的 image 管理，所以相对比较方便。
|
 |
8
Or13rs 144 天前 1
我们生产上用了五年了，目前规模到大概是每天一万多个任务，我觉得 airflow 作为比较早的方案，随着规模的扩大，会越来越难维护，很重。
现在遇到的困境大概就是日志和告警， 日志方面，可能因为我们是早期版本，airflow 的日志会占用大量 inode ， 然后是告警，因为 airflow 的核心设计，导致状态转移会因为一些重启、重试、失败难以监控，直接导致通过获取日志监控失败，通过扫 airflow 的 instance 表状态转移也不容易监控，除非提高扫描频率，但是会增加数据库压力，可能 binlog 才是唯一的出了（摊手） 最后看你们使用的重不重， 如果不重，独立一个 celery 服务会是一个很好的方案， 如果要管理方便 perfect 和 dagster 会很好， 另外还有些更轻量级的新奇方案 https://github.com/faust-streaming/mode |
|
9
lvhuiyang OP @Or13rs 感谢回复，很宝贵的经验。 我目前管理的项目规模还不大，觉得上面提到的 Airflow 的问题也还可以接受，总之很感谢分享这些经验，我再调研一下
|
 |
10
kratosmy 143 天前 via iPhone 1
@Or13rs 我们会在 openshift 上用 airflow 的 kubenetesexecutor 跑各个 batch job ，会有什么坑吗
|
 |
11
Philippa 143 天前 1
Airflow 毛病实在太多了，6 年前一个项目用了，除了重量级，一些 bugs 连 Airbnb 自身都无法解决。
Python 代码无法序列化，需要提前打包成 image 进行运行。现在很多已经可以直接序列化代码发送到各个机器运行，比如 Ray ，这种实验性有需要高性能的代码就非常贴切。 状态管理以来本身的 databases ，但这个表设计和 API 又是它们自己定的，无法优化用起来也要迁就。 反应很慢，而且界面也不友好，它的关系依然需要手动定义，所以没有降低复杂度，只是有一个可视化。 如果是单纯的 Python ，我优先考虑 Ray 。Ray 和 Airflow 一样，都有 kubernetes 的 operators ，容器方面交给 k8s 就可以了。 如果是多种语言只是需要一个外层的调度框架，我会优先考虑 Go 生态的。甚至其实自己写也没差，因为可以自己 100% 控制。 |
Select Language