Dify 架构解析与私有化部署

Dify AI开发平台的架构优势及私有化部署指南。

核心内容：

• Dify作为AI应用开发平台的对比优势
• Dify商用许可的限制与应用场景
• Dify组件总览及生产环境部署方案

如果你要搞一个企业级的AI应用，或者说智能体应用，通常有三条路可以走：

• 手写全部代码，自己去对接各家大模型的API接口
• 用一些封装好的SDK，比如Vercel的AI SDK
• 直接用Dify这种AI应用开发平台

跟Dify比较像的产品，像“扣子”，也是一个选择。但扣子是纯云端的SaaS，不太适合作为解决方案的一部分拿出去交付给客户。所以，代码开源且容易私有部署的Dify，就成了更务实的选择。

Dify的License能否商用

Dify用的是Apache开源协议，但商用上还是有一些附加条件的：

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

总体来看，这个协议还是挺宽松的。只要给每个企业客户单独部署一套专用环境，并且不让客户直接使用Dify的Web控制台，就不算违规。

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

你的项目是否需要使用Dify

开发智能体应用，不一定要用Dify。从技术上讲，用Ja va 8和Spring Boot去集成OpenAI的API也能跑得通。

但智能体应用有它自己的特点——需要反复调试提示词，处理知识库数据。这时候用Dify能极大提升开发体验和效率。总不能提示词稍微改改就发一个新版本吧。

Dify的后端是用Python开发的，原因很简单：AI相关的组件生态大部分都有现成的Python开发包。它跟企业级应用常见的Ja va后端不太一样，建议独立部署，跟业务集群分开。

Dify组件总览

Dify用的是常见的前后端分离架构，组件挺多的，部署方式也很灵活。

官方推荐的Docker Compose方案，其实只适合本地开发和体验。到了生产环境，就必须考虑K8s或者其他高可用部署方案。

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

必要组件

• api
• worker
• web

基本组件

• postgres
• redis
• sandbox
• ssrf_proxy
• certbot
• nginx
• wea viate

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

架构分层详细说明

后端

Dify的后端包括：

• “api”，以gunicorn启动的Python Flask服务
• “worker”，以celery启动，从redis队列中消费异步任务，比如数据集文件导入和文档更新

前端

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

接入层

用Nginx把网络请求转发给api或web，而certbot负责自动管理HTTPS证书。

存储层

Dify的存储层用了：

• 关系型数据库PostgreSQL
• NoSQL数据库/缓存Redis
• 向量数据库，默认是Wea viate

安全性

Dify作为应用开发平台，可以用可视化工具编排工作流节点来处理业务逻辑。工作流节点里允许用户执行Python或NodeJS代码，所以需要用Sandbox机制来限制用户执行高危操作。

涉及以下两个模块：

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

与LangChain的比较

LangChain是老牌的LLM应用开发框架。从下图的对比来看，Dify在多个方面都表现得更好。

生产环境中私有化部署Dify

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

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

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