微服务 web api 应用程序 - 领域驱动设计：有大量重复数据正常吗？

Question

所以我正在尝试掌握微服务。据我了解，每项服务都应该代表自己。 在我的示例中，我有一个Unit.API 和一个Combat.API。 Unit.API db 包含大约 1,000,000 个不同的单元。

现在如果我想在Combat.API 中计算/创建一个战斗日志，我需要知道哪个用户使用了哪些单位。

方法 0：据我了解的方法错误：
在控制器的 post 方法中，我将所有 unitId 作为参数获取，然后调用 Unit.API 以获取单位。

方法 1：正确的方法？：
我的Combat.API 中有来自Unit.API 的每个单元的副本。在控制器的 post 方法中，我获取所有 unitIds 作为参数，并从Combat.API db 获取战斗单元“副本”。每当一个单位发生变化时，我必须将一个事件从 Unit.API 发送到 Combat.API 以在那里进行相同的更改。

方法2：也错了？：
在控制器的 post 方法中，我直接通过参数获取所有单位。

我认为方法 1 实际上是正确的，但对我来说感觉是错误的。每分钟可能对单位进行数千次更改，我必须发送数千个事件才能保持其他数据库的更新。什么是正确的？

Answer 1

方法 0： 这似乎是最轻量级的解决方案，但在这里您将面临一种“基础设施耦合”。这是什么意思？这意味着，当 Unit.Api 出现故障或损坏时，Combat.Api 也将无法工作，因为它依赖于单元服务。

方法 1： 这是一种“按部就班”的解决方案。您复制数据，但由于您拥有独立的服务。

方法 2： 对我来说似乎是解决方法 :)

首先，如果您要进入微服务架构，您应该以拥有独立服务为目标。但在某些情况下，它们之间的丰富通信也可能成为瓶颈且难以维护。

到目前为止，我遇到了不同的方法，与您提到的完全相同。在选择最好的选项之前，您应该考虑风险和复杂性，这取决于您是否同意哪个选项，并意识到缺点。

另外，我觉得你应该再看看你的架构...我不知道Unit.API的用途和目的是什么，但是如果它只被Combat.API使用，也许它应该是一个微服务/有界上下文？