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