Dependencies 微服务输入和输出域模型

我使用Kafka来解耦我的服务，但我对服务消费和产生输入输出的方式有一些想法

如果我有一个服务a，它使来自某个外部服务的数据脱离我的控制，我将被迫适应外部系统提供的数据格式（域）。按照这种做法，我的服务A将其结果以自己的格式（域）推送到主题

顺便说一句，我有一个服务B，它做的事情与服务a类似，但使用一些其他外部服务，并且有自己的数据格式（域），它将其推送到一个单独的主题

现在，A和B生成的数据的语义相似，但不相同。但是，管道中的下一步是服务C，它应该消耗a和B产生的东西，用它做点什么，然后输出结果

C是否应该只知道如何使用来自一个地方的数据，这意味着A&B（以及未来的任何其他公司）需要在C特定的领域中生成其输出？这意味着，如果C消费者改变了它的域名，A、B和任何其他制作人都将不得不改变，这是我不喜欢的。另外，如果我加上另一个消费者，例如D，这意味着A和B，用这个类比，应该知道D也是他们的消费者，这在我看来很可怕

我认为C应该负责它的输入，这意味着它依赖于a和B模型（以及可能产生自己数据的任何其他模型）。 它还意味着，当添加一个新的源时，必须更改C以包含该数据

实际上，我倾向于使用多个源OneSink组件，而不是单源多个Sink

---

是否有任何首选做法？

您的每个服务都应该使用最适合其特定业务逻辑的数据格式

用于集成目的：

• 入站通道适配器

  -在数据进入服务时将其转换为所需格式

• 出站通道适配器

  -在退出服务时将数据转换为所需格式

---

更多信息：

在选择集成模式之前，需要从战略层面分析业务子域、维护这些服务的团队、谁拥有什么、您希望模型如何发展等

我建议先看一下的上下文映射部分，然后由Hohpe和Woolf来具体实现

有没有什么可取的做法

消息规范

也就是说，您可以将它们转换为消息格式mA、mB和mC，而不是将A、B和C相互耦合。只要（mA、mB、mC）兼容，这些服务就能够相互通信

实现这一点的一种方法是将mA、mB和mC限制为同一模式的不同“版本”，其中模式的演化受到限制

• 在初始版本之后，不能添加新的必填字段
• 可选字段应具有默认值
• 使用者应忽略无法识别的字段
• 字段可以不推荐使用，但永远不会重复使用（例如，请参阅）

格雷格·杨的书专门用一章阐述了这一观点。当您查看各种标准化消息序列化（Avro、协议缓冲区等）时，您将看到类似的想法

一个服务是否应该针对自己的主题生成输出，并使依赖的服务从中消费，或者反之亦然，或者第三个选项

大多数情况下，这是管道——我们如何从一个系统到另一个系统获取消息的副本

---

从概念上讲，您似乎希望C使用a和B生成的一组逻辑消息。因此，我认为直接的问题是，您当前是否有来自a的相同消息的消费者不希望来自B的消息，或者反之亦然。如果这是您所知道的唯一用例，那么将内容简化为单个主题可能会有好处。

您所谈论的是上下文映射。BCs之间的关系。上游和下游侧。在两个BC之间的关系中，决定哪一个是上游和下游不是您的选择。它们本身就是。您可以选择如何集成（使用RESTAPI、使用事件、同步、异步等）。您应该绘制一张背景图，确定哪种战略模式适用于BCs之间的每种关系，并决定如何实施。

源/汇又如何？一个服务是否应该针对自己的主题生成输出，并使依赖的服务从中消费，或者反之亦然，或者第三个选项？