前端文件花式直传OSS！后端：那我走？

一. 简介

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

前后端文件传输涉及数据较大，往往会成为很多项目的性能瓶颈。常见的传输方式也有不少，相对来说，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，可分成三步：

前端使用SDK直传OSS
前端上传完成后请求后端，通知上传完成
后端检测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，不通过应用服务器，那么将能省下几台应用服务器。

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

hunter-ji / Blog