Dify 架构解析与私有化部署

如果你需要开发一个企业级的 AI 应用，或者说智能体应用，一般有下面几种选择：

• • 手写全部代码，自行对接各类大模型厂商的 API 接口。
• • 使用某些封装过一层的 SDK，比如 Vercel 的 AI SDK^[2]
• • 使用 Dify 这种 AI 应用开发平台。

与 Dify 比较像的产品，有“扣子^[3]”。但扣子是纯云端 SaaS，不太适合作为解决方案的一部分拿去交付给客户。因此，代码开源且容易私有部署的 Dify 是更好的选择。

Dify 的 License 能否商用

虽然 Dify 使用 Apache 开源协议，但是商用有一些额外限制：

1. 1. 不允许提供多租户服务；
2. 2. 不允许修改 Dify Web 控制台界面的 LOGO 和版权信息。

总的来说，这个开源协议还是很宽松的。只要你给每个企业客户单独部署一套专用，并且不让客户使用 Dify Web 控制台，就不违反它。

换句话说，你完全可以不写一行代码，用 Dify Web 控制台的可视化工具搭建出智能体应用，然后将自动生成的 API 集成到自己的解决方案中。

我的项目是否需要使用 Dify

开发智能体应用，不一定非要用 Dify。本质上，你用老旧的 Java 8 和 Spring Boot 后端去集成 OpenAI 的 API 一样可行。

但智能体应用有一些特点，要去不断的调试提示词，处理知识库数据。使用 Dify 可以极大提升开发体验和效率。总不能提示词稍微改改就发个新版本吧。

Dify 后端使用 Python 开发，原因是 AI 相关的组件生态大部分都有 Python 的开发包直接可用。它与企业级应用常见的 Java 后端不同，建议是独立部署，跟业务集群分开。

Dify 组件总览

Dify 使用常见的前后端分离架构，组件非常多，部署方式也相当灵活。

Dify 官网推荐的 Docker Compose 部署方案，其实只能用于本地开发和体验。在生产环境中，应该根据需求，作 K8s 或者其它高可用部署方案。

以 Dify 0.15.3 版本为例，一个生产环境的部署，需要下面这些组件：

必要组件

• • api
• • worker
• • web

基本组件

• • postgres
• • redis
• • sandbox
• • ssrf_proxy
• • certbot
• • nginx
• • weaviate

组件之间的关系如下图所示

架构分层详细说明

后端

Dify 的后端包括

• • “api”，以 gunicorn 启动的 Python flask 服务；
• • “worker”，以 celery 启动，将异步任务从 redis 队列中消费。这些任务有数据集文件导入和数据集文档更新等。

前端

前端 “web” 是用 Next.js 开发的。构建后用 pm2 (node) 启动。

接入层

使用 Nginx 将网络请求转发给 api 或者 web，而 certbot 用来自动管理 HTTPS 证书。

存储层

Dify 的存储层使用了

• • 关系型数据库 PostgreSQL
• • NoSQL数据库/缓存 Redis
• • 向量数据库，缺省为 Weaviate

安全性

Dify 作为应用开发平台，是可以用可视化工具来编排工作流节点处理业务逻辑的。

工作流节点里可以允许用户执行 Python/NodeJS 代码，因此需要用 Sandbox 机制^[4]来限制用户去执行一些高危操作。

涉及以下两个模块

• • “sandbox” 是用 Go 语言开发的
• • “ssrf_proxy” 是用 squid 配置的网络出口

与 LangChain 的比较

LangChain 是老牌的 LLM 应用开发框架。从下图可以看出 Dify 在各个方面都胜过 LangChain^[5]。

生产环境中私有化部署 Dify

如果你需要为客户定制 AI 智能体应用，提供垂直行业的 AI 解决方案，就可以考虑在生产环境中私有化部署 Dify。

基于下面两个原因，可能还需要修改和深度定制 Dify 的代码：

1. 1. 打通企业内部数据，特别是整理出结构化的内部数据，形成可以用来 RAG 的知识库。
2. 2. 打通登录鉴权，这样智能体才理解自己的身份，从而提供个性化服务。