微服务/职责之间的沟通

Question

我是微服务的新手，在阅读了很多文档后，我仍然对很多事情有些怀疑。我正在举例说明我现在想要实现的目标：

情境：

• 微服务架构。
• FileServer将存储来自多个来源的文件。
• 每个微服务都有自己的数据库。

TemplateService数据库：

• TemplateId（PK）：guid
• FileId（~FK）：guid
• TEMPLATENAME

FileService数据库：

• FileId（PK）：guid
• 文件名
• 路径

使用案例 用户想要将模板上传到应用程序。

问题：（和我的想法）

谁创建了GUID（FileId）？

1. UI创建GUID，并同时调用模板服务和文件服务。
2. UI调用模板服务，此服务创建GUID，然后调用文件服务

谁处理文件服务器？

1. UI将文件直接发送到FileServer（或者可能是另一个服务，如FileManager？）
2. UI将文件发送到FileService，此服务将其存储在FileServer中。

更新时间：2018/03/27

因此，对于UserInput SaveTemplate（），我的新设计看起来像这样。

Answer 1

考虑适合微服务架构的事件源模式（例如，使用Kafka作为事件存储） UI将文件发布到Kafka，然后另一个服务可以使用来自kafka的文件并存储文件。

Event Sourcing pattern， Event Sourcing with Kafka

Answer 2

1. 不要在客户端应用上生成GUID。这是一个坏主意，因为如果这通常是业务实现，应该包含在有界的上下文服务中。客户端UI应该尽可能薄而且愚蠢。
2. 我建议您为第2层/有界上下文API提供文件服务器。这将使他们独立于彼此的存在。

使用此设计还可以改进一些内容：

1. 考虑引入API聚合器。 API聚合器将负责实现从客户端应用程序到二级API的请求路由。这样做可以帮助您封装第2级（有界上下文服务），这使您可以灵活地交换级API。直接与专用于有界上下文的API通信的客户端应用程序会使您无法对这些API进行自主更改
2. 考虑实施Messaging Saga和Compensating Transactions

为了让您了解通常的微服务架构如何在这里看到我的一个设计的架构图：