各位大佬公司 OSS 文件存储是怎么做的？

[bingyiyu]

后端一枚之前 oss 相关基本都是配置在前端，直接上传换 url，然后后端存 url 现在新公司要用 oss，设计成了临时桶，数据库只存文件名，每次获取图片都要请求后端接口获取 url 。 而且公司还分了四个桶（数据库没存桶名）， 方案 1.导致每个桶写一个接口。问题前端不知道该文件名去哪个桶取，沟通成本大 方案 2.现在技术经理提出的，每个业务写一个接口给前端。前后端无意义的开发成本过高。

现在四个桶 2 个是存用户照片的，一个存业务文件，一个存 apk 。其实对前端来说只要知道哪些文件是走照片桶，其他统一走业务文件桶就可以了

一直没深究 oss，现在的云存储都这么复杂了么，还是说我们把简单问题复杂化了

[flyslow]

两个方案：
1. 架个中间 node 层，把根据文件名获取 url 的逻辑封装在这一层，返回给前端的数据就是完整的 url，前端就可以避免来回请求，浪费性能和降低用户体验。具体哪些桶走照片桶，哪些桶走文件桶，这些都可以在 node 中间层里做配置化。这个设计对于 UI 前端，把 OSS 的细节都屏蔽了。
2. 不敏感的图片、文件，直接 CDN 化。首先配置 OSS 的 CDN 功能。另外约定每个桶的上传规则，同类型的桶尽量规则一致。使用时前端根据规则直接拼接出 URL，拼接过程可以封装成组件或 util 函数。

[jingslunt]

问题是数据库没存桶名吧，这类文件会非常多，建议还是存 es 里。只能把图片的桶合并成一个，然后存包含桶的完整路径。如果不整成完整的路径，只能按方案二了。

oss 确实复杂，可以看部署 csi 存储的例子 https://drive.google.com/file/d/19T_15PUuXiMXlN71lkVbtdWBlOIajxt_/view

[IvanLi127]

我觉得给到前端的地址得是完整的 url，从一开始返回的时候就应该返回完整的 url 而不是文件名。数据库存什么数据是后端的自由，但是给出去的数据得是完整的，除非有特殊的理由。
所以，如果没有专门做 BFF 的话，你们还是把地址拼好了返回出去吧。
最后。。。我一直没看懂楼主两个方案是啥意思。。。

[neptuno]

为啥要这么设计呢？听上去前端增加了很多无用的请求（应该不是为了反爬吧？因为你最后还是能拿到图片 url 的）

[timethinker]

1 、前端请求服务器（通用接口），获取 Token 以及文件 URL 路径信息，此 Token 用于调用 OSS 云存储 SDK 传入，Token 一般是 Base64 编码后的一长串字符串，SDK 上传至 OSS 云服务器，OSS 云服务器负责校验 Token 以及解析 Token，并根据元信息（业务后端生成 Token 时指定的桶、文件名称）把文件放到指定的位置。这个 Token 类似 JWT 这种结构，里面包含了元信息以及签名。
2 、SDK 上传完毕后，提交表单把 URL 路径信息提交至业务服务器，业务服务器直接保存 URL 路径。
3 、读取的时候，只需要 URL 路径，后端就可以拼接域名+路径得到完整的访问路径，如果是私有的则需要加上访问 Token，那么后端只需要提供一个根据 URL 路径得到访问链接的通用接口即可，前端就可以调用这个接口批量转换解析。

将上传和解析链接独立出来，成为一个通用的接口，业务使用上就可以直接保存 URL 路径，而不必重复上传或解析的工作，前端也可以根据这两个通用的接口得到自己想要的数据。

在调用生成 Token 这个接口上面，可以自定义参数，比如使用场景、文件类型限制等等，方便与 OSS 进行集成，接口在获取这些信息以后就可以生成对应的 Token 以及准备上传文件的 URL 路径，或其他前端需要在上传阶段需要得到的信息。
如果需要区分不同的桶，则可以在保存的 URL 路径上增加特定的前缀，这样解析服务就可以知道这个 URL 路径到底是哪一个桶的，不过不推荐这样做，不同的业务应该使用各自不同范围的服务，而不是一个大统一的跨项目的通用接口。

至于为什么不在业务数据直接返回的时候直接拼接，这取决于前端的需要，其实前端可以合并请求一次性获取。另外就是如果在后端进行拼接，那么每一个接口都需要知道域名等信息，我的建议是不要把业务数据的 URL 路径当做是一个路径或者链接，而应该把它当做一种特定格式标识符，标识符是需要被二次解析的。想象一下如果返回的数据中不仅要包含 URL，还要包含文件名以及大小上传时间等，跟业务数据的耦合性就比较大。或者这一步至少通过一个过滤器来完成，通过注解（ Java ）的方式来统一处理，否则会有大量重复枯燥的代码。

[Rocketer]

参考业界成熟方案呗，比如 S3，数据库里就是只存 file key