微服务范式中的主数据管理策略 [英] Master Data Management Strategies in Microservices paradigm
问题描述
致力于将一个巨大的单体应用程序迁移到微服务范式，不用说域识别和映射到不同的微服务和编排是一项艰巨的任务.现在，由于以前的应用程序在同一架构中共享主数据，因此在新范式中，我很难管理它，我的选择是:
Working on migrating a huge monolithic application to microservices paradigm, needless to say the domains identification and mapping then to different microservices and the orchestration has been quite a task. Now as the previous application shared the master data in the same schema, in the new paradigm it gets difficult for me to manage that, my choices are:
- 在每个微服务中复制相同的主数据: 优点:当缓存在应用程序中运行速度快且无需查找时，应用程序本身就充当了真正的事实来源.缺点:特定服务中主数据的任何更新都可能导致服务之间尝试使用此数据进行通信时的不一致，主数据的更新可能会导致严重的一致性问题.
- 将主数据作为单独的微服务托管: 优点:主数据的单一来源.缺点:影响性能，因为它总是在发生查找时通过网络调用服务.
- 创建分布式缓存并将其公开给多个微服务:将打破微服务数据的单一来源或真实"原则，但可以通过实现写入来确保性能和一致性.
以上任何想法或任何实施策略都会真正有帮助...
Any thoughts on above or any implementation strategies would really help...
维巴夫
推荐答案
此特定问题或困境的解决方案取决于有关您当前架构的一些信息.
Solution for this particular problem or dilemma depends on some information about your current Architecture.
你们的微服务是如何相互通信的?您是否将命令/查询用作某个队列上的直接调用和事件?
How do your micro-services communicate with each other? Are you using Commands/Queries as direct calls and events over some queue?
你的主数据有多大?是某种配置还是少量现金数据用作某种常量或设置?
How big is your master-data? Is it some sort of configuration or small amount of cashed data which is used as some sort of constants or settings?
如果您的通信机制之一与事件异步完成来自某个队列，并且您没有处理大量经常更改的数据，那么我的建议是:
If one of your communication mechanisms is done asynchronous with Events coming from some Queue and you are not dealing with huge amount of data which is very frequently changed then my recommendation would be to:
1.创建专用的主数据微服务.此微服务将是您的主数据的所有者.这将是唯一一个允许直接更改其中的实体.
1. Create a dedicated master-data-micro-service. This micro-service would be the owner of your master-data. It would be the only one which would allow direct changes on the Entities inside it.
2.将事件发布到主数据微服务中每个实体的更改队列. 每当有人在主数据微服务中创建、更新或删除实体时，您都会将事件发布到有关这些更改的某个队列.
2. Publish events to a queue on changes on every Entity in master-data-micro-service. Whenever someone creates, updates or deletes entities in master-data-micro-service you would publish events to some queue about those changes.
3.订阅主数据微服务事件.所有其他需要主数据微服务数据的微服务将订阅它使用的实体的事件并将它们本地保存在其数据库中.此数据或主数据的子集将保存为本地使用的副本.只有当主数据微服务的真实来源"发布它们已更改的事件时，这些主数据实体才能随这些事件一起更改.任何其他类型的更改都将被禁止，因为它会在该数据的本地副本与其在主数据微服务中的真实来源之间产生差异.
3. Subscribe to master-data-micro-service events. All other micro-services who need the master-data-micro-service data would subscribe to the Events of the Entities it uses and saves them locally in its database. This data or subset of master-data would be saved as a copy for local usage. This master-data Entities can only be changed with these events when their "source of truth" the master-data-micro-service publishes events that they have been changed. Any other type of change would be forbidden as it would create a difference between local copy of that data and its source of truth in the master-data-micro-service.
优点:
采用这种方法，您的主数据将只有一个真实来源.所有其他微服务只会使用它们需要的主数据微服务中的数据或数据子集.他们可以简单地忽略其他数据.另一个优点是您的微服务将能够独立运行，而无需直接调用主数据微服务来获取所需的一些数据.
With this approach you would only have one source of truth for your master data. All other micro-services would only use the data or subset of data from the master-data-micro-service which they need. Other data they can simply ignore. Other advantage is that your micro-service would be able to operate on its own without calling the master-data-micro-service directly to get some data it needs.
缺点
缺点是您需要在多个微服务中复制数据.另一个问题是您需要处理分布式系统的复杂性，但您已经在这样做了 ;)
The drawback is that you would need to duplicate data in multiple micro-services. The other problem is that you need to deal with the complexity of a distributed system, but you are already doing this ;)
对您提供的选择的一些评论:
在每个微服务中复制相同的主数据:优点:缓存时在应用程序中运行速度快且无需查找，应用程序内本身就是真实的真实来源.缺点:master 上的任何更新特定服务中的数据可能会导致不一致，而服务正在尝试使用这些数据相互通信，主数据的更新会导致严重的一致性问题
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.
我上面的建议已经部分涵盖了这种方法，只是没有直接调用.假设您将使用队列.即使您不使用队列，您也可以通过一些通知系统通知使用主数据微服务的微服务，然后让他们调用您的主数据微服务获取最新信息数据.并且不要调用需要主数据的微服务中的每个操作.那将是非常低效的.
My suggestion from above already covers this approach partly, only without the direct calls. Assumption was that you would use a queue. Even if you don't use a queue you could notify the micro-services which use the master-data-micro-service with some notification system and then and only then let them call your master-data-micro-service the get the latest data. And not do a call on every operation which is inside micro-service which requires master-data. That would be very inefficient.
将主数据作为单独的微服务托管:优点:单一主数据的来源.缺点:影响性能，因为它总是发生查找时通过线路调用服务.
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.
我从上面建议的方法是结合这个方法和关于在每个微服务中复制数据的第一点.
My suggested approach from above is a joined approach with this and your first point about replicating data in each micro-service.
创建分布式缓存并将其公开给多个微服务:将打破数据的单一来源或真相"原则微服务，但可以确保性能和一致性通过实现编写.
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 个加入的单点故障.这违背了微服务的主要原则之一.
I would not recommend doing this. There are many reasons why not. Some you already mentioned. One thing to consider when doing this that you will have 1 joined single point of failure for multiple micro-services. That is something which goes against one of the main principles of micro-services.
这篇关于微服务范式中的主数据管理策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
