- Dify
- Agent 平台
Dify 企业版私有化部署：K8s 架构与容量规划实操
作者：Apolla 交付团队阅读约 3 分钟
结论先行
Dify 企业版在 Kubernetes 上支撑 3000 人在线的典型配置是三个节点池：业务接入池 16C/32G × 4、异步任务池 32C/64G × 4、基础设施池 8C/16G × 2，另需 PostgreSQL、Redis、对象存储与向量库。压测中最先出现瓶颈的不是模型调用，而是文档解析的异步任务队列与向量库的写入吞吐。
为什么要分节点池
Dify 的组件负载特征差异很大：API 与 Web 是典型的在线请求，延迟敏感；Worker 承担文档解析、向量化与批量任务，CPU 与内存密集且允许排队；数据库与缓存需要稳定的 IO。把它们放在同一批节点上，一次大批量知识库导入就能拖垮在线对话。
三个节点池的配置
- 业务接入池 16C/32G × 4：api、web、plugin-daemon、sandbox；按 CPU 60% 自动扩容
- 异步任务池 32C/64G × 4：worker（解析、向量化、批量任务）；按队列长度扩容
- 基础设施池 8C/16G × 2：Ingress、监控、日志采集；打污点，业务组件不调度到这里
- 3000人
- 目标在线用户规模
- 10节点
- 三个节点池合计
- <2秒
- 压测 P95 首字响应
Apolla 交付实测（某电力集团信创环境）
中间件选型
PostgreSQL 建议独立部署并开启读写分离，连接数按 api 副本数 × 连接池上限预留 1.5 倍余量；Redis 用作 Celery broker 与缓存，建议分实例，避免任务积压影响会话缓存；对象存储走 S3 兼容接口；向量库在 10 万文档以下 pgvector 够用，超过后迁移到独立向量库。
压测暴露的三个瓶颈
第一，批量导入 2000 份 PDF 时 Worker 队列积压超过 40 分钟，原因是解析任务默认并发过低，把 Worker 并发从 4 提到 16 并单独隔离解析队列后降到 6 分钟。第二，向量库写入吞吐在并发导入时成为瓶颈，改为批量写入后提升约 5 倍。第三，模型网关的连接复用未开启，导致高并发下 TCP 连接耗尽，开启 keep-alive 后消失。
容易被忽略的一项
sandbox 组件默认允许出网。生产环境务必收紧网络策略，只放行必要的内部地址，否则代码执行工具会成为数据外泄通道。
信创环境的额外工作
在麒麟 V10 ARM64 + 达梦 + containerd 的环境下，ARM64 镜像需要全部重新构建，依赖中有 3 个原生模块要源码编译；达梦对 JSONB 与数组类型的支持与 PostgreSQL 有差异，需要在 ORM 层适配。这部分工作量约占整体部署的 30%，建议在计划中单列。