microservices - 微服务范式中的主数据管理策略

Question

致力于将庞大的整体应用程序迁移到微服务范式上，不用说域标识和映射，然后再映射到不同的微服务和编排是一项艰巨的任务。
现在，由于先前的应用程序以相同的模式共享主数据，因此在新的范式中，我很难对其进行管理，我的选择是:

在每个微服务中复制相同的主数据:优点:当缓存在应用程序中时可以快速运行并且没有查找时，其内部的应用程序充当真实的真实来源。缺点:特定服务中主数据的任何更新都可能导致不一致，而服务尝试使用此数据相互通信时，对主数据的更新可能会导致严重的一致性问题。

将主数据托管为单独的微服务:优点:主数据的单一来源。缺点:性能高，因为查找时总是通过线路进行服务调用。

创建分布式缓存并将其公开给多个微服务:会打破微服务数据的“单一源真相”原则，但可以确保性能和一致性是直写式实现。

对以上任何想法或任何实现策略都将真正有帮助...

韦巴哈夫

Answer 1

解决此特定问题或困境的方法取决于有关当前体系结构的一些信息。

您的微服务如何相互通信？
您是否将命令/查询用作某些队列上的直接调用和事件？

您的主数据有多大？
是某种配置还是少量的现金数据用作某种常量或设置？

如果您的一种通信机制与“事件”异步完成
来自某些Queue，并且您不处理大量经常更改的数据，那么我的建议是:

1.创建专用的主数据微服务。
该微服务将是您的主数据的所有者。这将是唯一一个可以直接对其内部实体进行更改的实体。

2.在主数据微服务中，将每个实体上的更改发布到队列中。 每当有人在主数据微服务中创建，更新或删除实体时，您都将事件发布到有关这些更改的队列中。

3.订阅主数据微服务事件。
需要主数据微服务数据的所有其他微服务都将订阅它使用的实体的事件，并将它们本地保存在其数据库中。该数据或主数据的子集将被保存为副本以供本地使用。仅当主数据微服务的“真相源”发布了已更改的事件时，才可以使用这些事件来更改此主数据实体。任何其他类型的更改都将被禁止，因为它将在该数据的本地副本与其在主数据微服务中的真实来源之间造成差异。

优点:

使用这种方法，您的主数据将只有一个真实来源。所有其他微服务将仅使用其需要的主数据微服务中的数据或数据子集。他们可以简单地忽略其他数据。另一个优点是您的微服务将能够独立运行，而无需直接调用主数据微服务来获取所需的一些数据。

缺点

缺点是您将需要在多个微服务中复制数据。另一个问题是您需要处理分布式系统的复杂性，但是您已经在这样做了；)

对您提供的选择的一些评论:

Replicate the same master data in each microservice: Pros: when cached in the application works fast and no looksup, application within itself acts as a true source of truth. Cons: Any updates on master data in a particular service could lead to inconsistencies while the services are trying communicate among each other using this data, the updates to the master data can cause serious consistency problems across.

我从上面的建议已经部分地涵盖了此方法，只是没有直接调用。假设您将使用队列。即使您不使用队列，您也可以通过一些通知系统通知使用主数据微服务的微服务，然后才让它们调用您的主数据微服务以获取最新信息。数据。并且不要在微服务内部需要主数据的每个操作上进行调用。那将是非常低效的。

Have the master data hosted as a seperate microservice: Pros: Single source of master data. Cons: Hit on performance since it always a service call over the wire when a lookup happens.

我从上面建议的方法是一种与之结合的方法，这是您在每个微服务中复制数据的第一点。

Create a distributed cache and expose it to multiple microservices: would break the "Single Source o Truth" principle of data for microservices but could ensure performance and consistency being a write through implementation.

我不建议这样做。不这样做的原因有很多。您已经提到了一些。执行此操作时要考虑的一件事是，对于多个微服务，您将有1个加入的单点故障。这与微服务的主要原则之一背道而驰。