微服务和数据复制

我正在构建一个新的应用程序，并且正在阅读有关微服务架构的信息。从开发，部署和生命周期管理的角度来看，体系结构本身很有意义。但是出现的一个问题是关于如何处理主数据。

例如，我有2个应用程序-例如销售应用程序和票务应用程序。假设这两个应用都是作为自己的微服务构建的。但是，这两个应用程序在部署时（假设分别部署，例如Sales使用MongoDB，Ticketing使用MariaDB），则需要访问相同的主数据实例，例如Accounts，Products。这意味着将有一个给定主数据实体的所有者应用程序（例如，对于帐户，可能是销售应用程序）和一个有兴趣的一方（例如，票务应用程序将需要有关帐户的信息）。

有多种方法可以实现：-从主方到感兴趣方的数据复制-从感兴趣方到主方的同步读取（微服务体系结构范例不建议同步依赖性）-自己的集中式存储库

即使在客户中，也可能有一个核心部分，对于销售和票务都是通用的（例如，帐户名，地址等）。但是，帐户的某些方面可能仅与销售相关，而其他方面仅与票务相关。

关于上述任何选项有什么想法/最佳实践/意见吗？

我是一个使用服务总线成功构建微服务架构的团队的成员。

最初，我们认为微服务和事件驱动的体系结构将使我们能够修复基础的共享数据泥潭数据库。

我们了解到的是，微服务和事件驱动的体系结构要求我们摆脱底层的共享数据球状数据库。

我相信，使用微服务很难很好地共享数据-对我来说，这是很难的。我建议不要让服务看到彼此的数据。如果无法查询，就不会意外引入依赖关系。

如果你 确实共享数据，那么肯定只有一项服务可以拥有一条记录。它是唯一写入记录的服务，并且同一数据的任何其他用户都应该具有只读访问权限。

不幸的是，即使管理的共享量很少，也会在您的服务之间引入巨大的耦合。如果一项服务不想要这种形状的数据怎么办？也许它想要一个汇总。您是否获得了“所有者/写入”服务来写入汇总数据以使另一个服务受益？我不建议。

如果所有者希望以其他形式保存数据怎么办？然后，每个阅读器服务都需要更新。那是维护的噩梦。

我们最好的解决方案是对数据进行大量重复和非规范化处理。微服务维护自己关心的数据副本。

消息通常带有足够的伴随数据进行发布以进行处理。

例如，您可能会想像一个邮政寄送服务可能需要跟踪对客户地址的更改，以防万一它需要寄出一些东西。但是，如果您的“准备发货的邮件”消息将目标地址作为消息数据的一部分包含在内，则发货服务将不再需要跟踪与客户相关的更改地址；只是与发货相关的时间点地址。

我不能建议如何设计具有同步数据的解决方案。我们的数据解决方案是围绕“最终一致性”的思想构建的。

因此，当客户更新其地址时，地址服务会处理来自UI的初始命令。一旦其数据正确，它将发布事件以通知所有其他感兴趣的服务“客户地址已更新”-带有完整的地址作为数据。这些服务将使用它们关心的部分数据来更新自己的数据存储。

想法是，每当服务必须采取重要行动时，它都应拥有足够最新的信息副本，以使其能够正确执行，独立跟踪或作为其响应消息的一部分。

共享数据存储将与微服务体系结构背道而驰。关键是，如果有帐户，则应该有一种服务来处理它们，并且除了提供全面的服务之外，没有其他与这些帐户进行交互的方式。如果您的微服务共享公用存储，并且它们对存储机制，验证或其他约束的任何更改都需要在两种服务中实施，它们将不是独立的。实际上，这种情况永远不会发生，并且很快会导致两个应用程序都无法进行任何重大更改。

因此，使用服务作为访问数据的唯一方法，例如“帐户”。可能会发生，在其他某些服务中实现功能需要更改“帐户”服务，这没关系。请记住，特定于任何服务的逻辑应包含在该服务中，并且应将尽可能少的特定内容放入Accounts微服务中。

将需要访问相同的主数据实例，例如帐户，产品

不一样。每个微服务都应该对帐户，产品等进行自己的映射。我们假设每个微服务将使用不同的方式与实体进行合作。

在域驱动设计中，这很常见，其中每个有界上下文（在同一应用程序中！）可以以不同的方式映射同一实体。

如果您需要更多信息，建议您阅读《构建微服务：设计细粒度的系统》一书。

您是否考虑过基于主集的骨架记录的概念？

例如，一个微服务处理帐户，另一个处理产品。三分之一可能出于其特定领域的目的而保留两者的记录。