微服务中的数据复制

Question

我们正试图从单一体系结构转向微服务体系结构。我们想到了什么是最好的方式来隔离我们的服务，并开始这样做，一个一个。现在，我们有一个问题，我们应该如何作出依赖的电话。让我详细解释一下。

假设我们有不同的微观服务。其中一个有关于产品的详细信息。其他微服务以产品为中心，因此它们将是用于交易、订单、报价等的服务。所有的微服务都使用gRPC进行通信。

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

现在的问题(或者不是)是，当我们希望看到一个用户完成的事务列表时，我们还需要项目的详细信息。类似的订单列表，再一次我们需要详细的项目。(不是所有细节，而是一些细节)。

我们可以想出两种办法来处理这个问题。

• 一种是进行两次后续调用，一次是对事务或订单微服务，而不是对项目微服务，以获得所需的部分细节。在这里，我们有我们自己的网关，它在性能和网络方面非常高效。
• 另一种方法是使用事务所需的pub/sub复制部分数据，并在服务本身中订购微服务。因此，基本上类似于order微服务中的一个新表，并在服务中使用一个连接来服务数据。从而消除了进行依赖调用的需要。

，所以首先，服务的隔离是正确的？

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

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

Answer 1

在架构中没有正确的答案，只有遵循最佳实践。当数据驻留在多个服务中并且必须加入它们时，我认为通过调用不同的微服务来聚合它并不是一个好做法，因为它扼杀了松散耦合服务的用途。所以在你的例子中，这是第二个设计。

如果要实现松散耦合，那么保持其他服务的重复数据并不是一种糟糕的做法。对您的设计的另一个修改可能是使用CQRS/事件源。您将在事件存储中转储所有事件，并从该事件存储中创建只读模型/投影。这是非常强大的模式，但请注意，这是一个复杂的模式，可能是过分。

Answer 2

使用第二个选项“使用pub/sub复制部分数据”。这是使您的微服务真正自主的唯一方法，并通过减少网络呼叫实现更好的性能。

Answer 3

当我们希望看到一个由用户=>完成的事务列表时，这基本上是审计，最终是analytix。

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

当您转向微服务模式时，这里的一个更好的方法将是让您当前的服务在审计中包含所有细节，而事件将是这里的最佳选择，这样您的审计(或未来的分析模块)就可以独立地工作了。因此，如果所有服务都产生审计/报告目的所需的必要事件，您可以构建一个处理其余部分的审计/报告微服务--是的，它将复制数据，但最好是使审计远离实际数据。