本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 将业务逻辑从数据库迁移到应用层
<a name="logic"></a>

将业务逻辑从数据库存储的过程、触发器和函数迁移到应用层服务是分解单体数据库的关键步骤。这种转型提高了服务自主性，简化了维护并增强了可扩展性。本节提供有关分析数据库逻辑、规划迁移策略，然后在保持业务连续性的同时实施转型的指导。它还讨论了如何制定有效的回滚计划。

**Topics**
+ [第 1 阶段：分析业务逻辑](#logic-analysis)
+ [第 2 阶段：对业务逻辑进行分类](#logic-classification)
+ [第 3 阶段：迁移业务逻辑](#logic-migration)
+ [业务逻辑的回滚策略](#logic-rollback)

## 第 1 阶段：分析业务逻辑
<a name="logic-analysis"></a>

在对整体数据库进行现代化改造时，必须首先对现有的数据库逻辑进行全面分析。本阶段侧重于三个主要类别：
+ *存储过程*通常包含关键业务操作，包括数据操作逻辑、业务规则、验证检查和计算。作为应用程序业务逻辑的核心组件，它们需要仔细分解。例如，金融组织的存储过程可能会处理利息计算、账户对账和合规性检查。
+ *触发器*是处理审计跟踪、数据验证、计算和跨表一致性的关键数据库组件。例如，零售组织可能使用触发器来管理整个订单处理系统的库存更新，这表明了自动化数据库操作的复杂性。
+ 数据库中的@@ *函数*主要管理数据转换、计算和查找操作。它们通常嵌入在多个过程和应用程序中。例如，医疗保健组织可能使用函数来标准化患者数据或查找医疗代码。

每个类别都代表嵌入在数据库层中的业务逻辑的不同方面。您需要仔细评估和规划每一项才能将其迁移到应用层。

在此分析阶段，客户通常面临三个重大挑战。首先，复杂的依赖关系是通过嵌套过程调用、跨架构引用和隐式数据依赖关系出现的。其次，事务管理变得至关重要，尤其是在处理多步骤事务和在分布式系统之间保持数据一致性时。第三，必须仔细评估性能注意事项，特别是对于批处理操作、批量数据更新和实时计算，这些问题目前受益于接近数据。

为了有效地解决这些难题，可以使用 [AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html) 进行初步分析，然后使用详细的依赖关系映射工具。这种方法可以帮助您了解数据库逻辑的全部范围，并创建全面的迁移策略，在分解过程中保持业务连续性。

通过全面了解这些组件和挑战，您可以更好地规划现代化之旅，并就迁移到基于微服务的架构期间优先考虑哪些要素做出明智的决定。

分析数据库代码组件时，请为每个存储过程、触发器和函数创建全面的文档。首先要清楚地描述其目的和核心功能，包括其实施的业务规则。详细说明所有输入和输出参数，并记下它们的数据类型和有效范围。绘制与其他数据库对象、外部系统和下游进程的依赖关系。明确定义事务边界和隔离要求以维护数据完整性。记录任何性能预期，包括响应时间要求和资源利用模式。最后，分析使用模式以了解峰值负载、执行频率和关键业务时段。

## 第 2 阶段：对业务逻辑进行分类
<a name="logic-classification"></a>

有效的数据库分解需要按关键维度对数据库逻辑进行系统分类：复杂性、业务影响、依赖关系、使用模式和迁移难度。此分类可帮助您识别高风险组件、确定测试要求和确定迁移优先级。例如，具有高业务影响力和频繁使用的复杂存储过程需要仔细的规划和大量的测试。但是，依赖性最小的简单、很少使用的函数可能适用于早期迁移阶段。

这种结构化方法创建了一个平衡的迁移路线图，在保持系统稳定的同时，最大限度地减少了业务中断。通过了解这些相互关系，您可以改进分解工作的顺序并适当地分配资源。

## 第 3 阶段：迁移业务逻辑
<a name="logic-migration"></a>

在对业务逻辑进行分析和分类之后，是时候对其进行迁移了。将业务逻辑迁出单体数据库时，有两种方法：将数据库逻辑移至应用层，或将业务逻辑移至作为微服务一部分的另一个数据库。

如果将业务逻辑迁移到应用程序，则数据库表仅存储数据，数据库不包含任何业务逻辑。这是推荐的方法。您可以使用 [Ispirer****](https://aws.amazon.com/marketplace/seller-profile?id=seller-6w64f4cwyhmiw) 或生成式人工智能工具（例如 A [mazon Q](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) Developer）或[https://kiro.dev/](https://kiro.dev/)将数据库业务逻辑转换为应用程序层，例如转换为 Java。有关更多信息，请参阅[将业务逻辑从数据库迁移到应用程序以实现更快的创新和灵活性](https://aws.amazon.com/blogs/mt/migrate-business-logic-from-database-to-application-for-faster-innovation-and-flexibility/)（AWS 博客文章）。

如果将业务逻辑迁移到另一个数据库，则可以使用 [AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html) 将现有数据库架构和代码对象转换为目标数据库。[它支持专门构建的 AWS 数据库服务，例如亚马逊 Dynam [oDB、Amazon Aurora 和 Amazon](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) R [edsh](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html) ift。](https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html)通过提供全面的评估报告和自动转换功能， AWS SCT 有助于简化过渡过程，使您能够专注于优化新的数据库结构以提高性能和可扩展性。随着现代化项目的进展， AWS SCT 可以处理增量转换以支持分阶段的方法，从而使您能够验证和微调数据库转换的每个步骤。

## 业务逻辑的回滚策略
<a name="logic-rollback"></a>

任何分解策略的两个关键方面是保持向后兼容性和实施全面的回滚程序。这些要素相互配合，有助于保护过渡期间的运营。本节介绍如何在分解过程中管理兼容性，以及如何建立有效的紧急回滚功能以防范潜在问题。

### 保持向后兼容性
<a name="logic-rollback-backward-compatibility"></a>

在数据库分解过程中，保持向后兼容性对于平稳过渡至关重要。在逐步实现新功能的同时，暂时保留现有的数据库程序。使用版本控制来跟踪所有更改并同时管理多个数据库版本。规划较长的共存期，在此期间，源系统和目标系统都必须可靠运行。这为在停用传统组件之前测试和验证新系统提供了时间。这种方法可以最大限度地减少业务中断，并在需要时为回滚提供安全网。

### 紧急回滚计划
<a name="logic-rollback-plan"></a>

全面的回滚策略对于安全的数据库分解至关重要。在代码中实现功能标志，以控制哪个版本的业务逻辑处于活动状态。这使您无需更改部署即可在新实现和原始实现之间即时切换。这种方法可以对过渡进行精细控制，并帮助您在出现问题时快速回滚。将原始逻辑保留为经过验证的备份，并维护详细的回滚程序，其中指定触发器、职责和恢复步骤。

定期在各种条件下测试这些回滚方案，以验证其有效性，并确保团队熟悉应急程序。功能标志还可以通过有选择地为特定用户组或交易启用新功能来实现逐步推出。这为过渡期间提供了额外的风险缓解层。