前端文件花式直传OSS!后端:那我走?

3,167 阅读4分钟

一. 简介

前端还在传文件给后端吗?你们的服务器扛得住吗?什么......老板砸钱加机器?!告辞!/狗头

前后端文件传输涉及数据较大,往往会成为很多项目的性能瓶颈。常见的传输方式也有不少,相对来说,OSS直传能够减轻很大压力。

本文我们来列举下常见的和oss直传的几种传输方式,并列举其优劣。

二. 常见方式

1. 表单上传

表单上传文件是最常见的方式,前后端开发小伙伴都很轻松,前端哐哐传,后端哐哐收就成了。其过程如下图所示。

form上传

优势:

  • 简单方便,开发量小
  • 前后端原生支持,无需额外第三方库支持

2. Base64上传

Base64方式上传文件,多常见于小文件,如小图片等,前后端都可直接使用String类型发送和接收。不过在前端,需要将文件转成base64数据,不仅会增加些性能消耗,还会增加传输数据的体积。而对于后端,如果并不是想直接存储base64数据,也还需要将其转成文件再存储,也会增加后端的性能消耗。

该上传方式可适用于Resetful Api,也可适用于文件的加密、回调接口携带文件等等。其过程如下图所示。

base64上传

优势:

  • 适用于Resetful Api,可用于加密、回调等场景,较为灵活

劣势:

  • 前后端文件与base64数据转换需要消耗性能
  • 只适用于小文件

三. OSS直传

此处的OSS直传方案都是使用的阿里云的OSS产品,以下将介绍三个方案,可适用于不同的场景。

1. Browser.js SDK上传

该方案可在前端直接通过browser.js上传文件到OSS,可分成三步:

  1. 前端使用SDK直传OSS
  2. 前端上传完成后请求后端,通知上传完成
  3. 后端检测OSS上该文件是否存在(可选)

其流程如下图所示。

browser直传

Browser.js的方式需要前端安装阿里云的库ali-oss,然后在前端调用。直传还需要OSS账户的Key和Secret,因此为了安全考虑,需要建立RAM账户,然后前端向后端先请求一个STS临时访问凭证来完成直传,其流程如下图所示。

browser直传2

2. Javascript客户端签名直传

Javascript客户端签名直传,需要先从后端获取临时签名,其流程与上一步的browser.js方案大致相同,不同点在于:

  • 无需第三方库支持,直接表单上传
  • 原生支持后端上传回调(下一步骤讲述)

其流程如下图所示。

javascript签名直传

不过该方案做下来,我感觉最大的问题是权限配置有点麻烦....../泪眼

3. 服务端签名直传并设置上传回调

该方案其实是上面方案——Javascript客户端签名直传的升级版本,其加上了后端的上传回调功能。不错呦~

前端需要改动的很少,只需要在请求参数中加上callback参数即可,该参数为后端加密,在签名请求的响应中一起返回回来,内加密了后端回调接口。在前端直传完成后,后端回调接口将会接收到相关文件参数,包括文件路径、大小、类型等。最后OSS会将回调接口response转发给前端,响应直传OSS的请求。

其流程如下图所示。

后端签名直传且回调

四. 对比

传统方式相比直传OSS,相对来说有三个缺点:

  • 上传慢:用户数据需先上传到应用服务器,之后再上传到OSS。网络传输时间比直传到OSS多一倍。如果用户数据不通过应用服务器中转,而是直传到OSS,速度将大大提升。而且OSS采用BGP带宽,能保证各地各运营商之间的传输速度。
  • 扩展性差:如果后续用户多了,应用服务器会成为瓶颈。
  • 费用高:需要准备多台应用服务器。由于OSS上传流量是免费的,如果数据直传到OSS,不通过应用服务器,那么将能省下几台应用服务器。

当然,对于规模较小、成本较低的项目来说,常见的上传方式还是适合的,毕竟没有最好的,只有最适合的。

五. 参考文档

六. 博客原文链接