客户端直传与上传签名

为什么推荐直传

如果所有文件都先经过业务服务，再转发到对象存储，业务服务仍然要承担上传带宽和连接压力——只是把「存」换成了「转发」，问题没解决。

更好的方式是客户端直传对象存储：

客户端 -> 业务服务：申请上传凭证
客户端 -> 对象存储：直传文件或分片
对象存储 -> 回调/事件：通知业务服务
业务服务 -> 数据库：更新文件状态

业务服务不再处理大流量文件内容，只处理控制面逻辑。

两种方式对比

上传签名怎么做

直传的关键是签名。业务服务签发一个短期有效的上传凭证，对象存储只认这个签名：

签名里通常包含：

• 允许写入的对象 key 前缀（限定路径，防止写错位置）。
• 过期时间（如 15 分钟，过期失效）。
• 大小上限、内容类型等约束。
• 签名本身的 HMAC 校验值。

这样业务服务不用每字节都经过，但每个字节的「允许写入」都由它控制。

直传的时序

直传的安全要点

• 签名短期有效，防止被拿去写任意位置。
• 对象 key 白名单前缀，防止绕过业务规则。
• 上传完成后由服务端确认（回调或主动查询），不能只信客户端。
• 回调接口要防伪造（校验签名 / 来源）。

小结

客户端直传是「控制面 / 数据面分层」的落地：业务服务发「入场券」，对象存储管「仓库」，两边用签名和回调衔接。下一节看对象 key 怎么设计、元数据一致性怎么保证。

上一章节

为什么把文件从业务服务拆出去

下一章节

对象 key 设计与元数据一致性