微服务模式将极大地改变基础架构和数据存储. 在微服务模型中，在从传统应用程序中提取服务并提供独立性的情况下，团队还必须考虑其基础数据库，将其分解为服务固有的数据源。
看看微服务迁移如何影响数据库管理，讨论一下分解数据库的步骤吧。
按服务模式分类的数据库
在微服务架构中，大数据湖必须迁移到分布式数据库以支持特定的服务。 这样可以在只访问原始数据库的特定部分的服务之间创建必要的注视点分离。 这也有助于管理自己的服务集的团队保持必要的独立控制。
根据Praful Todkar提出的模型，要分解单元数据库，必须与它支持的服务同时进行。 有时称为按服务模式分类的数据库。 这是一个逐步的过程，必须要求小组：
从单体中分离个别服务，路由流量。
分离同一数据库中的表并与服务匹配。
在此表旁边创建一个新的小数据库并路由通信。
从原始数据库中删除以前的数据和方案。
把服务和桌子分开
在微服务过渡期间，重组整个数据库就像在驾驶汽车的同时更换轮胎一样。 这样做可能会引起各种故障，增加丢失数据和破坏功能的机会。
正确的做法是从小开始在旧架构和新微服务之间进行逻辑分离。 选择要从单元中删除的服务时，将创建一个只包含新服务所需数据的新数据表(或多个表)。
在这一步中，明确路由规则很重要。 首先，团队需要将流量从单元应用程序重新路由到新的微服务。 然后他们必须把旧的单元数据库的一部分转发到表中，最终构成新数据库的框架。 所有这些都需要现代网络功能，包括通过Istio等工具实现的服务网格方法。
在将分离的表转换为新的分布式数据库时，奇数奇偶校验也很重要。 请确保新旧数据库中的数据是完全同步的。 确认数据奇偶校验后，从以前的数据库中删除表和旧数据。
使用模式容易管理，但不要太依赖。
方案是描述数据库中数据结构的元数据集。 有些团队喜欢按模式组织数据，以便为每个服务而不是整个数据库创建自己的数据库模式。 这种方法没有争议，因为要管理的数据库很少，统一性很高。
但是，这种方法非常接近单体式数据湖模型，我们试图远离这个模型。 如果有选择，即使看起来客观相反，开发者和设计师也倾向于习惯使用方法。 他们妥协，遵循服务模式。 但是，如果可能的话，最好为每个服务设置专用的数据库，而不依赖于整体体系结构。微服务的最好部分是可以将专用数据库分配给特定服务，并将共享数据库用于其他服务。 这个决定通常取决于服务的重要性及其处理的数据类型。 团队结构也在这里工作。 有些服务要求管理它们的团队具有严格的自治能力，但建议在多个团队之间共享其他服务。
要选择最适合微服务的数据库，通常需要单独构建大规模的关系数据库。 在迁移到微服务时，为新体系结构选择数据库是重要的决定。
现在有很多数据库选项，包括：
关键值数据库
文档存储数据库。
图表数据库。
基于列的数据库
每种类型的数据库模型都适合特定类型的数据管理需要。 例如，键值数据库和列数据库最适合结构化数据，图形最适合半结构化数据，文档存储最适合非结构化数据。
请注意，每个数据库类型的读写速度都不同，每个数据库的供应商工具也不同。 在选择其中一种数据库类型或工具集之前，请使用示例数据运行测试。 例如，需要实时性能的服务需要一个具有强大内存性能的数据库。
企业正在向微服务转移，但关系数据库不会立即消失。 由于各种原因，许多应用程序的某些组件在传统体系结构中性能最高，依赖于旧的单元数据库运行。 好消息是微服务支持这种数据库管理的多类型模型。 因此，除了其他服务正在迁移到微服务外，不要试图从单元中删除应用程序的各个部分。
中文
电话咨询
微信咨询
公众号
