微服务文件服务设计咨询

发布于 2022-09-13 01:10:21 字数 181 浏览 41 评论 0

想咨询各位几个问题,谢谢。
1、目前微服务框架内我想开发一个文件服务专门用于处理文件、OSS上传,目前考虑的是接入多家OSS对象存储提供商,方便后期切换,目前暂不考虑切换换文件的转移(暂时定靠人工上下载),数据库中文件路径是存储相对路径还是完整路径好呢?
2、是否需要设计一张附件表存储全部上传的文件,同1是存储相对路径还是完整路径呢?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

渔村楼浪 2022-09-20 01:10:21

【问题一】

用云存储的话一般是相对路径。

其实也压根不是路径了,而是 FileKey 这种文件标识,只不过长的看起来像路径。

存 FileKey 有两个好处:

  1. 替换服务商方便。绝大部分云存储供应商都会提供“源站克隆”、“源站迁移”(可能服务不叫这个名,但功能是这个功能)。也就是说,当你要换服务商时,只需要把新的存储桶的源站指向老的,剩下的就跟你无关了,你代码不需要改动任何一行(当然了配置项肯定得改)。
  2. 切换 CDN 方便。当某个 CDN 节点挂掉时,你可以迅速的通过修改配置文件的方式替换为其他的 CDN 节点,同样不需要你改一行代码。

当然你可能会说,“我存完整路径,需要切换时再在代码里手动 REPLACE 掉开头的域名什么的,不也行吗?”。这个问题就不回答了吧,你自己思考一下。


【问题二】

看你业务需求。

一般来说业务上用不到这个表,因为这个 FileKey 你还是得存到相应的实体表里。比如用户头像,你总不能用户表里只存个附件 ID、然后外键关联到这个附件表里吧?

所以这个表更大的用途是做日志查询用的。但如果数据量比较大的话其实关系型数据库不算是一个特别好的选择。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文