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

EN

解决这个特殊问题或困境取决于有关当前体系结构的一些信息。

• 你的微型服务如何相互沟通？您是否使用命令/查询作为对某个队列的直接调用和事件？
• 你的主数据有多大？是某种配置还是少量的已兑现数据被用作某种常量或设置？

如果您的通信机制之一是异步处理来自某个队列的事件，并且您没有处理大量经常更改的数据，那么我的建议是：

1.创建一个专用的主数据微服务.这个微服务将是您的主数据的所有者.这将是允许对其内部实体进行直接改变的唯一办法。

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

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

Pros:

使用这种方法，您将只有一个主数据的真实来源。所有其他微服务只会使用他们所需要的主数据微服务中的数据或数据子集。其他他们可以忽略的数据。另一个优势是，您的微服务可以自己操作，而不需要直接调用主数据微服务来获取它需要的一些数据。

Cons

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

关于您提供的选项的一些评论：：

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

我从上面提出的建议已经部分地涵盖了这一做法，只是没有直接的电话。假设你会使用队列。即使您不使用队列，您也可以通知使用主数据微服务的微服务和一些通知系统，然后让它们调用您的主数据微服务来获取最新的数据。而不是对每一个需要主数据的微服务内部的操作进行调用。那将非常低效。

将主数据作为单独的微服务承载:优点:主数据的单一来源。缺点:影响性能，因为当查找发生时，它总是通过有线进行服务调用。

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

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

我不建议这么做。为什么不这样做有很多原因。有些你已经提过了。在进行此操作时，需要考虑的一件事是，对于多个微服务，您将加入一个单一的故障点。这违背了微观服务的主要原则之一。

我们所遵循的方法之一，如下所示；

1. 创建主数据实体的逻辑分组，这样我们就不会创建超级大的MONOLITH Microservice。
2. 通过Microservice提供对逻辑分组主实体的管理(创建/更新/删除/读取)。因此，我们有5到6个微服务管理不同逻辑组的主数据实体。
3. 当任何功能模块请求主数据实体时，它首先在Redis Cache中查找它，如果找不到，则调用对应于引用数据逻辑组的获取API微服务。
4. Microservice的Fetch API实现了将主数据实体放入Redis Cache中。这样，对同一实体的任何后续请求都将在Redis缓存中为其他功能模块提供。
5. Redis缓存是在请求为Fetch API或值对象被更新时更新的。

优点

1. 所有值对象都是从Redis Cache集中访问的。
2. Redis缓存提供了更快的读取速度，而不是每次通过主数据实体的获取API。

缺点

1. 识别单个主数据实体的关键需要传达给其他功能模块。