使用扣子与Dify的业务风险

如果你正在使用扣子和Dify构建你的业务，有一个风险你必须关注。不是你的数据全在线上不安全，也不是将来费用太高,这些都是可以解决的问题。

而是当你的业务发展起来，数据量稍微增多时，性能就会下降很明显，甚至跑不动直接拒绝服务。

扣子性能测试

我用扣子构建了一个求质数的工作流，逻辑是指定一个数字，求出该数字以下的所有质数，逻辑如下图：

注：上述逻辑可以用一个脚本实现，但为了体现平台的多节点能力，特意拆分为 3 个步骤。

首先使用100来测试该流程，结果扣子用了11.23秒。

当我继续把数字增大到1000时问题出现了，经过10秒的挣扎然后报错了：

错误提示大意是节点数量过多，要我去优化节点，可实际节点就是只有6个，只是循环执行了1000次而已。

css 复制代码

 {
     "code": 6016,
     "debug_url": "https://www.coze.cn/work_flow?execute_id=7513813302357016610&space_id=7411328210694455348&workflow_id=7513465459611680777&execute_mode=2",
     "msg": "Workflow node execution limit exceeded: The number of executed nodes in the workflow has surpassed the allowed maximum. Please review and optimize your workflow to reduce the number of nodes."
 }

Dify性能测试

我用同样的逻辑在Dify 上进行测试了，几乎得到了一样的结果：

先测试100的情况：

在测试1000时又报错了

现在动不动就是上亿的数字，1千、1万的数据量真是太常见了，所以你的业务要是基于这两套系统构建的一定要注意其中的风险。

规避风险最好的方式是就有更好选择，不受制于某一家的系统，这里推荐一个不错的工作流编排n8n ，试了一下效果会好很多。

n8n的性能测试

使用n8n构建了一套一样的求质数流程

测试数字100 执行时间只要175毫秒，总算是一个正常的结果

说明一下，这里n8n是部署在我的本地，但我想这并不是关键问题因为这个测试中 Dify和扣子的 io传输与计算量都不大。

继续把数字提高到1000 看n8n的性能

加大到1000以后时间要6秒开始不尽人意了。但这不是最致命的问题，最大问题是当你用户起来有一定的并发的时候 n8n就会力不从心了

使用jmeter 构建了一100个线程同时发起调用，但这完全多佘了因为并发不到6/秒

而此时cpu已经飙到120%了，但并发始终上不去，而且出现了大量的错误。

这种情况其实也能理解，毕竟我使用的是免费版，如果用付费的企业版应该能解决这个问题，毕竟n8n还是以营利为目的。但这同样有受制于人的风险。

这时还有一个选择供大家参考，就是我最近一直在做的工作流编排系统。

ApiFlow 工作流编排

这是大叔做的编排系统，同样的逻辑看看性能情况：

直接测试1000

结果只要28毫秒，这看上去像走了本地缓存一样，其实这28毫秒大部都是http网络传输用掉的，真正的流程执行时间是1毫秒都不需要。

因为我我底层的DSL设计是基于Groovy语言构建的，类似Gradle或jenkins中的DSL，执行前DSL会被编译成Class 且编译一次，所以它的执行性能接近java原生语言，可充分利用jvm 的JIT热点缓存技术。

groovy 复制代码

/*构建时间:2025-6-8 14:38:47*/


//生成数组
eval_1 = EVAL {
	0..input.count.toLong()
}
// 数据遍历迭代
each_1 = EACH {
	from eval_1.result
	//转换质数
  map { 
    def num=it
    def res=true;
     if (num <= 1) {
        res=false;
      }else if (num == 2) {
        res=true;
      }else {
        for (int i = 2; i < num; i++) {
         if (num%i == 0) {
            res=false;
             break;
         }
        }
      }
    [prime:res,num:it]
  }
	//判断质数
  filter { 
    it.prime
	}
	list()
}
//返回总数
eval_2 = EVAL {
	each_1.result.size()
}
start {
	run eval_1
	run each_1
	run eval_2
}

现在我们把数字提高到1万性能也不会有太大差别。

当数字提升到1万扣子、Dify、n8n(免费版)三个平台都跑不动了，此外它的并发能力也是远远走在最前面：

用100个线程同时跑到达到了3000/s的并发，而且是零错误。

总结

若需构建最小 MVP 进行试错，使用扣子、Dify 是不错的选择，一旦业务量起来了就要考虑受制于人的风险，平台是否自主可控，如果业务量起来了，而服务确撑不住那就太尴尬可惜了。