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

Question

在 mictoservices 的颗粒化方面，已经阅读了 2 个披萨规则、可以在 2 周内开发的服务等。当阅读 amazon、nelflix、gilt 的案例研究时，我们听到了大约 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 等。至少我们正在这样做。