链载Ai

标题: 如何管理和调度Dify工作流？ [打印本页]
作者: 链载Ai    时间: 2 小时前
标题: 如何管理和调度Dify工作流？

概述

dify[1]是一款开源的大模型应用开发平台，可以通过可视化的画布拖拖拽拽快速构建AI Agent/工作流。Agent通常指能够自主决策、动态响应的智能体，比如聊天机器人、自动化客服等。工作流适合结构化、步骤明确、对输出内容和格式要求非常严谨的场景。 Dify工作流有许多场景，需要用到定时调度，比如：

本篇文章将介绍如何通过任务调度系统调度Dify工作流，通过任务调度系统调度LangChain脚本请看《LangChain脚本如何调度及提效？》。

开源Dify的痛点

无定时调度和监控报警

Dify专注于做大模型应用的开发和运行平台，不支持工作流的定时调度和监控报警。

执行记录过多导致性能差

Dify工作流每次执行，会把执行记录存储在数据库的 workflow_node_executions, workflow_runs 等表，永远不会清理，会导致表数据越堆越多，影响性能。该问题社区也提了很多的 Issues，但是社区没有计划去修复该问题，比如：

1. Issue#9747[2]: Ability to control logs.
2. Issue#12991[3]：Database Size Growth Issue: Workflow Execution Logs and Retention Policy

解决方案

官方推荐使用任务调度系统托管和调度Dify工作流[4]，做定时调度和状态监控。针对Dify侧数据库表数据过多的问题，社区没有计划做自动清理的能力，可以让运维隔断时间手动清理下该表，然后统一在任务调度系统上看执行记录。

Dify Schedule集成Dify工作流

Dify Schedule[5]是一个使用github actions[6]做Dify工作流定时调度的项目，主要包括的功能如下：

接入步骤

1. Fork 仓库到自己的github账户中。
2. 在.github/workflows下，配置定时任务，每个Dify工作流需要对应一个yml文件
3. 配置Dify工作流信息。进入Fork代码仓库，依次点击 Settings->Secrets and variables->Actions->New repository secret，添加如下密钥：
4. 配置定时任务的通知配置
5. 前往github actions页面，查看调度记录，也可以手动运行
6. 在Dify工作流控制台，工作流的日志页面，可以看到dify-schedule触发的记录

方案限制

只能调度公网Dify

通过github actions 调度Dify工作流，需要DIFY_BASE_URL这个配置成公网域名，如果是私网部署的Dify，github无法调度，网络不通。

调度延时大

Github actions的schedule能力比较弱，就算把cron表达式配置成* * * * *，也无法做到每分钟调度一次，官方文档[7]描述最小调度频率是5分钟。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;background-color: rgb(255, 255, 255);">
You can schedule a workflow to run at specific UTC times usingPOSIX cron syntax. Scheduled workflows run on the latest commit on the default or base branch. The shortest interval you can run scheduled workflows is once every 5 minutes.

经过实际测试下来，可能是github调度资源有限，就算把cron表达式配置成"*/5 * * * *"，也无法保证5分钟一次，调度经常会延迟十几分钟甚至好几十分钟，如果想要精确的做Dify工作流定时调度，该方案不是很合适。比如配置每5分钟调度一次，实际调度情况如下图：

配置复杂

每增加一个Dify工作流，就得配置一个github actions workflow文件，针对每个Dify工作流，还得新增 DIFY_TOKENS、DIFY_INPUTS等Secrets配置，开发维护成本比较高。

无失败报警

失败报警是定时任务系统的基本诉求，如果Dify工作流运行失败了，需要及时通知到业务方，否则容易产生故障。该方案的消息通知，是任务执行成功失败都通知，没法配置只通知失败的任务。

XXL-JOB集成Dify工作流

XXL-JOB[8]是开源非常流行的任务调度系统，简单易用，并且功能丰富。可以做到秒级别调度，提供任务的报警监控、手动运维、监控大盘等能力。

阿里云XXL-JOB版完全兼容开源，支持调度公网的Dify集群，也支持调度阿里云内网的Dify集群，下面以调度阿里云内网Dify详细介绍。

接入步骤

1. 在阿里云上自建Dify集群，比如通过容器服务一键部署Dify[9]，并通过模版新建工作流，如下创建了一个有迭代器的工作流：
2. 在MSE中新建XXL-JOB集群[10]（限时免费试用一个月），vpc网络需要和Dify集群保持一致。
3. 进入XXL-JOB集群中，先创建应用，再创建任务，任务类型选择“Dify工作流”
{"input_text":"whatisyourname"}
4. 测试运行，可以通过任务管理->运行一次，进行测试。

方案优势

秒级别调度

该方案支持多种定时调度，包括cron、fixed_rate、fixed_delay，能精确到秒级别调度。同时还支持时区、自定义日历等定时配置。

安全防护

限流控制

有一堆Dify工作流，每天运行一次或者每小时运行一次，如果把定时时间设置同一时刻，会导致调用大模型的时候触发token限流，任务执行失败。

XXL-JOB自带任务失败自动重试功能，虽然通过不断重试最终可以解决该问题，但是限流过程中一直重试会加重token限流，资源利用率不高，重复重试还会导致浪费token消耗，增加成本。所以针对该场景，推荐使用限流方案：

如上图所示，任务调度XXL-JOB版支持应用级别的限流控制：

1. 每个应用会有2个队列，一个是优先级排队队列，可以把任务按照优先级在队列中排队，保证核心任务优先跑完。任务的优先级仅在自己的应用下生效，不会和其他应用产生冲突。
2. 另一个是并发数队列，控制这个应用的并发数，不同应用的并发数彼此不受干扰。
3. 当并发队列中某个任务运行完成，有空闲槽位后，会从排队队列头部取出任务，放到并发队列中，开始执行任务。

企业级报警

任务调度XXL-JOB版集成阿里云监控，提供企业级报警服务：

丰富的可观测

调度大盘

调度大盘通过曲线的形式展示整体调度情况，包括执行成功和执行失败，支持应用、时间区间的过滤：

执行记录

执行记录通过列表的形式展示了每次执行的基本详情，包括Dify工作流执行的状态、耗时和tokens消耗，支持多种条件过滤查询：

工作流详情

在执行记录列表中，点详情，可以看到整个Dify工作流这次运行的详情。

节点追踪

任务开始执行，MSE-XXLJOB通过streaming模式，就可以实时拿到该工作流所有节点的执行情况，如果节点是迭代器和循环分支，还能支持节点下钻，比如步骤1中包含迭代器的工作流，节点追踪如下图所示：

点击迭代器节点 - Iteration，可以看到子流程如下：

调度事件

调度事件以列表的形式展示了任务每次调度的所有事件，针对Dify工作流任务，还包括了所有工作流和节点的事件，支持按照应用、任务名、任务执行ID、时间区间过滤：

总结

Dify-Schedule和MSE-XXLJOB，调度Dify工作流详细对比如下表：





欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5