微服务/职责之间的通信

Question

我是微服务新手，在阅读了很多文档之后，我仍然对很多事情有一些疑问。我举一个我现在想要实现的例子：

场景：

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

模板服务数据库：

• 模板 ID (PK)：guid
• FileId (~FK): guid
• 模板名称

文件服务数据库：

• 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

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

您还可以通过此设计改进一些内容：

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

为了让您了解通常的微服务架构是什么样的，这是我的一个设计中的架构图：

Answer 2

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

Event Sourcing pattern, Event Sourcing with Kafka