企业官网建设流程全解析

1. 项目概述与核心价值

最近在折腾一个基于大语言模型的应用开发平台——Dify，想把它部署到AWS上。作为一个开源项目，Dify本身提供了Docker Compose的部署方式，但对于生产环境，尤其是需要弹性伸缩、高可用和全球访问的场景，直接上云原生架构是更靠谱的选择。AWS的弹性计算、托管数据库和全球网络，正好能补足这些需求。但手动在AWS控制台点点点，配置VPC、EKS、RDS、ALB、CloudFront，再整合Helm Chart，这个流程不仅繁琐，而且难以版本化和重复部署。这正是基础设施即代码（IaC）要解决的问题。

我找到了AWS官方示例库里的一个项目：aws-samples/solution-for-deploying-dify-on-aws。这个项目使用AWS CDK（Cloud Development Kit）来定义和部署一整套运行Dify的AWS基础设施。它最吸引我的地方，是采用了最新的TargetGroupBinding架构来替代传统的Kubernetes Ingress，解决了部署流程中“先有鸡还是先有蛋”的DNS配置难题。简单说，以前部署完得等Ingress Controller创建好ALB，才能拿到DNS地址去配CloudFront，现在CDK能预先创建好ALB，所有资源一步到位，部署体验流畅多了。这个方案非常适合那些希望将Dify作为内部AI应用开发平台，或者构建对外服务的团队，它提供了一个生产就绪、可扩展的起点。

2. 架构深度解析：从传统Ingress到TargetGroupBinding的演进

2.1 传统Ingress模式的痛点与局限

在Kubernetes生态中，对外暴露服务最常用的方式之一就是Ingress配合Ingress Controller（如AWS Load Balancer Controller）。它的工作流程是：你在K8s里创建一个Ingress资源，声明路由规则；Controller监听到这个资源后，会去AWS上动态创建一个Application Load Balancer（ALB），并配置相应的监听器和目标组；最后，Controller会将K8s Service背后的Pod IP注册到这个目标组中。

这个模式听起来很自动化，但在与CDK这类需要预知资源ARN或DNS进行后续配置的工具结合时，就暴露了几个明显的短板：

1. DNS不可预知性：ALB是在部署过程中由Controller动态创建的。这意味着，在CDK执行cdk deploy时，我们无法提前知道这个ALB的DNS名称是什么。而像CloudFront这样的下游服务，又必须在创建时就指定源站（Origin）的域名。这就导致了一个两阶段部署的尴尬局面：必须先部署EKS和Dify应用，等ALB创建出来，手动记下DNS，再回头去部署CloudFront堆栈。
2. 配置灵活性受限：ALB的许多高级配置（如特定的安全策略、自定义属性）需要通过Ingress的Annotations来指定。这种方式虽然能用，但配置分散在YAML文件中，不如在CDK代码中用强类型对象定义来得直观和易于管理。
3. 可观测性割裂：由于ALB是“黑盒”式创建的，其生命周期不完全受CDK管理。在需要调整ALB配置或排查问题时，你需要在AWS控制台和kubectl命令之间来回切换，心智负担较重。

2.2 TargetGroupBinding模式的工作原理与优势

TargetGroupBinding是AWS Load Balancer Controller提供的一种Custom Resource Definition（CRD）。它颠覆了上述流程：由我们（通过CDK）先在AWS上创建好ALB和Target Group，然后再在K8s中创建TargetGroupBinding资源，将K8s Service与这个预先存在的Target Group绑定起来。

这个模式带来了几个关键优势，也是本项目v2.0.0版本的核心改进：

1. ALB预创建，DNS立即可得：这是最大的亮点。CDK可以在部署应用之前，就创建好ALB。因此，ALB的DNS名称在部署脚本运行之初就是一个已知量。我们可以将这个DNS直接传递给CloudFront构造器，从而实现VPC网络、计算集群、应用、负载均衡和CDN的一次性、原子性部署。
2. 完全的配置主权：ALB的所有属性——监听器协议/端口、路由规则（基于路径的主机头）、安全组、空闲超时、访问日志等——都可以在CDK代码中精细控制。你可以像管理其他AWS资源一样，用代码定义ALB的一切行为。
3. 清晰的职责分离：CDK负责基础设施（ALB）的生命周期，Kubernetes负责应用（Pod）的生命周期，而TargetGroupBinding作为“粘合剂”，负责将两者动态关联。这种分离使得运维边界更清晰。
4. 更佳的可观测性：因为Target Group是显式创建的，你可以在AWS控制台直接查看其详细的健康检查状态、指标和注册目标，与K8s中的Pod状态对应关系一目了然。

