分析探讨微服务迁移如何影响数据库管理和分解数据库的步骤

在从单体式架构迁移到微服务架构时，数据库通常是事后想法。有些人认为迁移仅涉及应用逻辑的重组，而底层数据保持不变。但是，这种做法可能会导致单体式服务和微服务的尴尬混合：分布式单体服务。

微服务模型使基础架构和数据存储发生深刻变化。在微服务模型中，从传统应用程序中拉出服务，并为其提供独立性，在这种情况下，团队也必须考虑其基础数据库，并将其分解为特定于服务的数据源。

让我们看一下微服务迁移如何影响数据库管理，并探讨分解数据库的步骤。

按服务模式的数据库

在微服务架构中，大型数据湖需要转型为分布式数据库，以匹配特定服务。这样做可在只需要访问原始数据库特定部分的各个服务间创建必要的关注点分离。这也可帮助管理自己服务集的团队维持所需的独立控制。

根据Praful Todkar建议的模型，分解单体数据库需要与其所支持的服务同时进行-有时称为按服务模式的数据库。这应该是逐步的过程，并要求团队：

从单体中分离出单个服务，并将流量路由到它;

分离相同数据库中的表，并将其与该服务匹配;

在该表旁边创建新的较小的数据库，并将流量路由到它;

从原始数据库中删除先前的数据和架构。

分离服务和表

在微服务迁移期间，重组整个数据库有点像在驾驶汽车的同时更换轮胎。这样做可能会导致各种故障，并增加丢失数据或破坏功能的机会。

正确的做法是，从小处着手，在旧架构与新微服务间进行逻辑分离。当你选择要从单体中移除的服务后，创建一个新数据表（或多个表），其中仅包含新服务所需的数据。

在此步骤中，明确的路由规则至关重要。首先团队需要将流量从单体应用程序重新路由到新的微服务。然后，他们必须将旧的单体数据库的部分转移到表中，这最终将构成新数据库的框架。所有这些都需要现代的联网功能，例如由Istio等工具实现的服务网格方法。

当将分离的表转换为新的分布式数据库时，奇偶校验也至关重要。请确保新旧数据库中的数据已完全同步。在确认数据奇偶校验后，从以前的数据库中删除表和旧数据。

使用模式是便于管理，但不能过于依靠

模式是元数据集，用来描述数据库内数据的结构。有些团队更喜欢按模式整理数据，为每个服务创建独有的数据库模式，而不是整个数据库。这种方法有着无可争议的好处，因为要管理的数据库更少，并且它们之间的统一性更高。

但是，这种做法非常接近单体式数据湖模型，而我们正试图远离这种模型。如果有选择的话，即使看起来客观上适得其反，开发人员和架构师也会倾向于熟悉的方法。他们会做出妥协并遵循按服务模式做法。但是请记住：只要有可能，最好为每个服务都设置专用数据库，而不要依赖总体架构。

微服务最好的部分是，它使你可以将专用数据库分配给某些服务，而将共享数据库用于其他服务。该决定通常取决于服务的重要性及其处理的数据类型。团队结构也在这里发挥作用。有些服务要求管理它们的团队具有严格的自治权，而其他服务最好在多个团队之间共享。

为微服务选择最佳数据库 通常，单体是构建大型关系数据库上。当迁移到微服务时，为新架构选择数据库是重大决定。

现在有很多数据库选项，包括：

键值数据库

文档存储数据库

图形数据库

基于列的数据库

每种类型的数据库模型都适合特定类型的数据管理需求。例如，键值数据库和列式数据库最适合结构化数据，图形适合半结构化数据，而文档存储则最适合非结构化数据。

请记住，每种数据库类型的读写速度都不同，围绕不同数据库的供应商工具也不同。在选择任何一种数据库类型或工具集前，请使用样本数据运行测试。例如，对于需要实时性能的服务，将需要具有强大内存性能的数据库。

尽管企业正在迁移到微服务，但是关系数据库不会很快消失。出于各种原因，很多应用程序的某些部件在传统架构中运行时性能最佳，并且将依赖于旧的单体数据库来运行。好消息是微服务支持这种数据库管理的多类型模型。因此，不要仅仅因为其他服务正在迁移到微服务，而试图将应用程序的每个部分从单体中移出。
责编AJX