Node.js基于AWS SDK向S3上传大文件的可取消最优方案对比

调研前置认知梳理 #

• 查阅AWS官方JavaScript SDK文档时，因接口抽象层级较多，初期存在较多理解障碍
• 对照公开参考资料，已明确putObject与s3.upload的基础差异：前者为单请求直传接口，硬限制仅支持5GB以内文件；后者为SDK基础封装，默认适配小文件上传场景
• 已确认基于API Gateway、Lambda搭建的上传链路存在固有的请求尺寸硬限制，完全无法覆盖1-100GB量级的大文件上传需求
• 当前已盘点到的大文件上传可选路径共三类：手动调用createMultipartUpload实现的原生分片上传流程、SDK内置ManagedUpload高层封装、基于getSignedURL的预签名上传链路

核心落地诉求 #

• 覆盖1-100GB量级的大文件上传场景
• 全流程支持上传操作的主动取消能力
• 尽可能压缩开发与维护成本，规避手动实现原生MultipartUpload流程的繁琐逻辑
• 找到适配场景的最简、最优实现路径

适配诉求的最优实现路径 #

优先选择SDK内置ManagedUpload做最小化封装 #

• 该能力是AWS JS SDK针对大文件上传专门提供的高层封装，已经自动实现了分片大小动态计算、分片并发上传控制、单分片失败自动重试、上传进度实时回传等通用逻辑，完全不需要手动对接createMultipartUpload、uploadPart、completeMultipartUpload等原生底层接口，能大幅降低手动编码的工作量
• 取消能力原生支持：每个ManagedUpload实例都内置abort()方法，调用后会自动完成两个核心动作：中断所有正在传输的分片请求、主动调用S3侧接口清理未完成的分片上传缓存，无需开发者手动实现取消后的资源清理逻辑
• 灵活适配预签名上传场景：如果需要跳过自建后端中转、直接将上传能力开放给前端，可将ManagedUpload内部的分片上传请求替换为预签名URL请求，整套流程的分片管理、进度回传、取消能力都可以复用，不需要重写核心逻辑
• 手动原生分片实现的冗余成本：需要自行维护分片序号映射关系、已上传分片的ETag清单、并发数控制、失败重试策略、取消时的跨分片清理逻辑，对于仅需要稳定跑通上传流程的场景，开发和长期维护成本远高于直接使用SDK内置封装

内容的提问来源于stack exchange，提问作者Rahul Ahire