乐闻世界logo
5月27日 16:17

Serverless 文件处理如何实现？

Serverless 架构中处理文件是一个高频场景，但和无服务器计算打交道，存储选型、执行限制、事件触发这些环节都和传统服务器方案有本质区别。下面从存储选型、处理场景、性能优化和注意事项四个维度讲清楚。

存储服务选型

对象存储（首选方案）

对象存储是 Serverless 文件处理的核心依赖，几乎所有文件操作都围绕它展开：

  • AWS S3：最成熟的对象存储服务，支持事件通知、预签名 URL、生命周期策略、版本控制，是 Lambda 文件处理的事实标准
  • Azure Blob Storage：Azure 生态对应方案，与 Azure Functions 深度集成，支持 Blob 触发器
  • 阿里云 OSS：国内常用方案，与函数计算 FC 配合，支持事件触发和 URL 签名

对象存储的核心优势在于高可用、按量计费、理论上无限扩展，天然适配 Serverless 的弹性模型。

临时存储（/tmp）

函数运行实例提供 /tmp 目录作为临时文件系统，但有一系列限制需要注意：

  • 容量：AWS Lambda 默认 512MB，可配置到 10GB；阿里云 FC 最大 10GB
  • 生命周期：内容在函数实例被回收时清除，不能跨调用持久化
  • 持久性：同一实例被复用（冷启动后的热调用）时 /tmp 内容仍在，但不能依赖这种行为
  • 典型用途：下载文件到本地处理后上传回对象存储，例如图片压缩时先下载到 /tmp 再处理
python
import boto3
import os

s3 = boto3.client('s3')

def lambda_handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    # 下载到 /tmp
    download_path = f'/tmp/{os.path.basename(key)}'
    s3.download_file(bucket, key, download_path)
    
    # 处理文件...
    
    # 上传回 S3
    s3.upload_file(download_path, bucket, f'processed/{os.path.basename(key)}')

持久文件系统（EFS）

当多个函数实例需要共享文件，或者需要持久化存储时，可以使用弹性文件系统：

  • AWS EFS：可挂载到 Lambda 函数，支持多实例同时读写
  • 适用场景：机器学习模型的共享加载、需要文件锁的并发写入、大容量持久化需求
  • 注意：EFS 会引入额外的冷启动延迟（首次挂载约 1-3 秒），需要权衡是否真有必要

文件处理的核心场景

文件上传

Serverless 中的文件上传推荐使用预签名 URL 模式，客户端直传对象存储，不经过函数：

python
def generate_upload_url(bucket, key, expires=3600):
    s3 = boto3.client('s3')
    return s3.generate_presigned_url(
        'put_object',
        Params={'Bucket': bucket, 'Key': key},
        ExpiresIn=expires
    )

大文件（>100MB）应使用分片上传（Multipart Upload），客户端将文件分成多个 Part 并行上传，最后由服务端合并。上传完成后，S3 可以配置事件通知自动触发 Lambda 进行后续处理，形成完整的上传-处理流水线。

文件处理

图片处理

Lambda 处理图片是典型场景，包括缩放、裁剪、格式转换、水印等：

python
from PIL import Image

def process_image(input_path, output_path, size=(800, 600)):
    with Image.open(input_path) as img:
        img.thumbnail(size)
        img.save(output_path, 'JPEG', quality=85)

需要注意 Lambda 的内存和超时限制：图片处理通常需要 512MB-1GB 内存，超时设置建议不超过函数最大限制（15 分钟），大图处理要考虑分块策略。

视频处理

视频转码是计算密集型任务，直接用 Lambda 并不合适（受限于 15 分钟超时和内存上限）。推荐方案：

  • AWS Elemental MediaConvert：专业视频转码服务，Lambda 提交转码任务后由 MediaConvert 异步执行
  • AWS Batch：对于自定义转码逻辑，使用 Batch 运行容器化任务，没有 15 分钟限制

文档处理

PDF 生成、Word 转 PDF、Excel 解析等文档处理场景，Lambda 可以胜任轻量级任务。但大型文档（数百页 PDF）可能触及内存或超时限制，此时应该使用异步任务队列将工作卸载到 ECS/Fargate。

文件下载

下载同样推荐预签名 URL 直传模式，避免文件流量经过函数。对于大文件和高频访问场景，配合 CDN 加速：

python
def generate_download_url(bucket, key, expires=3600):
    s3 = boto3.client('s3')
    url = s3.generate_presigned_url(
        'get_object',
        Params={'Bucket': bucket, 'Key': key},
        ExpiresIn=expires
    )
    # 配合 CloudFront 分发
    return url

流式传输适合视频、音频等大文件场景，客户端可以边下载边播放，不必等整个文件传输完成。

性能优化

缓存策略

三层缓存体系：

  • CDN 缓存：CloudFront 等 CDN 缓存静态资源，设置合适的 Cache-Control 头控制 TTL
  • 浏览器缓存：通过 Cache-Control 和 ETag 让浏览器缓存资源，减少重复请求
  • 边缘计算：Lambda@Edge 在 CDN 节点执行轻量逻辑，比如根据设备类型返回不同尺寸图片，避免回源到主 Lambda

并发与异步处理

文件处理任务有天然的可并行性，充分利用这一点可以大幅提升吞吐量：

  • 事件驱动异步处理：S3 上传事件触发 Lambda，每个文件独立处理，天然并行
  • SQS/SNS 解耦：高并发场景下用消息队列削峰，Lambda 从队列消费任务，避免突发流量打垮下游
  • 批量处理：S3 Batch Operations 可以对大量对象执行批量操作，比逐个触发 Lambda 更高效
  • Step Functions 编排：复杂的多步处理流程（上传 -> 转码 -> 生成缩略图 -> 更新数据库）用 Step Functions 编排，支持重试和错误处理

需要注意的坑

超时与内存

Lambda 最长执行 15 分钟，最大内存 10GB。如果你的文件处理任务可能超时，必须提前规划异步方案（Batch、Fargate），而不是寄希望于调大超时时间。内存配置直接影响 CPU 算力——1.5GB 以下每 128MB 内存对应一个 vCPU，超过 1.5GB 后 CPU 算力线性增长，图片和文档处理建议至少 1GB。

冷启动

函数长时间未调用后再次触发会产生冷启动延迟，对于 /tmp 挂载 EFS 的函数冷启动更明显。如果对延迟敏感，可以使用 Provisioned Concurrency 预热实例，但要权衡成本。

大文件处理

Lambda 接收的 payload 最大 6MB（同步调用），所以大文件不能通过请求体传入函数。必须使用预签名 URL 直传 S3，然后通过 S3 事件触发 Lambda 从 /tmp 或流式读取处理。视频等超大文件应直接走 MediaConvert 或 Batch。

安全

  • S3 Bucket 策略必须严格配置，禁止公开读写，使用最小权限原则
  • 预签名 URL 设置合理的过期时间（上传 1 小时、下载 5 分钟）
  • 文件上传前验证类型和大小，防止恶意文件上传
  • Lambda 执行角色只授予必要的 S3 操作权限
标签：Serverless