AWS云服务深度集成

第一部分：素材管理系统 - 分片上传与断点续传架构

在海量素材上传场景下，网络不稳定、文件巨大（数GB的视频/设计稿）是常态。直接简单上传会导致频繁失败且难以恢复。我们基于 AWS S3 Pre-signed URLs 和 Multipart Upload API，设计了一套高可靠的上传方案。

核心设计目标：可靠性、可恢复性、高并发性。

详细架构与流程：

我们的架构分为前端（浏览器）、BFF层（Node.js）和AWS S3三部分。

1. 初始化上传（Initiate Upload）

• 前端：用户选择文件后，前端计算文件的MD5哈希（作为唯一标识）和文件总大小，然后向我们的BFF服务发起 POST /api/upload/init 请求。
• BFF：
  • 根据文件哈希查询数据库，判断是否为“断点续传”。如果是，则直接从数据库恢复上传状态（如已上传的分片列表）。
  • 如果不是新文件，则调用AWS S3的 createMultipartUpload 方法，创建一个分片上传任务。S3会返回一个唯一的 UploadId。
  • BFF将 (FileHash, UploadId, Status=uploading) 存入数据库（如MySQL），并返回给前端。

2. 分片上传（Upload Parts）

• 前端：将大文件切割成固定大小的分片（例如5MB/片）。然后为每个分片并行地向BFF请求一个预签名URL。
• BFF：接到 GET /api/upload/presigned-url?uploadId=xxx&partNumber=1 请求后，调用AWS S3的 getSignedUrl('uploadPart', ...) 方法，生成一个仅对该分片有效的、有时效性的上传URL。该URL直接指向S3，不经过我们的服务器。
• 前端：拿到预签名URL后，直接使用HTTP PUT将分片数据上传到S3。这一步极大地减轻了我们BFF服务器的负载，并利用了S3的高带宽。
• 前端：每个分片上传成功后，S3会返回一个 ETag。前端将此 (partNumber, ETag) 暂时存储在本地（如IndexedDB）。

3. 完成上传与状态持久化（Complete Upload & State Persistence）

• 前端：当所有分片都上传完毕后，前端向BFF发送 POST /api/upload/complete 请求，携带 UploadId 和所有 (partNumber, ETag) 的列表。
• BFF：调用AWS S3的 completeMultipartUpload 方法，S3会根据提供的列表组装最终文件。
• 状态管理（关键）：我们设计了一个状态机来管理上传任务，状态包括：pending, uploading, completed, failed。
  • 在分片上传过程中，前端会定期（如每上传完5个分片）向BFF汇报进度，BFF更新数据库中的已上传分片列表。这是实现断点续传的核心——即使浏览器刷新或崩溃，再次初始化时，BFF也能告知前端哪些分片已经传过，前端只需上传缺失的分片即可。
  • 任何步骤失败（网络错误、S3服务异常）都会将任务状态置为 failed，并触发告警。我们实现了自动重试机制，对于可重试的错误（如网络超时）会自动重试数次。

技术挑战与解决方案：

• 挑战：前端直接上传S3可能遇到CORS问题。
• 解决方案：在S3存储桶上正确配置CORS策略，允许我们前端域名的请求。
• 挑战：保证最终一致性，防止僵尸任务。
• 解决方案：设置一个定时任务，扫描数据库中长时间处于 uploading 状态且无进展的任务，主动调用S3的 abortMultipartUpload 终止它们，并释放S3存储资源。

---

第二部分：高并发邮件系统 - SES的挑战与监控

使用AWS SES处理营销邮件和系统通知时，我们确实遇到了典型的云服务集成挑战。

遇到的挑战与解决方案：

1. 服务限流

   • 问题：SES对发送速率有严格的限制（例如，从最初的每秒14封逐步提升到50封）。在营销高峰期，我们迅速触达了速率上限，收到 Throttling 错误。
   • 解决方案：
     • 请求AWS提高限额：这是最直接的方案，我们提前根据业务预估申请了更高的发送速率。
     • 客户端指数退避重试：在BFF的邮件发送代码中，我们捕获 Throttling 异常，并实现了一个指数退避重试机制。第一次失败后等待1秒重试，第二次等待2秒，以此类推，避免加重SES的负担。
     • 异步队列削峰填谷：这是最核心的架构改进。我们不再同步调用SES，而是将邮件发送任务推入一个SQS队列。然后，我们部署了一个Lambda函数 或一个EC2消费者服务，从SQS队列中匀速地拉取任务（控制在SES速率限制内）并调用SES发送。这样，无论前端产生多少邮件请求，都不会冲垮SES。

2. 投递延迟与退信

   • 问题：
     • 延迟：在高峰期，即使没有限流，邮件进入SES的投递管道也可能出现几分钟的延迟。
     • 退信：主要原因是无效的邮箱地址（硬退信）或目标邮件服务器问题（软退信）。
   • 解决方案与监控设计：
     • 架构设计：我们构建了一个完整的邮件发送与监控链路。
     graph TDA[BFF/业务服务] -->|推送发送任务| B[SQS Queue];B --> C[Lambda Consumer];C -->|调用| D[AWS SES];D -->|推送投递事件| E[SNS Topic];E --> F[Lambda Event Processor];F -->|更新状态| G[DynamoDB];F -->|投递失败告警| H[CloudWatch Alarms];

     • 监控与可观测性：

       • 启用SES发送日志：将SES的所有发送事件（Send, Delivery, Bounce, Complaint）通过 CloudWatch Logs 进行记录。
       • 订阅SNS通知：我们配置SES将各类事件（投递成功、退信、用户投诉）发布到SNS主题。一个专用的 Lambda函数 订阅该主题，用于近实时地处理这些事件。
       • 状态追踪与告警：
         • Lambda事件处理器会更新 DynamoDB 中邮件记录的状态（如 delivered, bounced）。
         • 我们在CloudWatch中为退信率和投诉率设置告警。一旦超过AWS规定的阈值（默认退信率<5%，投诉率<0.1%），立即触发告警，通知运维和运营人员，防止SES账户被暂停。
         • 对于重要的系统通知邮件（如密码重置），我们还会监控从任务入队到最终投递的端到端延迟，确保用户体验。

     • 治理与维护：

       • 对于硬退信的邮箱地址，我们将其立即加入SES抑制列表，并同步到我们的用户数据库，未来不再向该地址发送邮件。
       • 定期审查CloudWatch仪表盘，监控发送量、投递率、退信率等关键指标，持续优化邮件内容和发送策略。

总结

通过这两套设计，我们展现了如何将云服务从简单的“工具”升级为构建复杂、可靠、可扩展业务系统的“基石”。

• 在素材系统中，我们利用S3的分片上传和预签名URL，构建了一个去中心化、高容错的文件上传架构，将流量压力从自身服务器转移至S3，并保证了极端情况下的任务可恢复。
• 在邮件系统中，我们通过与SQS、SNS、Lambda、CloudWatch等服务的深度编织，构建了一个具备自保护能力（防限流）、可观测性（全链路监控）和自我修复能力（处理退信） 的异步消息处理系统。这不仅解决了高并发问题，更实现了生产级应用所需的运营和治理能力。