每个搜索结果都说明了有关将图像存储在文件系统中但将路径存储在数据库中的信息，但是我不确定“文件系统”到底是什么意思。那是否意味着您有类似以下内容：
/public (assets)
/js
/css
/img
/app (frontend)
/server (backend)
并且您将直接上传到该/ public / img目录？
我记得过去曾经使用Heroku上托管的Node.js应用程序尝试过类似的操作，但它并没有阻止我。我必须设置Amazon S3并在那里上传图像，这引起了我的困惑。
是使用Amazon S3这样的常规方法还是人们是否直接将其上传到/ img目录（假设这是“文件系统”？），碰巧是Heroku不允许这样做，但其他主机可以这样做吗？
我将模式描述为“将数据存储在Blob存储服务中，将指针存储在数据库中”。上传的文件是“ blob”-一旦它离开了用户的计算机和文件系统，它真的是文件了吗？:)在服务器上，文件系统可以存储该“ blob”。S3可以存储该Blob。在第一种情况下，您要存储路径。在第二种情况下，您将存储S3对象的URL。数据库甚至可以存储该Blob（尽管不建议这样做，但是...）
无论如何，要问的问题是：“当我需要两个应用服务器来支持流量时会发生什么？”。无论该Blob到哪里，两个应用服务器都需要对其进行访问。
在您控制的数据中心中，有多种方法可在服务器之间共享文件系统-网络附加存储（NFS或SMB安装的卷）或存储区域网络（iSCSI，光纤通道）。由于基于云的基础架构/平台即服务提供商中的网络/硬件配置选项更加有限，事实上的标准是S3，因为它便宜，可靠，易于使用，并且可以从服务器上完全卸载文件服务。
但是，对于Heroku，您对文件系统没有太多控制权。并且，知道您的每个dyno的文件系统都是“短暂的”-dyno重新启动后它就会消失。当您的应用空闲或每24小时（以较早者为准）时，就会发生这种情况。这样就迫使选择了一点。
最后一点-S3附带了一些辅助好处，即减轻了为服务器提供Blob的负担。您也可以将文件从浏览器直接存储到S3，而无需通过应用程序进行路由（请参阅https://devcenter.heroku.com/articles/s3-upload-node）。两种情况下的好处是，这些下载/上载会占用应用程序宝贵的时间，以用于处理死记硬背的内容。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句