我在第三方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的资源获取”，记得关注我哦～）
