前言中我主要说明了“实施oss方案”的原因及最终要达到目的，今天这篇文章主要讲解的是：在前后端分离的项目中如何“与第三方oss系统对接上传功能”（由于前言中列出的上传方案中的前两种并不适用于稍微有点流量的系统，所以今天我直接讲解“前端->资源服务器/资源存储系统（比如oss）&资源服务器/资源存储系统（比如oss）与后端进行数据交互”方案）

我在第三方oss落地预研时主要经历了以下两个阶段：

不安全的直传方案

“oss直传”巧妙的避开了我司服务器资源的限制（所有虚线都表示用户无感知）

流程解读：

1. 前端直接对接oss服务的服务器，上传资源；（阿里云oss的SDK中提供了两种上传方式：简单上传【最大支持5G的资源对象】和分块上传【最大支持48.8TB的资源对象】；简单上传由于不支持断点续传，适合用于上传小文件；而分块上传支持断点续传，适合上传比较大的文件；一般超过100MB 的文件都推荐使用分块上传）；

2. oss服务接收到资源之后向在第三方系统中配置的回调地址中发送信息并接收结果；

3. oss服务将从回调地址中接收到的结果反馈给上传资源的前端站点；

4. 前端站点拿到上传的反馈信息之后继续业务流程；

在阿里云提供的该方案是将oss系统提供的accessId和accessKey暴露在前端js中（这一对信息是阿里云的授权账号信息，一旦泄漏，相当于你的oss可以被所有人使用），进而向bucket中放入资源信息。

该方案主要解决的是：所有资源不再通过我司自己的服务器的后端服务（比如nginx/php-fpm等）的中转处理，简约了上传流程、节省了我司的入网流量、保证了上传资源的完整性。

但同时，我想你肯定注意到了我在阐述oss系统提供的账号信息时重点描黑的几个字，肯定也在想：这样不就不安全、不经济了吗？！是的，你没有想错！！！所以在此基础上，我结合阿里云的STS认证产生了下面的方案（标红的地方是本方案加入的内容）：

比较经济、安全的直传方案

sts为oss的资源私有化提供了一层安全保证

流程解读：

1. 前端上传资源之前先从对应的后端API（后台API从我司oss服务包中拿取授权信息）中拿取到临时授权信息（STS认证信息-拥有时效性），而后直接对接oss服务的服务器，上传资源；

2. oss服务接收到资源之后向已经配置的回调地址中发送信息并接收结果；（当时做视频截帧就是在这一步把视频的第一帧地址返回的）

3. oss服务将从回调地址中接收到的结果反馈给上传资源的前端站点；

4. 前端站点拿到上传的反馈信息之后继续业务流程；

5. 在后续的业务操作中，前端将资源信息提交给后端API之后，后端API必须再次检验资源是否符合预期（扩展名、大小、是否真的在oss系统存在）

该方案中，我做了两步优化，一个是使用了具有时效性的临时认证信息，虽然上传时认证信息还是会被前端暴露，但其时效性增加了被利用的难度（oss系统的资源安全性不仅仅表现在账号信息是否被暴露，更重要的是单个资源是否会被未经授权的使用，这一方面会在“下载”篇章稍作说明）；第二个是针对前端上传给oss后，资源是否被业务所接受，所以会在业务后台检验资源是否存在、资源的类型和大小是否符合预期。

以上便是我预研时经历的两次方案变革，而真正在我司线上运行的是第三种：oss传输加速方案，即上传时使用传输加速扩展功能（整个上传流程不变，只不过在上传时使用了加速服务），由于这是一款阿里云提供的额外服务，并不在我所要阐述的基本流程中，且，其实流程是一样的，所以不再额外赘述。

最后，有两个小tips我想额外告诉你：

1. 有些有时间限制的但并不常改动的数据信息完全可以存储在类似于redis这种服务中，而不是每次都实时生成（比如临时授权认证信息）；

2. 我对接的阿里云oss是有“重名覆盖”问题的，所以尽可能地让前端将文件重命名后再上传（虽然现在可以开启资源版本功能，但是要钱啊！！！）；

而重命名也是有小技巧的：一般为了查找起来直观一些，会使用日期区分“文件夹”（阿里云oss的bucket其实没有“文件夹”这一概念的），但是官方文档中也给出了这样做的弊端“如果您在上传大量文件时，在命名上使用了顺序前缀（如时间戳或字母顺序），可能会出现大量文件索引集中存储于存储空间中的某个特定分区的情况。此时如果您的请求次数过多，会导致请求速率下降。出现这种问题时，建议您为Object的名称增加随机前缀”

（接下来的一篇中，我将为您阐述“如何对接第三方oss的资源获取”，记得关注我哦～）