【阅读原文】戳：高可用和性能：基于ACK部署Dify的最佳实践
随着人工智能技术的不断进步，大型语言模型（LLM）如GPT系列已成为许多AI应用的核心。然而，LLM的开发、部署、维护和优化涉及一系列复杂的实践和流程，这一过程通常被称为LLMOps。为了帮助用户轻松创建和管理LLM应用，Dify应运而生，成为一个简单易用的LLMOps平台。
目前，Dify的官方支持包括Docker Compose和基于源码的本地部署方式，但这两种方式在高可用性和可伸缩性方面存在不足，因此不适合于生产环境。相比之下，阿里云容器服务ACK（Container Service for Kubernetes）[1]提供高性能的容器应用管理，支持企业级Kubernetes容器化应用的生命周期管理，并且符合赔付标准的服务级协议（SLA），适用于对稳定性和安全性有高要求的大规模业务环境。此外，ACK能够与丰富的云产品无缝集成，显著增强Dify的整体性能。基于阿里云ACK可以轻松部署高可用、可伸缩且具备高SLA的Dify服务，满足生产环境的需求。
本文将提供在ACK集群中部署、管理高可用、可伸缩且具备高SLA的Dify服务的详细解决方案。
关于Dify
LLMOps是一套完整的实践和流程，旨在涵盖大型语言模型的开发、部署、维护及优化。其核心目标是应对大型语言模型的复杂性，涉及从模型的诞生到实际应用的整个过程，包括数据整理、架构设计、训练、微调、测试、部署以及持续监控等多个环节。在LLMOps的实施中，我们会面临如逻辑设计、上下文增强和数据准备等各种挑战，这些都要求我们投入相当多的时间和精力。而Dify的出现，则为我们提供了一个简便易用的平台，帮助我们轻松应对这些挑战。Dify并不只是一个单一目的、小而美的开发工具，而是一个All-In-One的一站式大模型应用开发平台。
Dify能做什么?
创业，快速的将你的AI应用创意变成现实，无论成功和失败都需要加速。在真实世界，已经有几十个团队通过Dify构建MVP（最小可用产品）获得投资，或通过POC（概念验证）赢得了客户的订单。
将LLM集成至已有业务，通过引入LLM增强现有应用的能力，接入Dify的RESTful API从而实现Prompt 与业务代码的解耦，在Dify的管理界面是跟踪数据、成本和用量，持续改进应用效果。
作为企业级LLM基础设施，一些银行和大型互联网公司正在将Dify部署为企业内的LLM网关，加速GenAI技术在企业内的推广，并实现中心化的监管。
探索LLM的能力边界，即使你是一个技术爱好者，通过Dify也可以轻松的实践Prompt工程和Agent技术，在GPTs推出以前就已经有超过60,000开发者在Dify上创建了自己的第一个应用。
Dify On ACK架构
目前，Dify官方支持了两种部署方式-Docker Compose、以及基于源码的本地部署方式。但这两种部署方式都不具备高可用、可伸缩的特性，不适合生产环境下使用，更多的是用于开发和测试环境。
基于ACK的Dify部署相比于Docker Compose和本地部署的方式，有高可用、弹性的优点，可以让Dify组件随业务需求变化即时、平滑地进行扩容，从而有力推动业务发展。与此同时，还可以使用云产品和云服务来代替Dify的基础组件，从而获取更高的性能和SLA。
此外，在Dify编排LLM应用过程中，用户既可以选择直接调用LLM服务供应商的OpenAPI，也可以通过ACK部署专属的模型推理服务[2]。这种灵活性和易扩展性，使其能够满足多样化的生产场景需求。
基于ACK部署Dify
Dify应用的组件主要包括业务组件和基础组件两大类，业务组件包括：api/worker、web、sandbox。基础组件包括：db、verctor db、redis、nginx、ssrf_proxy。
目前，ACK控制台的应用市场已经提供ack-dify的应用安装。默认情况下基础组件会使用社区开源的redis、postgres以及weaviate。如果您对这些基础组件有更高的性能、功能和SLA要求、或者对基础组件有运维和管理的压力，可以使用我们的如下云产品:
• 云数据库Redis[3]
• RDS PostgreSQL[4]
• AnalyticDB PostgreSQL版[5]
基于ACK实现Dify高可用、弹性部署，并同时集成云产品的解决方案，可以实现Dify稳定、高性能部署。
为了实现以上部署，我们需要在ack-dify的参数配置界面完成如下的参数配置，主要包括以下方面：
1. 云产品配置
2. 高可用和弹性配置
3. 服务访问配置
一、云产品配置
本次实践教程中，会使用到云数据库Redis、RDS PostgreSQL、AnalyticDB PostgreSQL版，我们可以按照如下教程提前准备相关资源。
• 云数据库Redis[3]
• RDS PostgreSQL[4]
• AnalyticDB PostgreSQL版[5]
1.在准备好相关的云资源后，我们首先需要关闭默认的开源的组件安装，包括：redis.enabled、postgresql.enabled、weaviate.enabled 均设置为false。
2.配置云数据库Reids
################################### # External Redis # - these configs are only used when `externalRedis.enabled` is true ################################### externalRedis: enabled: true host: "r-***********.redis.rds.aliyuncs.com" port: 6379 username: "default" password: "Dify123456" useSSL: false
1. 配置RDS PostgreSQL
################################### # External postgres # - these configs are only used when `externalPostgres.enabled` is true ################################### externalPostgres: enabled: true username: "postgres" password: "Dify123456" address: "pgm-*********.pg.rds.aliyuncs.com" port: 5432 dbName: dify maxOpenConns: 20 maxIdleConns: 5
2. 配置ADB
################################### # External AnalyticDB # - these configs take effect when `externalAnalyticDB.enabled` is true ################################### externalAnalyticDB: enabled: true accessKey: "***" secretKey: "***" region: "cn-hongkong" instanceId: "gp-*************" account: "dify_user" accountPassword: "********" # 可以指定已有的namespace;或者填写一个不存在的namespace,会自动创建 namespace: "difyhelm" namespacePassword: "difyhelmPassword"
二、高可用和弹性
多数用户基于ACK的部署应用时，都对应用有高可用和弹性伸缩的需求，来提高应用的容灾和对峰值负载的处理能力。在ACK上，只需要对应用的配置进行如下简单的配置，就可以达到以上效果。
1.多副本：目前dify的核心业务组件，如api、worker、web、sandbox默认配置为一个副本，通过配置如下参数，可以达到多副本的效果。
api.replicas: 2 ... worker.replicas: 2 ... web.replicas: 2 ... sandbox.replicas: 2
2.副本打散: 为了避免单节点、或者单az故障对应用整体服务不可用，我们通常需要设置副本之间的打散。示例通过配置pod之间的反亲和性，实现同组件pod尽量打散到不同节点的效果。
api.affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: component operator: In values: - api topologyKey: kubernetes.io/hostname ... worker.affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: component operator: In values: - worker topologyKey: kubernetes.io/hostname ... web.affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: component operator: In values: - web topologyKey: kubernetes.io/hostname ... sandbox.affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: component operator: In values: - sandbox topologyKey: kubernetes.io/hostname
3.弹性配置：为了应对峰值负载的压力，我们通常还会为资源消耗密集型的组件增加弹性伸缩配置。比如worker组件，在处理大量的文档知识库的过程中，容易出现cpu/mem的升高，可以通过如下配置，来实现worker的自动伸缩。
woker: ... autoscaling: enabled: true minReplicas: 1 maxReplicas: 5 metrics: - type: Resource resource: name: memory target: averageUtilization: 80 type: Utilization
配置后，dify同一组件的多个副本均分布在不同的节点上，且woker依据内存使用量自动伸缩，部署效果如下：
➜ ~ kubectl get po -n dify-system -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ack-dify-api-655bbf7468-95sfj 1/1 Running 0 6m42s 192.168.1.186 cn-hangzhou.192.168.1.164 <none> <none> ack-dify-api-655bbf7468-zdw7l 1/1 Running 0 6m42s 192.168.0.51 cn-hangzhou.192.168.0.40 <none> <none> ack-dify-proxy-5f6c546d87-blx79 1/1 Running 0 6m42s 192.168.1.178 cn-hangzhou.192.168.1.165 <none> <none> ack-dify-sandbox-5fd7cd8b7c-9flwh 1/1 Running 0 6m42s 192.168.1.183 cn-hangzhou.192.168.1.164 <none> <none> ack-dify-sandbox-5fd7cd8b7c-mhq99 1/1 Running 0 6m42s 192.168.0.53 cn-hangzhou.192.168.0.40 <none> <none> ack-dify-web-6fbc4d4b4b-54dkx 1/1 Running 0 6m42s 192.168.1.185 cn-hangzhou.192.168.1.164 <none> <none> ack-dify-web-6fbc4d4b4b-6kg8f 1/1 Running 0 6m42s 192.168.0.41 cn-hangzhou.192.168.0.40 <none> <none> ack-dify-worker-5dddd9877f-cq6rs 1/1 Running 0 6m42s 192.168.0.44 cn-hangzhou.192.168.0.40 <none> <none> ack-dify-worker-5dddd9877f-s6r6z 1/1 Running 0 6m42s 192.168.1.182 cn-hangzhou.192.168.1.164 <none> <none> ➜ ~ kubectl get hpa -n dify-system NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE ack-dify-worker Deployment/ack-dify-worker memory: 17%/80% 1 5 2 6m43s
三、服务访问配置
ACK中，我们推荐通过配置Ingress透出Dify服务，相关操作可参照Ingress管理[6]。目前支持配置Nginx Ingree和ALB Ingress, 这里以Nginx Ingress为例。为了安全强烈建议您开启tls设置。
ingress: enabled: false # Nginx Ingress className can be set "" # ALB Ingress className can be set "alb" className: "" annotations: {} # kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" # nginx.ingress.kubernetes.io/backend-protocol: HTTP # nginx.ingress.kubernetes.io/proxy-body-size: 15m # nginx.ingress.kubernetes.io/ssl-redirect: "true" hosts: - host: dify-example.local paths: - path: / pathType: Prefix backend: service: name: ack-dify port: 80 tls: - secretName: chart-example-tls hosts: - dify-example.local
配置成功后，即可安全便捷的访问Dify服务，进行LLM应用编排、集成LLM应用到已有业务中等等。一个便捷的示例，可以参照使用Dify快速构建AI问答助手_容器服务Kubernetes版ACK(ACK)-阿里云帮助中心[7]。
总结
Dify On ACK的架构支持高可用和弹性的特性，使得其能够根据业务需求快速扩容。这种部署方式允许集成云服务，提供更高的性能和服务等级协议（SLA），极大提升了Dify的稳定性和可用性。通过ACK，用户可以借助云数据库，如云数据库Redis、RDS PostgreSQL和ADB，来取代默认的开源组件，进一步增强功能和性能。
此外，利用ACK的弹性配置，企业能够应对峰值负载，实现自动伸缩，提高系统的容灾能力。这使得Dify不仅适合快速启动创新项目，还能作为企业级LLM基础设施，加速GenAI技术在企业中的推广。
总而言之，在ACK上部署Dify不仅显著提高了可用性与性能，也简化了管理运维，为企业提供了一个稳健的AI应用开发环境。通过Dify及其在ACK上的部署，用户能够快速将AI应用落地，并持续优化其效果。
相关链接：
[1]阿里云容器服务ACK
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/product-overview/what-is-ack
[2]通过ACK部署专属的模型推理服务
https://help.aliyun.com/zh/ack/cloud-native-ai-suite/use-cases/llm-reasoning-practice/
[3]云数据库Redis
https://www.aliyun.com/product/redis
[4]RDS PostgreSQL
https://help.aliyun.com/zh/rds/apsaradb-rds-for-postgresql/what-is-apsaradb-rds-for-postgresql
[5]AnalyticDB PostgreSQL版
[6]Ingress管理
[7]使用Dify快速构建AI问答助手_容器服务Kubernetes版ACK(ACK)-阿里云帮助中心
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
获取关于我们的更多信息~
