architecture - 微服务中的数据复制

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

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

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

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

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

一种是进行两次后续调用，一次调用事务或订单微服务，然后调用商品微服务以获取所需的部分详细信息。在这里，我们有自己的网关，它在性能和网络方面都非常高效。
另一种是使用事务所需的发布/订阅复制部分数据，并在服务本身中订购微服务。因此，基本上类似于订单微服务中的新表，并加入服务以提供数据。从而消除了进行依赖调用的需要。

那么首先，服务的隔离是否正确？

其次，这两种方法中哪一种是更好的设计

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

标签： architecturemicroservices

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

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