我开发的应用程序包含以下内容：
在实现类似文件存储的功能时，为了上传小文件和大文件，我只是假设我将这些文件存储在微服务的文件系统上，并将路径与元数据一起保存到微服务的数据库中。
由于微服务未实现任何 Http API 端点，因此我通过 API 网关上传文件。但在意识到将这些文件从 API 传输到微服务以及提供相同的服务需要做多少工作之后，我只是将它们存储在 API 的文件系统上并将路径保存到微服务的数据库中。
这个方法可以吗？
我的 API gateway 从它自己的文件系统存储和提供文件，这很奇怪吗？ 如果是这样，我是否应该在上传时将文件从 API 传输到微服务，即使考虑到文件可能很大 - 还是微服务本身应该实现特定的 API？
我希望这个问题不会被解释为基于意见 - 我想知道考虑前端 API 微服务模式哪种方法最好，以及是否有任何架构标准可以解决这种情况，以及是否有这种方法有其陷阱。
基于上面的评论
API网关
网关的目的是重定向请求并处理横切问题，例如身份验证、日志记录等。它不应该做更多的事情。网关必须具有高可用性，网关出现任何问题都意味着您无法访问相关服务。
文件上传
文件上传应由微服务本身处理。您的网关将仅用于传递和获取流。根据您的系统的性质，如果您使用云存储，您可以使用“代客钥匙”等模式。 https://learn.microsoft.com/en-us/azure/architecture/patterns/valet-key
经过一段时间和一些经验，这个问题的正确答案是API网关。微服务本身就足够复杂，存储任何文件，无论大小，都会浪费网络、带宽等，只会引入延迟问题并降低性能和用户体验。
我将其留在这里只是为了让人们能够听到这一点，因为这两种方法都不会错，而 API 网关的选择只是提供了更实际的好处，因此更合适。如果这个问题的目标是存储在数据库中的数据或文件，那么微服务及其数据库将是显而易见的选择。
如果您可以方便地将文件服务器添加到整个堆栈中，那么当然，这将是正确的方法，但这也会引入更多的复杂性和上述其他内容。