7
各位大佬公司 OSS 文件存储是怎么做的？
source link: https://www.v2ex.com/t/786498
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
后端一枚之前 oss 相关基本都是配置在前端，直接上传换 url，然后后端存 url 现在新公司要用 oss，设计成了临时桶，数据库只存文件名，每次获取图片都要请求后端接口获取 url 。 而且公司还分了四个桶（数据库没存桶名）， 方案 1.导致每个桶写一个接口。问题前端不知道该文件名去哪个桶取，沟通成本大 方案 2.现在技术经理提出的，每个业务写一个接口给前端。前后端无意义的开发成本过高。
现在四个桶 2 个是存用户照片的，一个存业务文件，一个存 apk 。其实对前端来说只要知道哪些文件是走照片桶，其他统一走业务文件桶就可以了
一直没深究 oss，现在的云存储都这么复杂了么，还是说我们把简单问题复杂化了
6 条回复 • 2021-06-30 14:22:25 +08:00
flyslow 1 天前
两个方案：
1. 架个中间 node 层，把根据文件名获取 url 的逻辑封装在这一层，返回给前端的数据就是完整的 url，前端就可以避免来回请求，浪费性能和降低用户体验。具体哪些桶走照片桶，哪些桶走文件桶，这些都可以在 node 中间层里做配置化。这个设计对于 UI 前端，把 OSS 的细节都屏蔽了。
2. 不敏感的图片、文件，直接 CDN 化。首先配置 OSS 的 CDN 功能。另外约定每个桶的上传规则，同类型的桶尽量规则一致。使用时前端根据规则直接拼接出 URL，拼接过程可以封装成组件或 util 函数。
1. 架个中间 node 层，把根据文件名获取 url 的逻辑封装在这一层，返回给前端的数据就是完整的 url，前端就可以避免来回请求，浪费性能和降低用户体验。具体哪些桶走照片桶，哪些桶走文件桶，这些都可以在 node 中间层里做配置化。这个设计对于 UI 前端，把 OSS 的细节都屏蔽了。
2. 不敏感的图片、文件，直接 CDN 化。首先配置 OSS 的 CDN 功能。另外约定每个桶的上传规则，同类型的桶尽量规则一致。使用时前端根据规则直接拼接出 URL，拼接过程可以封装成组件或 util 函数。
jingslunt 23 小时 59 分钟前
问题是数据库没存桶名吧，这类文件会非常多，建议还是存 es 里。只能把图片的桶合并成一个，然后存包含桶的完整路径。如果不整成完整的路径，只能按方案二了。
oss 确实复杂，可以看部署 csi 存储的例子 https://drive.google.com/file/d/19T_15PUuXiMXlN71lkVbtdWBlOIajxt_/view
oss 确实复杂，可以看部署 csi 存储的例子 https://drive.google.com/file/d/19T_15PUuXiMXlN71lkVbtdWBlOIajxt_/view
IvanLi127 23 小时 59 分钟前
我觉得给到前端的地址得是完整的 url，从一开始返回的时候就应该返回完整的 url 而不是文件名。数据库存什么数据是后端的自由，但是给出去的数据得是完整的，除非有特殊的理由。
所以，如果没有专门做 BFF 的话，你们还是把地址拼好了返回出去吧。
最后。。。我一直没看懂楼主两个方案是啥意思。。。
所以，如果没有专门做 BFF 的话，你们还是把地址拼好了返回出去吧。
最后。。。我一直没看懂楼主两个方案是啥意思。。。
qwe520liao 23 小时 50 分钟前 
2
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 ）的方式来统一处理，否则会有大量重复枯燥的代码。
2 、SDK 上传完毕后，提交表单把 URL 路径信息提交至业务服务器，业务服务器直接保存 URL 路径。
3 、读取的时候，只需要 URL 路径，后端就可以拼接域名+路径得到完整的访问路径，如果是私有的则需要加上访问 Token，那么后端只需要提供一个根据 URL 路径得到访问链接的通用接口即可，前端就可以调用这个接口批量转换解析。
将上传和解析链接独立出来，成为一个通用的接口，业务使用上就可以直接保存 URL 路径，而不必重复上传或解析的工作，前端也可以根据这两个通用的接口得到自己想要的数据。
在调用生成 Token 这个接口上面，可以自定义参数，比如使用场景、文件类型限制等等，方便与 OSS 进行集成，接口在获取这些信息以后就可以生成对应的 Token 以及准备上传文件的 URL 路径，或其他前端需要在上传阶段需要得到的信息。
如果需要区分不同的桶，则可以在保存的 URL 路径上增加特定的前缀，这样解析服务就可以知道这个 URL 路径到底是哪一个桶的，不过不推荐这样做，不同的业务应该使用各自不同范围的服务，而不是一个大统一的跨项目的通用接口。
至于为什么不在业务数据直接返回的时候直接拼接，这取决于前端的需要，其实前端可以合并请求一次性获取。另外就是如果在后端进行拼接，那么每一个接口都需要知道域名等信息，我的建议是不要把业务数据的 URL 路径当做是一个路径或者链接，而应该把它当做一种特定格式标识符，标识符是需要被二次解析的。想象一下如果返回的数据中不仅要包含 URL，还要包含文件名以及大小上传时间等，跟业务数据的耦合性就比较大。或者这一步至少通过一个过滤器来完成，通过注解（ Java ）的方式来统一处理，否则会有大量重复枯燥的代码。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK