微服务 - 维护多个数据存储,初始数据加载等

Question

关于mictoservices的颗粒化方面已经阅读了关于2比萨规则,可以在2周内开发的服务等.当亚马逊,nelflix,镀金的案例研究被阅读时,我们听到了大约100个服务.虽然服务粒度确实有意义,但对我来说仍然不清楚的是这些微服务中的每一个的数据存储.如果每个服务存储/维护自己的数据,是否会有太多的数据存储？它可能是相同的逻辑实体,如产品,客户等被切片的相关部分/属性由相应的微服务存储/维护.可能存在维护基本客户信息的服务,另一个维护其他客户信息的服务,例如他的订阅信息或他的兴趣等.

围绕数据存储想到几个问题

1. 这在备份,恢复等方面不会是一个巨大的维护问题吗？
2. 如何将初始数据填充到这些商店中？这周围有什么最好的做法吗？组织必然拥有大量的客户或产品数据,并且很可能在其他系统中掌握.
3. 这种多数据存储方法如何影响"全渠道"方法,它意味着获取所有数据的单一视图？组织可能已经开展了数据整合计划以实现相同目标

编辑:稍微编辑了主题

Answer 1

1.Will this not be a huge maintenance issue in terms of backups, restores etc?

从你的角度来看，是的，会的。我的意思是，最终您将不仅仅需要备份一台数据库服务器，而是需要备份数十或数百个数据库服务器。但大多数人（至少我们是这样做的）正在使用云数据库服务来摆脱所有这些维护工作。

2.How is the initial data populated into these stores ? Are there any best practices around this ? Organisations are bound to have huge volumes of customer or product data & they will most likely be mastered in other systems.

我不确定是否有最好的方法，但我们创建了一个客户端来从遗留系统中读取数据，然后将其转换并拆分为每个微服务的部分，并通过使用它们的服务将它们推送到这些微服务。我们使用消息队列来确保迁移的健康状况。

3.How does this approach of multiple data stores impact the 'omni-channel' approach where it implies getting a single view of all data? Organizations might have had data consolidation initiatives going on to achieve the same.

我不知道什么是“全渠道”，所以我无法回答。

最后您提到了服务之间共享的逻辑实体。实现微服务真正最困难的部分是定义每个服务将提供什么。在这样做的同时，您应该仔细检查每个服务的数据需求，并且这些服务应该尽可能少地共享，例如仅实体 ID 等。至少这就是我们正在做的事情。