应用架构与 AWS 工程路线

部署不是把代码传到云上，而是把入口、计算、数据、权限、发布和故障恢复连成一条可验证的链路。这套知识同时服务 AI 应用和 Web3 后端。

从已有知识接着学

主题	基础知识入口	工程实践入口
页面渲染与托管	SSR、CSR、SSG、ISR	静态托管与服务端运行方式选型
Web 托管、域名与 HTTPS	Amplify、Route 53、CloudFront、ACM 与 ALB	部署方式与上线检查
云服务概念	Serverless 服务介绍、AWS 原笔记	一次请求中各项服务怎样配合
权限、网络、数据库	RDS、S3	IAM、网络与数据安全
短请求 API	Lambda	Node/Hono 部署到 Lambda
常驻 API 与 Worker	ECS	Go 服务与 ECS/Fargate
自动发布与预览	CI/CD	IaC、灰度与 PR 预览环境
异步任务	SQS	事件队列与可靠处理
日志、指标与体验	CloudWatch	可观测性与 AI 辅助排障
故障与成本	CloudWatch 日志与监控	排障、备份恢复与成本

新增 AWS 篇章整理自 github-account-info 的部署文档，包括 Node Lambda、Go 容器平台、稳定性、性能监控和备份恢复。这里保留可复用的设计与操作方法，不复制真实账号、资源 ID、Secret、内部域名或历史验收状态。原项目文件不移动、不删除。

一次请求与一次后台任务

浏览器 → 静态资源托管/CDN
  └→ API Gateway
       ├→ Lambda：短请求、鉴权、入队
       └→ VPC Link → Internal ALB → ECS：常驻 API
                         │
                    私有数据库

API → SQS → Lambda/ECS Worker → 数据库结果
                     └→ 日志、指标、告警

API Gateway 是统一 API 入口；VPC Link 将网关连接到私网资源；ALB（Application Load Balancer，应用负载均衡器）把 HTTP 请求转到健康实例；ECS 管理容器任务，Fargate 提供无需自行维护 EC2 主机的计算资源。不是每个项目都要同时使用这条图里的所有服务。

怎么选运行方式

工作负载	优先考虑	主要代价
静态页面、JS/CSS、图片	对象存储/CDN 或静态托管平台	不能把需要服务端执行的 SSR 当普通静态文件发布
短时、事件驱动、波动大的处理	常规 Lambda	冷启动、超时、并发配额、数据库连接控制
常驻服务、浏览器进程、长连接、持续消费	ECS/Fargate	常驻费用、健康检查、容量与容器发布
多阶段等待、重试和人工确认	工作流编排 + 持久化状态	编排不能替代每个步骤的幂等与资源限制

选择 Lambda 不是因为 Go 不能运行在 Lambda，选择 ECS 也不是因为 Node 不能运行容器。依据是执行方式、资源、时长和运维需求。

Serverless 的几个准确边界

Serverless（无服务器）是一种不需要开发者逐台管理底层服务器的云服务模式。开发者提交代码或配置服务，由云厂商管理底层机器并提供按需扩缩容能力；服务器仍然存在。

Lambda 只是其中一种产品。Lambda 运行函数代码，API Gateway 提供 API 入口，SQS 提供消息队列，ECS + Fargate 可以运行容器。它们承担不同职责，不能把 Lambda 的时长限制当作所有 Serverless 服务的限制。

Serverless 是减少主机管理，不是没有运维或一定更便宜。应用仍要选择运行时与架构，维护依赖、权限、连接池和故障恢复；高并发也可能压垮数据库或外部模型配额。

常规 Lambda 单次函数执行的 timeout 上限是 900 秒；简单改成异步调用不会延长该次执行上限。AWS 还提供 Managed Instances、durable functions 等不同执行形态，限制不能混为一谈。官方当前说明 Managed Instances 的部分异步/事件源映射调用可达 5,400 秒，同步调用仍受 900 秒限制。采用哪种形态，要同时核对目标账号、区域、费用和工作负载，不能把新版能力当作原项目已有配置。

浏览器、网关、代理和下游还有各自超时。能运行十五分钟不代表用户 HTTP 请求能一直等十五分钟。长任务通常返回 taskId，让后台处理，再用查询、SSE 或其他方式更新进度。

长任务可以按运行方式选择：

• ECS + Fargate：ECS 管理容器任务，Fargate 提供运行资源。适合常驻扫描、Temporal Worker、浏览器进程，不受常规 Lambda 单次调用时长限制，但仍需设计退出、重试与状态恢复。
• AWS Batch + Fargate (opens new window)：Batch 负责排队、调度和失败重试，Fargate 运行容器，适合批量文件处理、离线计算等跑完就结束的任务。

用一个长任务说明服务选型

假设用户提交生成报告任务，平时请求少，但一次生成可能持续几分钟。HTTP 接口先鉴权、校验输入，持久化任务和待投递事件，再返回 taskId；后台消费者执行，页面查询状态。数据库与投递的一致性用 Outbox 与幂等消费 处理，不能先返回成功却没有任何持久化记录。

若处理时长有明确上限、依赖容易打包、适合事件触发，可以评估 Lambda；若需要持续运行的浏览器、长连接或时长难以保证的进程，更适合容器 Worker。队列解决缓冲与重试，计算服务解决在哪里执行，持久化状态解决重启后还记得做到哪一步。它们不是相互替代的方案。

流量增长时也不应直接无限扩消费者。假设外部模型最多允许 20 个并发，开 200 个 Worker 只会制造限流与重试；需要在消费者侧限并发，并根据最慢下游的承受能力决定扩容。

高可用不是给每个服务多建一份

多个 API 副本只能解决部分实例故障，不能解决共享数据库连接耗尽、错误版本同时发布或同一个外部 API 不可用。设计时先找单点和共同故障，再决定多可用区、备份、限流和降级，而不是只增加副本数。

例如两个可用区的 Task 共用一个数据库，即使其中一个 Task 停机，另一个能继续接流量；但若数据库不可用，两个 Task 都可能失败。数据库高可用负责缩短这类中断，备份负责误删等恢复，两者也不能互相替代。

面试时可以这样回答

什么时候用 Lambda，什么时候用 ECS？参考答案

我按执行时长、依赖和负载方式选，不按语言选。短时、事件驱动、波动大的任务适合评估 Lambda；常驻进程、长连接或资源控制要求更高的任务适合 ECS。比如报告入口可以用 Lambda 校验并入队，浏览器执行器放在容器里。两种都要限制并发、保护数据库，Serverless 不会替应用解决幂等和恢复。

为什么服务扩容了，系统反而更慢？参考答案

扩容增加了对共享下游的压力。如果数据库连接、锁或模型配额已经饱和，多开实例只会放大排队和重试。我会先看各层耗时和容量，限制入口及消费者并发，再处理慢查询、缓存或下游配额。扩容依据是整条链路的瓶颈，不只是 API 的 CPU。

学完怎样验收

能解释一次请求经过哪些边界；能从代码版本追到部署版本；能说明队列重试为何不重复产生业务效果；能在健康检查失败时回退流量；能用备份在隔离环境恢复数据。项目已上线的具体证据继续放在对应项目手册，不在通用笔记里虚构执行结果。

官方参考

• Lambda timeout 与不同执行形态 (opens new window)
• AWS Well-Architected (opens new window)