从单体架构迁移到微服务架构时，数据库通常是事后才想到的。有人认为迁移只是应用逻辑的重组，而底层数据保持不变。然而，这种方法会导致单体服务和微服务的尴尬组合：分布式单体服务。微服务模型给基础设施和数据存储带来了深刻的变化。在微服务模型中，服务从传统应用程序中提取并独立提供，团队还必须考虑其底层数据库并将它们分解为特定于服务的数据源。让我们看看微服务迁移如何影响数据库管理，并探索分解数据库的步骤。按服务模式分库在微服务架构中，需要将大型数据湖转化为分布式数据库，以匹配特定的服务。这样做会在只需要访问原始数据库特定部分的服务之间创建必要的关注点分离。这也有助于管理他们自己的服务集的团队保持所需的独立控制。根据PrafulTodkar建议的模型，分解单体数据库需要与其支持的服务齐头并进——有时称为逐个数据库的模型。这应该是一个循序渐进的过程，并且要求团队：将单个服务从整体中分离出来，并将流量路由到它；在同一数据库中分离一个表并将其与该服务匹配；在该表旁边创建一个新的、较小的服务；小型数据库并将流量路由到它；从原始数据库中删除以前的数据和模式。分离服务和表在微服务迁移过程中，重新组织整个数据库有点像开车时换轮胎。这样做可能会导致各种故障并增加丢失数据或破坏功能的可能性。正确的做法是从小处着手，从逻辑上将旧架构与新微服务分开。选择要从整体中删除的服务后，创建一个（或多个）新数据表，其中仅包含新服务所需的数据。在此步骤中，显式路由规则至关重要。首先，团队需要将流量从单体应用程序重新路由到新的微服务。然后，他们不得不将旧的单体数据库的一部分转移到表中，这些表最终将构成新数据库的骨架。所有这些都需要现代网络功能，例如Istio等工具支持的服务网格方法。将分离表转换为新的分布式数据库时，奇偶校验也很重要。请确保新旧数据库中的数据完全同步。确认数据奇偶校验后，删除表和之前数据库中的旧数据。使用模式易于管理，但您不能过分依赖它们。模式是用于描述数据库中数据结构的元数据集。一些团队更喜欢按模式组织数据，为每个服务而不是整个数据库创建唯一的数据库模式。这种方法具有无可争议的优势，因为需要管理的数据库更少，而且它们之间的一致性更高。但是，这种方法非常接近于我们正试图摆脱的单一数据湖模型。如果有选择，开发人员和架构师往往会倾向于熟悉的方法，即使它们在客观上看起来适得其反。他们做出妥协并遵循每项服务的方法。但请记住：只要有可能，最好为每项服务配备专用数据库，而不是依赖于整体架构。微服务最好的部分是它允许您为某些服务分配专用数据库并为其他服务使用共享数据库。该决定通常取决于服务的重要性及其处理的数据类型。团队结构也在这里发挥作用。有些服务需要管理它们的团队严格自治，而其他服务最好在多个团队之间共享。为微服务选择最好的数据库通常，整体构建在大型关系数据库上。在迁移到微服务时，为新架构选择数据库是一个重大决定。今天有许多数据库选项，包括：键值数据库文档存储数据库图形数据库基于列的数据库每种类型的数据库模型都适合特定类型的数据管理需求。例如，键值和列式数据库最适合结构化数据，图最适合半结构化数据，文档存储最适合非结构化数据。请记住，每种数据库类型都有不同的读写速度，不同数据库的供应商工具也是如此。在选择任何数据库类型或工具集之前，请使用示例数据运行测试。例如，对于需要实时性能的服务，将需要具有强大内存性能的数据库。尽管企业正在迁移到微服务，但关系数据库不会很快消失。由于各种原因，许多应用程序的某些部分在传统架构上运行时性能最佳，并且将依赖遗留的单一数据库来运行。好消息是微服务支持这种数据库管理的多类型模型。因此，不要仅仅因为其他服务正在迁移到微服务就试图将应用程序的每个部分都从单体中移出。
