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

Question

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

关于数据存储的几个问题

就备份而言，这不是一个巨大的维护问题吗？
恢复等？

初始数据如何填充到这些存储中？是否有任何最佳实践？组织必然拥有大量的客户或产品数据，它们很可能会在其他系统中掌握。

这种多数据存储的方法如何影响“全 channel ”方法，它意味着获得所有数据的单一 View ？组织可能已经实现了数据整合计划来实现相同的目标

编辑:稍微编辑了主题

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.

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

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