这是我参与「第三届青训营 -后端场」笔记创作活动的的第6篇笔记
前言
这里对抖音demo大项目过程中投稿思路的迭代做出相应记录
一、v1.0
方案：直接上传到本地
具体实现：我们后端拿到前端的接口会有一个file类型的data，通过对文件的一些open，close之类的相关方法，把文件存到本地，视频封面的话通过ffmpeg直接截取第一帧生成.jpeg格式缩略图存储到本地（文件名用uuid生成）
二、v2.0
方案：增加对象存储（七牛云，阿里云，腾讯云），同时也支持本地存储
具体实现：采用业界标准的aws-s3为事实标准，因为目前几乎所有的云厂商的对象存储都支持aws-s3的接口协议。无论哪个厂商的对象存储都可以直接使用aws-sdk进行操作，开发者不需要额外去学习新的文档，既有的代码在迁移到其他厂商以后依然可以直接使用，具体操作就是在各个云存储服务器上创建bucket，生成accesskey，创建一个s3的客户端，通过返回的client的putobject方法构造所需的结构体上传，同时通过PreSign方法获取上传后在云服务器的url，把url再存到mysql里
三、v3.0
方案：文件从客户端直传 云服务器
具体实现： （1）客户端向服务端发送请求，获取直传云存储服务器的凭证。
（2）客户端向云存储上传文件，并携带该凭证。
整个“生成上传 OSS 凭证”过程，实际上做了这么几件事：
（1）上传凭证鉴权由 policy 提供，根据私密配置生成这个 policy 。
（2）由于上传环节脱离了开发者服务器，因此你可以在 policy 中定义各种限制，例如上传最大体积、文件名等。
（3）将 policy 转化为指定的格式。
优缺点：
从“客户端 — 服务器 — OSS”的传输模式，变更为“客户端 — OSS”的模式，最大的好处是，省掉了上传服务器的这一步，上传效率更高，速度更快（相比较于一般服务器的带宽，可以认为 OSS 的宽带是“几乎无限”的）。
当然该模式也有缺点，那就是增加了很多额外的开发工作量，主要包含 2 部分：
（1）服务端增加生成上传 OSS 凭证的代码。
（2）客户端增加从服务端获取上传 OSS 凭证的代码和对直传 OSS 进行适配。
整体而言，直传模式除了增加一点开发工作量以外，从架构层面，几乎没有任何缺点。
