微服务中的数据复制

Question

我们正在尝试从单片架构过渡到微服务架构。我们想到了隔离服务的最佳方法，因此开始一个接一个地进行。现在我们有一个关于如何进行依赖调用的问题。让我详细解释。

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

所有这些服务将引用具有项目详细信息的项目微服务（通过ID进行引用）。因此，每个其他服务将仅具有该项目的ID。

现在的问题（也许不是）是，每当我们希望查看用户完成的交易列表时，我们还需要这些物品的详细信息。同样地，下订单清单，我们同样需要这些物品的详细信息。 （不是所有的细节，而是其中的一些）。

我们可以考虑两个选项来处理此问题。

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

• 另一个是使用事务所需的pub / sub复制部分数据，并在服务本身中订购微服务。因此，基本上像订单微服务中的新表，并加入服务中的表以提供数据。这样就消除了进行依赖调用的需要。

那么首先分离服务是否正确？

第二种，哪种方法是更好的设计

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

Answer 1

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

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

Answer 2

当我们想查看用户完成的交易列表时，=>这基本上是审计，并最终进行分析。

如果您尝试解决确切的问题，那么将来在考虑扩展它，具有更多分析类型的需求（例如，您决定对用户选择进行更多研究）时，将会遇到困难。

当您过渡到微服务模式时，一种更好的方法是让您当前的服务进入审核的所有详细信息中，事件将是此处的最佳选择，因此您的审核（或将来的分析模块）可以独立工作。因此，如果所有服务都产生了审计/报告目的所需的必要事件，则可以构建一个处理其余事务的审计/报告微服务-是的，它将复制数据，但始终可以更好地保持审计远离实际数据。

Answer 3

使用第二个选项“使用发布/订阅复制部分数据”。只有这样，您的微服务才能真正实现自治并通过减少网络调用来实现更好的性能。