具体到本项目的实现，它在CDK中创建了两个Target Group：一个用于Dify的后端API服务（通常端口5001），另一个用于前端Web服务（端口80/443）。然后，在通过Helm部署Dify时，会创建对应的NodePort类型Service，并同时创建两个TargetGroupBinding资源，分别将这两个Service绑定到预先创建好的Target Group上。AWS Load Balancer Controller会持续监控这些Binding，确保Pod的IP被正确注册或注销。

注意：使用TargetGroupBinding模式，要求你的EKS集群上安装的AWS Load Balancer Controller版本在v2.2.0及以上。旧版本不支持此CRD。

3. 核心组件选型与配置考量

这个CDK项目将Dify所需的后端服务拆解为多个独立的、可组合的AWS托管服务。理解每个组件的选型理由和配置要点，对于根据自身需求进行调整至关重要。

3.1 计算层：Amazon EKS集群

选择EKS而非EC2或ECS，主要基于以下几点：

• 与Kubernetes生态无缝集成：Dify官方提供了Helm Chart，这是为K8s环境量身定制的部署方式。使用EKS可以最原汁原味地利用Helm进行应用部署、版本管理和配置注入。
• 灵活的扩缩容：结合Kubernetes的HPA（Horizontal Pod Autoscaling）和EKS托管节点组的Cluster Autoscaler，可以根据Dify应用的CPU/内存使用量或自定义指标（如请求队列长度）自动调整Pod和节点数量。
• 丰富的网络与服务发现：K8s的Service和Ingress/TargetGroupBinding机制，为微服务架构提供了成熟的服务发现和负载均衡方案，与ALB集成度高。

配置要点：

• 节点组实例类型：项目默认使用m8g.large（Graviton3）。Graviton实例（ARM架构）通常比同档x86实例有更高的性价比和能效。确保你部署的Dify镜像有ARM64版本。如果没有，需要将instanceType改为如m6i.large（x86）等。
• 节点数量与自动伸缩：desiredSize、minSize、maxSize这三个参数需要根据负载预估来设置。对于生产环境，建议minSize至少为2，以保证高可用。maxSize则根据你的成本预算和峰值负载预期来设定。
• 集群版本：使用较新的稳定版本（如1.28+），以获得更好的安全性和功能支持。注意与AWS Load Balancer Controller版本的兼容性。

3.2 数据层：多引擎并存

Dify依赖多种数据存储，项目为每种都选择了AWS的托管服务，免去了运维负担。

1. 关系型数据库：Amazon Aurora PostgreSQL Serverless v2

   • 选型理由：Serverless v2是点睛之笔。Dify的数据库负载可能随着用户量和AI任务量波动。Serverless v2可以在一秒内将容量从最小0.5个ACU（Aurora Capacity Unit）扩展到最大（可配置）。在夜间或低峰期，成本极低；在白天高峰或运行批量任务时，又能自动扩容保障性能。这比预置固定容量的实例经济得多。
   • 配置要点：主要关注minCapacity和maxCapacity。对于初期，可以设为0.5-4 ACU。监控数据库的CPU利用率和连接数，后续再按需调整上限。务必启用删除保护和配置适当的备份保留期（生产环境建议7天以上）。

2. 缓存：Amazon ElastiCache for Redis

   • 选型理由：用于会话存储、临时数据和热点数据缓存，降低数据库压力。ElastiCache提供完全托管的Redis，支持自动故障转移、备份与恢复。
   • 配置要点：nodeType选择取决于缓存大小和吞吐量。cache.t4g.micro适合测试，生产环境建议从cache.t4g.medium起步。如果Dify需要多个工作节点共享会话，则必须使用Redis，而不能用本地内存缓存。

