2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
大多数无服务器教程都止步于应用程序接口网关背后的一个“你好，世界”级别的拉姆达函数。而我想要的是相反的做法：从头到尾构建一个真实的产品，在真实的亚马逊云科技平台上运行每一条命令，并记录下实际的数据——包括那些未按计划进行的部分。
最终成果是一个由21篇文章组成的系列，构建了一个具备实时点击分析功能的统一资源定位符缩短器，完全采用无服务器架构，并将其部署至生产环境：涵盖身份验证、多租户支持、事件流水线、实时推送、可观测性、带有金丝雀部署的持续集成/持续交付、成本细分以及负载测试。代码地址：
github.com/nghiadaulau/serverless-url-shortener-aws。
产品架构
┌──────── Cognito (JWT) ─────────┐
浏览器 ─HTTPS──▶ 应用程序接口网关 (HTTP API) │ 身份验证
│ │ │ │
POST /links ───┼─────▶ 创建 ──▶ DynamoDB (单表设计)
GET /{code} ───┼─────▶ 解析 ─┬─▶ 301 重定向
│ │ └─▶ EventBridge ─▶ SQS(+死信队列) ─▶ 聚合器
│ │ │ 计数 + 推送
└─WebSocket───────────────────────────────────◀── 实时仪表盘
Step Functions (链接审核) · X-Ray · CloudWatch 警报
SAM (基础设施即代码) · GitHub Actions 持续集成 · CodeDeploy 金丝雀部署 + 回滚
这里没有任何需要您持续运行的服务器。空闲成本实际上为零。
几个令我惊讶的发现（均为实测数据，非引用）
内存即中央处理器。 同样的中央处理器密集型任务，在128 MB与1769 MB内存配置下的对比：
128 MB: 2594 毫秒
1769 MB: 88 毫秒 → 速度快约29倍，且成本低约2.25倍（内存 × 计费时间）
在128 MB配置下，拉姆达函数面临的是中央处理器资源匮乏，而非内存不足（两者中最大使用内存均保持在约82 MB）。同样的调整手段将冷启动时间从1513 毫秒降低至 295 毫秒。
并发上限是配额限制，而非代码问题。 使用 k6 进行负载测试，速率约为554 请求/秒：
总请求数: 27741
301 (成功): 304 (1.1%)
503 (过载): 25 (0.1%)
429 (被限流): ~98.8%
并发执行数 (最大值): 10
该账户的拉姆达函数并发限制被降低为10，且我故意设置了应用程序接口网关的速率限制。因此，在负载压力下，系统通过两层机制丢弃流量（网关层的429错误，拉姆达函数层的503错误），并为所服务的请求保持快速响应——这是优雅降级，而非系统崩溃。解决方案不是优化代码，而是提高配额。
无需框架的幂等性。 点击事件至少交付一次，因此简单的计数会导致重复计算。使用一次 DynamoDB 的TransactWriteItems操作，既增加计数器又写入一个带有attribute_not_exists条件的CLICK#<eventId>标记——如果是重复请求，整个事务将被取消，从而确保只计数一次。
账单。 构建和测试整个系统——包括应用程序接口、数据库、身份验证、事件总线、队列、实时功能、状态机、可观测性——成本基本上为0美元，全部在免费套餐范围内。
本系列涵盖的内容
- 基础 — SAM、拉姆达函数执行生命周期、冷启动、arm64架构
- 核心 — HTTP API 与 REST API 对比、DynamoDB 单表设计、全局二级索引与稀疏索引、条件写入、原子计数器
- 身份验证 — Cognito + JWT 授权器、多租户、在数据层阻止不安全的直接对象引用
- 事件驱动 — EventBridge、SQS + 死信队列、幂等性、部分批次失败处理、WebSocket 实时推送、Step Functions + saga 模式
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
