【问题标题】:Architecture : Microservices file upload , Service vs Facade架构:微服务文件上传,服务与门面
【发布时间】:2019-03-29 20:29:23
【问题描述】:

我有一个微服务架构,它的服务很少,并且在它上面有一个外观层。

现在我想给它添加文件上传功能。 所以基本上我会为它提供一个微服务,它的职责是将文件上传到本地服务器,创建不同版本的图像

我对架构有几个问题: a) 文件上传调用:应该从哪里触发这个调用,外观或单个微服务

b) 验证/安全性:所有验证都应该出现在哪里,调用服务或文件上传服务(根据我的文件上传服务)

c) 是否有已定义的文件上传模式。

【问题讨论】:

  • 您在询问上传,但您知道如何提供这些文件吗?
  • 我有一个单独的媒体服务器来托管这些文件。

标签: architecture microservices


【解决方案1】:

a) 文件上传调用:这是非常主观的.. 视情况而定。门面在做什么?它只是将请求重定向到正确的微服务吗?很多时候有一条灰线;我总是更喜欢能给我带来更好性能的设计。如果添加额外的啤酒花没有给我任何灵活性;我会避免的。

b) 在这里我可以给你一个明确的答案。始终每个微服务都应该是自包含的。我们不知道将来谁会调用我们的服务。我们永远不应该假设一个特定的客户对其进行编码。因此,所有的验证都应该是我们微服务的一部分。这里的异常可以是身份验证服务;有时我们有独立的微服务,但即使是令牌验证也应该发生在单个微服务中。

c) 没有为此定义的设计模式。

【讨论】:

  • 对于 a) 点,外观充当聚合器。它调用 n 个服务,聚合响应并将最终响应发送给用户。
  • 所以你是说外观是你所有 REST 端点的单点联系。无论如何这都是正确的设计。
  • 那么我应该从门面或单个服务调用文件上传吗?
  • 为了保持一致性; UI 应该调用外观,然后调用微服务。确保调用是在内部 IP 地址上,而不是使用公共 IP,以减少不同服务之间以及外观和微服务之间的延迟。