Architecture 微服务中的数据复制

我们正试图从单一体系结构转变为微服务体系结构。我们想到了将我们的服务分开的最佳方式，并开始一个接一个地这样做。现在我们有一个问题，我们应该如何进行依赖调用。让我详细解释一下

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

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

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

我们可以考虑两种办法来处理这个问题

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

• 另一种方法是使用pub/sub复制服务本身中事务和订单微服务所需的部分数据。因此，基本上类似于order microservice中的一个新表，并在服务中加入一个连接来服务数据。从而消除了进行依赖调用的需要

那么首先，服务的分离是正确的吗？

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

注意：我们有大约10个服务依赖于items数据库。

---

此外，页面上通常会调用5-6个微服务。好的是，我们有自己的网关，可以并行地进行所有调用。因此，如果我们使用第一种方法，最多会有2个连续调用。

除了遵循最佳实践之外，在体系结构中没有正确的答案。当数据驻留在多个服务中并且必须加入它们时，在我看来，通过调用不同的微服务来聚合数据并不是一种好的做法，因为这会扼杀松耦合服务的用途。所以在你的情况下，这是第二种设计

---

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

当我们想要查看用户完成的事务列表时=>这基本上是审计和最终分析

如果您试图解决确切的问题，那么将来当您考虑将其扩展到更具分析性的需求时，您将遇到困难（例如，您决定对用户选择进行更多研究）

---

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

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

如果我错了，请纠正我，但这里的情况有所不同。我不必在这里参加。这就像打电话给MS并得到结果一样。结果具有多个相关实体的ID。为了获得相关实体的详细信息，我必须调用resp MS.vs.将该数据的副本存储在多个位置。如果您调用多个服务以适应单个请求，则其加入。想象一下，您的一个依赖的微服务已关闭。即使在其他服务启动时，您也无法与请求竞争，因此必须避免它的依赖性。如果您的客户端请求正在调用多个服务，则不建议使用这种方法。您可以创建投影/只读模型，也可以将数据保留在微服务中。这确实是一种互通有无的方法，但即使您需要一些复制，也要尽量使您的服务独立。复制并不意味着您需要复制所有数据。想象一下，预订服务可以有订单状态（它在预订服务本身中），但当用户单击订单详细信息时，您只能呼叫其他服务以获取详细信息。imgaine订单服务已关闭，但您的预订服务仍然能够显示预订状态，因为订单状态已存在。因此，这是一种互谅互让的方法