3. 向量/全文检索：Amazon OpenSearch Service

   • 选型理由：Dify的“知识库”功能依赖于向量检索。OpenSearch（及其内置的k-NN插件）是AWS上托管开源OpenSearch/Elasticsearch的服务，完美契合此需求。
   • 配置要点：这是成本大头。dataNodeInstanceType（数据节点类型）和dataNodes（节点数量）直接影响存储容量和检索性能。测试可用t3.small.search单节点，生产环境建议至少2个r6g.large.search节点起步，并启用多可用区部署。注意，OpenSearch的计费包含实例费用和存储费用。

4. 对象存储：Amazon S3

   • 选型理由：存储用户上传的文件、生成的图片、文档等非结构化数据。S3具有无限扩展性、11个9的持久性和极低的成本。
   • 配置要点：项目会创建一个专用S3桶。需要考虑的是生命周期策略（自动将旧文件转移到更便宜的S3 Glacier存储层）和桶策略（确保只有EKS节点和CloudFront有权限访问）。对于中国区，由于权限模型差异，可能需要配置访问密钥。

3.3 网络与交付层：ALB + CloudFront

1. Application Load Balancer：作为内部流量入口，接收来自CloudFront或直接来自公网的请求。在TargetGroupBinding模式下，我们在CDK中显式创建它。需要仔细配置安全组，仅允许CloudFront的IP段（如果用了CloudFront）或特定的公网IP访问443端口。
2. Amazon CloudFront：全球内容分发网络，是生产环境必备。
   • 加速与降低成本：将静态资源（JS、CSS、图片）缓存到边缘节点，用户就近访问，大幅降低延迟，同时减少ALB和Origin的流量压力。
   • 自动HTTPS：通过AWS Certificate Manager (ACM) 自动为你的自定义域名（如dify.yourcompany.com）申请和续期SSL/TLS证书，完全免费。
   • DDoS防护：CloudFront本身提供一定程度的分布式拒绝服务攻击防护。可以进一步启用AWS WAF（Web Application Firewall）关联到该分发上，防御常见Web攻击。
   • 配置要点：需要有一个在Route 53托管或已验证所有权的域名。在config.json的domain部分配置domainName和hostedZoneId。缓存行为策略是关键，通常需要为API路径（如/api/*,/v1/*）设置缓存策略为“CachingDisabled”，而为静态资源路径设置较长的TTL。

4. 实战部署：一步步搭建你的Dify平台

4.1 环境准备与初始配置

在开始之前，请确保你的本地开发环境满足以下要求，这并非儿戏，缺少任何一环都可能导致部署失败：

• Node.js 20.12.0+：CDK是TypeScript编写的，需要Node.js环境。建议使用nvm管理Node版本。
• AWS CLI v2：已安装并配置了具有足够权限的IAM凭证（aws configure）。部署将创建大量资源，建议使用具有管理员权限的IAM用户，或为CDK部署专门创建一个权限边界清晰的IAM角色。
• AWS CDK v2：通过npm install -g aws-cdk安装。安装后运行cdk --version确认。
• kubectl：用于与部署好的EKS集群交互。
• Git：用于克隆项目仓库。

首先，获取项目代码并安装依赖：

git clone https://github.com/aws-samples/solution-for-deploying-dify-on-aws.git cd solution-for-deploying-dify-on-aws npm install cd dify-cdk npm install cd ..

接下来是核心步骤：配置。项目提供了一个交互式命令行工具，强烈建议使用它，避免手动编辑JSON出错。

cd dify-cdk npm run config

这个工具会引导你完成一系列选择：

1. Dify版本：选择你要部署的Dify镜像版本。
2. 区域类型：是全球区域（如us-east-1）还是中国区域（cn-north-1）。注意：中国区不支持CloudFront。
3. VPC配置：是新建一个VPC，还是使用已有的VPC。对于生产环境，使用与公司网络打通（通过VPN或Direct Connect）的现有VPC通常是更好的选择。
4. EKS集群：新建或使用现有集群。
5. 各项服务规格：数据库实例类型、Redis节点类型、OpenSearch配置等。工具会根据你的选择（生产/测试）给出推荐配置。
6. 数据库自动迁移：强烈建议启用。这会在应用部署后，自动运行Dify的数据库迁移脚本，确保表结构是最新的。

配置完成后，会在dify-cdk/目录下生成一个config.json文件。这是整个部署的蓝图，所有自定义都基于此文件。

4.2 使用TargetGroupBinding模式进行部署

配置完成后，首先需要为你的AWS账户和区域引导（bootstrap）CDK环境。这只需要做一次。

# 确保你在 dify-cdk 目录下 cd dify-cdk npx cdk bootstrap aws://ACCOUNT-NUMBER/REGION # 例如：npx cdk bootstrap aws://123456789012/us-east-1

现在，可以开始一键部署了。项目提供的npm run deploy脚本会先编译TypeScript代码，然后执行cdk deploy --all。

# 推荐使用并行部署以加快速度 npx cdk deploy --all --concurrency 4 --require-approval never

• --concurrency 4：允许CDK同时部署最多4个独立的堆栈（如VPC、S3、RDS等），大幅缩短总部署时间。CDK会自动解析堆栈间的依赖关系，有依赖关系的不会并行。
• --require-approval never：对于有安全影响的变化（如IAM策略变更），CDK默认会要求交互式批准。此参数跳过批准，适用于自动化流水线。在首次部署或进行重大变更时，建议先不加此参数，仔细检查变更集。

部署过程会持续20-40分钟，具体取决于你配置的资源规格。期间，CDK会依次创建：

1. VPC堆栈：包含公有/私有子网、NAT网关、路由表等。
2. EKS集群堆栈：控制平面、托管节点组、核心插件（如VPC CNI、CoreDNS）。
3. 数据存储堆栈：RDS、Redis、OpenSearch、S3。
4. ALB堆栈（关键）：创建Application Load Balancer、两个Target Group（API和前端）、监听器、安全组。
5. Helm部署堆栈：在EKS上创建命名空间、Secret（存储数据库密码等），并部署Dify Helm Chart。Chart会创建Deployment、Service，以及TargetGroupBinding资源。
6. CloudFront堆栈（如果启用）：创建CDN分发，源站直接指向第4步创建的ALB DNS。

部署成功后，输出会显示所有关键端点的URL，最重要的是CloudFront域名（如果启用）或ALB的DNS名称。这个域名已经配置好了HTTPS，可以直接访问。

4.3 部署后验证与连接

部署完成不代表万事大吉，必须进行验证。

# 1. 更新kubeconfig，连接到新创建的EKS集群 aws eks update-kubeconfig --region <your-region> --name <cluster-name-from-config> # 2. 检查核心Pod是否运行正常 kubectl get pods -n dify # 你应该看到类似以下的输出，所有Pod状态应为Running或Completed # NAME READY STATUS RESTARTS AGE # dify-api-xxxxxx 1/1 Running 0 5m # dify-frontend-xxxxxx 1/1 Running 0 5m # dify-plugin-daemon-xxxxxx 1/1 Running 0 5m # dify-db-migration-xxxxxx 0/1 Completed 0 5m # 迁移任务完成即可 # 3. 检查TargetGroupBinding资源 kubectl get targetgroupbindings -n dify # 应该看到两个TGB，分别绑定api和frontend服务。 # 4. 检查Target Group健康状态 # 首先从CDK输出或AWS控制台获取Target Group的ARN API_TG_ARN=$(aws cloudformation describe-stacks --stack-name DifyStack --query "Stacks[0].Outputs[?OutputKey=='ApiTargetGroupArn'].OutputValue" --output text) aws elbv2 describe-target-health --target-group-arn $API_TG_ARN --query "TargetHealthDescriptions[*].TargetHealth.State" --output text # 输出应为 "healthy"。如果不健康，检查Pod日志和安全组规则。 # 5. 获取访问地址 CF_DOMAIN=$(aws cloudformation describe-stacks --stack-name DifyCloudFrontStack --query "Stacks[0].Outputs[?OutputKey=='DistributionDomainName'].OutputValue" --output text 2>/dev/null || echo "") if [ -z "$CF_DOMAIN" ]; then # 如果没启用CloudFront，则使用ALB地址 ALB_DNS=$(aws cloudformation describe-stacks --stack-name DifyStack --query "Stacks[0].Outputs[?OutputKey=='LoadBalancerDnsName'].OutputValue" --output text) echo "访问地址: https://$ALB_DNS" else echo "访问地址: https://$CF_DOMAIN" fi

打开浏览器访问输出的地址，你应该能看到Dify的登录界面。首次使用需要创建管理员账户。

实操心得：部署完成后，立即去AWS控制台的CloudFormation页面看一下。所有资源都被组织在几个清晰的堆栈里，一目了然。这种“基础设施即代码”的另一个好处是，当你不再需要这个环境时，只需运行npx cdk destroy --all，CDK就会按照依赖关系反向安全地删除所有资源，避免在控制台遗漏删除而产生费用。

5. 高级配置与运维管理

5.1 自定义域名与HTTPS配置

使用CloudFront时配置自定义域名是最佳实践。假设你已有一个在Route 53管理的域名dify.yourcompany.com。

1. 在config.json中配置：

   { "domain": { "useCloudfront": true, "domainName": "dify.yourcompany.com", "hostedZoneId": "Z1234567890ABC", // 你的Route 53托管区域ID "cloudfront": { "enabled": true, "domainName": "dify.yourcompany.com", "aliases": ["dify.yourcompany.com"], "priceClass": "PriceClass_200", // 使用北美、欧洲和亚洲的边缘节点 "waf": { "enabled": true // 启用WAF，增加安全防护 } } } }

2. 部署：重新运行cdk deploy。CDK会自动通过ACM为你的域名申请SSL证书，并将该证书关联到CloudFront分发上。同时，它会在Route 53中创建一条CNAME记录，将你的域名指向CloudFront分配。
3. 验证：访问https://dify.yourcompany.com，浏览器应显示由ACM签发的有效证书。

5.2 启用数据库自动迁移与插件守护进程

在config.json的dify部分，有两个重要配置：

• dbMigration.enabled: 设为true后，CDK会在部署应用时，自动创建一个Kubernetes Job来执行dify db upgrade命令。这确保了数据库表结构与当前Dify版本兼容。对于任何版本升级，都必须确保此功能启用或手动执行迁移。
• pluginDaemon.enabled: Dify的插件系统需要这个守护进程来管理插件的生命周期。如果你计划使用或开发Dify插件，必须启用它。storageSize定义了插件持久化存储的大小。

5.3 监控与告警设置

生产环境必须配置监控。建议至少设置以下CloudWatch告警：

1. EKS节点CPU/内存利用率：在EC2控制台为节点组设置告警，阈值建议设在70%-80%。
2. ALB：
   • HTTPCode_ELB_5XX_Count：负载均衡器自身错误，应接近0。
   • HTTPCode_Target_5XX_Count：后端目标（你的Pod）返回的5xx错误，需要关注。
   • TargetResponseTime：平均响应时间，设定一个业务可接受的上限（如2秒）。
3. RDS：
   • CPUUtilization、DatabaseConnections、FreeStorageSpace。
4. CloudFront：
   • 5xxErrorRate：查看错误率是否异常。

你可以通过CDK代码轻松添加这些告警，例如在对应的堆栈构造器中创建aws-cdk-lib.aws_cloudwatch.Alarm资源。

5.4 成本优化建议

1. 利用自动伸缩：
   • EKS节点：合理设置节点组的minSize、maxSize，并确保Cluster Autoscaler工作正常。
   • Aurora Serverless v2：根据监控设置合理的minCapacity和maxCapacity。夜间可以设置更小的最小值。
   • OpenSearch：可以考虑配置基于时间的自动伸缩（如夜间缩容），但这需要自定义脚本或使用OpenSearch的UltraWarm存储层（适用于历史日志/数据）。
2. 选择合适实例：初期可以使用较小的实例类型（如t4g系列），随着负载增长再升级。Graviton实例（*g系列）通常性价比更高。
3. S3生命周期策略：对于用户上传的文档、历史对话记录等不常访问的数据，可以配置规则，在30天后自动转移到S3 Glacier Instant Retrieval或Deep Archive存储层，成本可降低70%-95%。
4. 关闭测试环境：如果只是白天测试，可以在晚上通过脚本或定时任务调用cdk destroy销毁大部分资源（注意保留S3和RDS快照），早上再重新部署。对于长期不用的环境，务必彻底销毁。

6. 常见问题排查与故障修复

即使按照指南操作，也可能会遇到问题。这里记录了几个我踩过的坑和解决方法。

6.1 Pod一直处于Pending状态

现象：kubectl get pods -n dify显示Pod状态为Pending。排查步骤：

1. kubectl describe pod <pod-name> -n dify。查看Events部分，最常见的原因是：
   • Insufficient cpu/memory：节点资源不足。需要扩容节点组或检查是否有其他Pod占用了大量资源。
   • 0/3 nodes are available: 3 Insufficient pods.：节点上可分配的Pod数量达到上限（每个节点默认最多110个Pod）。对于运行少量大型应用的场景，这个限制通常不会触发。
   • FailedScheduling：没有节点满足Pod的亲和性/反亲和性规则或节点选择器。检查Dify Helm Chart的配置。
2. 如果事件提示与PVC（持久卷声明）相关，检查EKS集群的存储类（StorageClass）是否正确配置，以及是否安装了EBS CSI驱动。

6.2 Target Group显示目标“unhealthy”

现象：在EC2控制台的Target Groups页面，健康状态为unhealthy，导致ALB返回502错误。排查步骤：

1. 检查安全组：这是最常见的原因。ALB的安全组必须允许流量到达EKS节点（或Pod）的端口（通常是NodePort范围，如30000-32767）。同时，EKS节点（或Pod所在节点的安全组）必须允许来自ALB安全组的流量。确保两者是双向互通的。
2. 检查健康检查路径：默认的健康检查路径可能是/health或/。通过kubectl logs查看Pod日志，确认应用是否响应这个路径。有时Dify的健康检查端点可能需要特殊配置，需要在Helm values中自定义。
3. 检查网络ACL：确保VPC的子网网络ACL没有阻止健康检查流量（通常来自VPC CIDR）。
4. 查看Load Balancer Controller日志：kubectl logs -n kube-system deployment/aws-load-balancer-controller。看是否有关于注册目标失败的报错。

6.3 访问网站显示“502 Bad Gateway”或“503 Service Temporarily Unavailable”

现象：通过CloudFront或ALB域名访问，出现5xx错误。排查步骤：

1. 区分错误来源：直接访问ALB的DNS名称（不经过CloudFront）。如果也报错，问题在ALB或后端。如果直接访问ALB正常，但通过CloudFront报错，问题在CloudFront配置。
2. ALB层面问题：如上所述，检查Target Group健康状态。
3. CloudFront层面问题：
   • 源站配置：确认CloudFront分发的源站域名正确指向了ALB的DNS。
   • 协议策略：确认源站协议策略（Origin Protocol Policy）正确。如果ALB监听器是HTTPS，这里应选择HTTPS Only或Match Viewer。如果ALB是HTTP，则选择HTTP Only。强烈建议ALB和CloudFront之间使用HTTPS。
   • 查看CloudFront日志：启用标准日志（Standard Logs）并送到S3，查看详细的请求和响应信息。

6.4 数据库连接失败

现象：Dify应用日志显示无法连接到Aurora PostgreSQL。排查步骤：

1. 检查Secret：kubectl get secret dify-db-secret -n dify -o yaml。确认数据库连接信息（主机、端口、用户名、密码）是否正确。密码是Base64编码的，可以解码检查。
2. 检查RDS安全组：RDS实例的安全组必须允许来自EKS节点安全组（或Pod所在子网CIDR）的入站流量，端口通常是5432。
3. 检查网络连通性：在EKS的某个Pod中（kubectl exec -it <pod-name> -n dify -- bash），尝试用telnet或nc命令连接RDS端点。nc -zv <rds-endpoint> 5432。
4. 确认数据库已就绪：在RDS控制台检查实例状态是否为Available。

6.5 如何升级Dify版本

1. 修改配置：更新config.json中的dify.version字段为目标版本。
2. 执行部署：运行cdk deploy DifyHelmStack。由于只有Helm堆栈的输入参数发生了变化，CDK会智能地仅更新这个堆栈。它会执行helm upgrade操作。
3. 验证：部署完成后，检查新Pod是否启动成功，并通过Web界面确认版本已更新。务必确保dbMigration.enabled为true，以便自动执行可能的数据库迁移。

6.6 清理资源

当你想彻底删除整个环境时：

# 首先，删除CloudFront分发（因为其删除可能需要较长时间） npx cdk destroy DifyCloudFrontStack # 然后，删除其他所有堆栈 npx cdk destroy --all

重要提醒：默认情况下，RDS数据库实例和S3桶有删除保护。cdk destroy不会删除它们，以防止数据意外丢失。如果你确认要删除，需要先在AWS控制台手动关闭删除保护，然后再运行destroy命令，或者修改CDK代码，在创建这些资源时将deletionProtection属性设为false。