Dify 自托管部署生产实践：从 Docker Compose 到高可用架构

痛点

团队要快速构建 AI 应用（RAG 知识库、Agent 工作流、对话机器人），选型时面临几个现实问题：

LangChain/LangGraph 门槛高 — 纯代码方案需要后端开发持续投入，产品经理无法参与调试
SaaS 方案数据不可控 — 企业敏感数据不能上传到第三方平台
内部重复造轮子 — 每个项目都写一套 prompt 管理、向量检索、模型路由逻辑

Dify 是开源的 LLM 应用开发平台（GitHub 90k+ stars），提供可视化 Workflow 编排、RAG Pipeline、Agent 框架、模型管理和 Prompt IDE，支持完全自托管。本文聚焦运维视角，讲清楚生产环境怎么部署、怎么调优、怎么避坑。

方案概览

Dify 架构核心组件：

组件	作用	技术栈
API Server	业务逻辑、模型调用编排	Python/Flask
Worker	异步任务（文档索引、数据集处理）	Celery
Web Frontend	可视化 Studio 界面	Next.js
PostgreSQL	元数据存储（应用配置、对话记录）	PostgreSQL 15+
Redis	缓存 + Celery Broker + 会话状态	Redis 7+
Vector DB	向量检索（知识库）	Weaviate/Qdrant/PgVector
Nginx	反向代理、静态资源	Nginx

实操步骤

第一步：Docker Compose 快速部署

# 克隆官方仓库
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 复制环境变量模板
cp .env.example .env

# 关键配置项（.env 文件）
# 生产环境必改项：
SECRET_KEY=<openssl rand -hex 32 生成>
CONSOLE_WEB_URL=https://dify.your-domain.com
SERVICE_API_URL=https://api.dify.your-domain.com
APP_WEB_URL=https://app.dify.your-domain.com

# 向量数据库选择（默认 weaviate，生产推荐 qdrant 或 pgvector）
VECTOR_STORE=qdrant
QDRANT_URL=http://qdrant:6333

# 存储配置（生产用 S3）
STORAGE_TYPE=s3
S3_BUCKET_NAME=dify-storage
S3_REGION=us-east-1

# 启动
docker compose up -d

第二步：外部数据库替代内置容器

生产环境绝不使用容器内数据库。将 PostgreSQL 和 Redis 外置：

# .env 修改为外部 PostgreSQL（RDS / 自建主从）
DB_HOST=your-pg-host.rds.amazonaws.com
DB_PORT=5432
DB_USERNAME=dify
DB_PASSWORD=<strong-password>
DB_DATABASE=dify

# 外部 Redis（ElastiCache / 自建 Sentinel）
REDIS_HOST=your-redis-host.cache.amazonaws.com
REDIS_PORT=6379
REDIS_PASSWORD=<redis-auth-token>
REDIS_USE_SSL=true

修改 docker-compose.yaml，注释掉内置的 db 和 redis service，避免资源浪费。

第三步：生产级 Nginx + HTTPS 配置

upstream dify_api {
    server 127.0.0.1:5001;
    keepalive 32;
}

upstream dify_web {
    server 127.0.0.1:3000;
    keepalive 16;
}

server {
    listen 443 ssl http2;
    server_name dify.your-domain.com;

    ssl_certificate /etc/letsencrypt/live/dify.your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dify.your-domain.com/privkey.pem;

    client_max_body_size 50m;  # 文档上传大小限制

    # API 请求
    location /api/ {
        proxy_pass http://dify_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;  # LLM 响应可能很慢
        proxy_buffering off;      # SSE 流式输出必须关闭 buffering
    }

    # SSE 流式端点
    location /api/chat-messages {
        proxy_pass http://dify_api;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        chunked_transfer_encoding on;
        proxy_read_timeout 600s;
    }

    # Web 前端
    location / {
        proxy_pass http://dify_web;
        proxy_set_header Host $host;
    }
}

第四步：Worker 扩容与资源限制

文档索引是 CPU/内存密集任务，Worker 需要独立扩容：

# docker-compose.override.yml
services:
  worker:
    deploy:
      replicas: 3
      resources:
        limits:
          memory: 4G
          cpus: '2.0'
        reservations:
          memory: 1G
          cpus: '0.5'
    environment:
      - CELERY_WORKER_CONCURRENCY=4
      - CELERY_WORKER_MAX_TASKS_PER_CHILD=100  # 防内存泄漏

避坑指南

1. SSE 流式输出被截断

症状：对话回复到一半突然中断，前端报 network error。

原因：Nginx 默认开启 proxy_buffering，buffer 满后断开连接。

修复：所有 LLM 相关端点必须设置 proxy_buffering off + proxy_read_timeout 600s。如果前面还有 CDN/负载均衡（如 AWS ALB），确认 idle timeout ≥ 600s。

2. 大文档索引 OOM Kill

症状：上传 PDF 超过 50MB 后 Worker 容器被杀。

原因：文档解析（PDF → 文本 → 分块 → Embedding）全在内存中完成。

修复： - Worker 内存限制设为 4G+ - 设置 CELERY_WORKER_MAX_TASKS_PER_CHILD=100，定期回收进程 - 业务层限制单文件大小（建议 ≤ 15MB），超大文档先拆分

3. 向量数据库选型踩坑

方案	适用场景	注意事项
PgVector	知识库 < 100 万条，团队已有 PG 运维能力	需 PostgreSQL 15+ 且安装 pgvector 扩展
Qdrant	百万级向量，需要高性能过滤	Rust 实现，内存占用可控，推荐生产用
Weaviate	多模态检索需求	Java 实现，内存消耗较大，JVM 调优门槛高

生产建议：数据量 < 50 万条直接用 PgVector（少维护一个组件），超过则上 Qdrant。

监控与运维

核心监控指标（Prometheus + Grafana）：

# 关键告警规则
- alert: DifyAPIHighLatency
  expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{service="dify-api"}[5m])) > 30
  annotations:
    summary: "Dify API P95 延迟超过 30s，检查 LLM Provider 响应"

- alert: DifyCeleryQueueBacklog
  expr: celery_queue_length{queue="default"} > 100
  annotations:
    summary: "Celery 队列积压超过 100，需要扩容 Worker"

- alert: DifyVectorDBDiskUsage
  expr: node_filesystem_avail_bytes{mountpoint="/data/qdrant"} / node_filesystem_size_bytes{mountpoint="/data/qdrant"} < 0.2
  annotations:
    summary: "向量数据库磁盘剩余不足 20%"

日常运维 Checklist： - 每周检查 Celery 死信队列（celery inspect active） - 每月清理过期会话记录（DELETE FROM conversations WHERE updated_at < NOW() - INTERVAL '90 days'） - 升级前先备份 PostgreSQL + 向量数据库快照

总结

部署阶段	核心动作
快速验证	Docker Compose 一键起，内置数据库够用
生产上线	外置 PG/Redis，S3 存储，Nginx 反代 + HTTPS
规模扩展	Worker 横向扩容，向量库选型升级，ALB + 多实例

Dify 的价值在于把 LLM 应用开发的通用基础设施标准化了 — prompt 管理、RAG Pipeline、模型路由、用量统计 — 运维只需要关注部署架构和资源调度。对于需要快速交付 AI 应用又不想把数据交给 SaaS 的团队，自托管 Dify 是当前性价比最高的方案之一。