architecture - 微服务中的数据复制

Question

我们正在尝试从单体架构转向微服务架构。我们考虑了隔离我们的服务的最佳方法，并开始一一这样做。现在我们有一个关于如何进行依赖调用的问题。让我详细解释一下。

假设我们有不同的微服务。其中一个包含有关产品的详细信息。其他微服务围绕产品展开，因此它们将成为交易、订单、报价等的服务。所有微服务都使用 gRPC 进行通信。

所有这些服务都将引用具有项目详细信息的项目微服务(引用将通过 ID 完成)。因此，其他每个服务都将只有项目的 ID。

现在的问题(或者可能不是)是，当我们想要查看用户完成的交易列表时，我们还需要项目的详细信息。类似的订单列表，我们再次需要项目的详细信息。 (不是所有细节，而是其中一些细节)。

我们可以考虑两种选择来处理这个问题。

一是进行两次后续调用，一次调用交易或订单微服务，然后调用商品微服务以获取所需的部分详细信息。在这里，我们拥有自己的网关，在性能和网络方面都非常高效。

另一种是在服务本身中使用事务和订单微服务所需的pub/sub复制部分数据。所以基本上类似于订单微服务中的新表并加入服务以提供数据。从而消除了进行相关调用的需要。

那么首先，服务的隔离是否恰当？

第二 2 种方法中哪一种是更好的设计

注意:我们有大约 10 个服务依赖于 items 数据库。
同样在一个页面上，通常会调用 5-6 个微服务。好消息是我们有自己的网关，可以并行进行所有调用。所以如果我们使用第一种方法，最多会有 2 个连续调用。

Answer 1

在架构中没有正确的答案，只能遵循最佳实践。当您的数据驻留在多个服务中并且必须加入它们时，在我看来，通过调用不同的微服务来聚合它不是一个好习惯，因为它破坏了松散耦合服务的目的。所以在你的情况下，它是第二种设计。

如果您要实现松散耦合，保留其他服务的重复数据并不是一个坏习惯。对您的设计的另一个修改可能是使用 CQRS/事件源。您将转储事件存储中的所有事件并从该事件存储创建只读模型/投影。这是非常强大的模式，但请注意，这是复杂的模式，可能会矫枉过正。