Django DRF项目AWS S3代理下载性能优化方案咨询

安全阿岳

2026-8-27

问题说明

当前维护的Django + DRF项目内置媒体处理模块，作为代理层对接AWS S3实现文件上传下载，避免前端直连S3访问资源。现下载请求平均耗时在400-600ms区间，存在生产环境性能风险，核心疑问包括：

是否有可行方案提升该类请求的响应速度
是否需要将下载逻辑拆分到异步微服务或多进程任务中
该类场景的通用最佳实践是什么

现有下载逻辑核心代码如下：

# media_app/services/download/image.py
class ImageDownloadService(FileDownloadServiceBase):
    model = Image


# media_app/services/download/base.py
class FileDownloadServiceBase:
    model = ...

    def __init__(self, instance: str) -> None:
        self.instance = instance

    def _get_file(self, presigned_url):
        response = requests.get(url=presigned_url, stream=True)
        return response

    def download(self) -> Tuple[file_data, status_code]:
        s3 = boto3.resource(
            service_name='s3',
            aws_access_key_id=settings.AWS_ACCESS_KEY_ID,
            aws_secret_access_key=settings.AWS_SECRET_ACCESS_KEY,
            region_name=settings.AWS_S3_REGION_NAME,
        )
        url = s3.meta.client.generate_presigned_url(
            ClientMethod="get_object", ExpiresIn=3600,
            Params={
                "Bucket": settings.AWS_STORAGE_BUCKET_NAME,
                "Key": f'media/public/{self.instance.file_name}',
            },
        )
        response = self._get_file(url)
        return response.content, response.status_code

性能瓶颈定位

现有实现的耗时主要来自三个可优化点：

每次下载请求都重新初始化S3客户端，没有复用HTTP连接池，TLS握手、鉴权协商的固定开销占总耗时的30%左右
代理逻辑采用"用户->Django->S3->Django->用户"的全链路中转模式，且开启stream=True后仍然将整个文件读取到Django服务内存再返回，多了一次全量内存拷贝和两段额外的网络传输开销
预签名URL每次实时生成、没有配置HTTP缓存策略，重复请求无法利用浏览器、边缘节点的缓存能力，所有请求都穿透到后端服务和S3源站

优化方案

首先明确：该场景不需要拆分异步微服务或多进程任务。文件下载是用户同步等待的即时请求，异步任务无法减少中转链路的传输开销，反而会引入任务状态轮询、链路排障复杂度提升等额外问题，投入产出比极低。

可按优先级落地以下优化：

S3客户端全局复用
将boto3 S3客户端的初始化逻辑从请求处理方法中移出，在项目启动时初始化一次全局单例。boto3客户端本身是线程安全的，配合连接池配置可以直接复用长连接，单次请求可以减少100-200ms的建连开销。参考实现：

import boto3
from botocore.config import Config

# 全局初始化，随项目启动加载
s3_client = boto3.client(
    service_name='s3',
    aws_access_key_id=settings.AWS_ACCESS_KEY_ID,
    aws_secret_access_key=settings.AWS_SECRET_ACCESS_KEY,
    region_name=settings.AWS_S3_REGION_NAME,
    config=Config(
        connect_timeout=5,
        read_timeout=10,
        max_pool_connections=50  # 根据服务并发量调整
    )
)

流式响应替代全量内存加载
不要将S3返回的文件内容全量读到内存后再返回，改用流式响应边从S3读边转发给用户，同时透传S3返回的Content-Type、Content-Length等响应头，首包延迟可以降低30%以上。Django/DRF中直接使用StreamingHttpResponse即可实现该逻辑。
预签名URL短周期缓存
当前生成的预签名URL有效期为1小时，可以将生成结果缓存50分钟（略短于有效期避免过期），同一文件的重复请求直接读取缓存的签名结果，省掉每次签名计算的开销。
补全HTTP缓存头
给图片这类静态资源响应添加合适的Cache-Control头，比如Cache-Control: public, max-age=86400，允许浏览器、CDN节点缓存资源，重复请求根本不会打到Django服务，这是收益最高的优化手段，命中缓存的请求耗时可以降到个位数毫秒级。

场景最佳实践

如果代理层的核心诉求是做权限校验、隐藏S3源站地址，优先采用重定向方案：用户请求下载接口时，Django只做权限校验，校验通过后直接返回302重定向到生成好的预签名S3 URL，让用户直接和S3建立连接下载文件。该方案下Django不需要承载任何文件流量，接口耗时可以稳定在10ms以内，也不会占用服务的出口带宽。
如果因为合规、内网隔离等要求必须让所有文件流量经过自有服务，不要用Python应用层做流量中转，在服务前端部署Nginx或CDN，将S3配置为回源站，Django只负责做权限校验、生成带鉴权信息的回源规则，静态资源流量全部由Nginx/CDN处理，转发性能比Python层高两个数量级。
不要为该场景单独拆分微服务：不管是单体还是微服务，只要是应用层做流量中转，本质的开销没有区别，拆分反而会增加运维成本和链路复杂度。

内容的提问来源于stack exchange，提问作者Dmitriy Lunev