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

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.

嗯，我不知道＆＃34; omni-channel＆＃34;是的，我无法回答这个问题。

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