微服务中的数据复制

Posted 2023-03-08

【中文标题】微服务中的数据复制

【英文标题】：Data replication in microservices

【发布时间】：2019-07-18 15:06:58

【问题描述】：

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

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

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

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

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

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

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

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

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

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

【参考方案1】：

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

【参考方案2】：

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

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

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

【参考方案3】：

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

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

【讨论】：

如果我错了，请纠正我，但不知何故，这里的情况有所不同。我不必在这里加入。这就像打电话给 MS 并得到结果。结果具有多个相关实体的 id。要获取相关实体的详细信息，我必须致电 resp MS。 vs 在多个位置存储该数据的副本。

如果您正在调用多个服务以适应单个请求，则它的加入。想象一下您的一个依赖微服务已关闭。即使其他服务启动，您也无法竞争请求，因此必须避免依赖。如果您的客户请求正在调用多个服务，那么不推荐使用这种方法。您要么创建预测/只读模型，要么将数据保留在微服务中。这确实是一种给予和接受的方法，但即使你需要一些重复，也要尽量让你的服务独立。

复制并不意味着您需要复制所有数据。想象一下预订服务可以有订单状态（它在预订服务本身中）但是当用户单击订单详细信息时，您才调用其他服务来获取详细信息。 imgaine 订单服务已关闭，但您的预订服务仍然能够显示预订状态，因为订单状态在那里。所以它是给予和采取的方法