部署数据库迁移的策略

成功迁移现有数据

当更改数据库的实际结构时，通常需要修改现有数据以符合新的模式。在某些情况下，这相对简单。例如，如果您需要添加一个与现有数据无关的新表，则无需修改数据库中存储的任何内容。

在其他情况下，例如拆分或合并列，您必须定义自定义数据转换，以指定应如何更改现有数据以填充新上下文。对于处理大量数据的结构，此迁移过程可能需要大量时间。

使更改可逆

根据您的部署策略，使更改可逆也可能很困难。一旦数据结构被更新并由实时代码填充，恢复到以前的版本可能会导致数据丢失。

这使得在出现问题时“向前滚动”比“向后回滚”更具吸引力，因为即使行为本身被恢复，数据也可以在更新后的代码中被考虑在内。

测试模式更改

数据库更改涉及的另一个挑战是测试。可能很难理解以何种最佳方式测试模式更改，以捕获边缘情况并确保新数据格式的有效性。真实世界的数据通常会以意想不到的方式冲击约束的边界，因此重要的是要充分掌握潜在值的整个范围，以便编写考虑这些值的测试。

模式更改也可能影响数据库的其他部分，您需要对其进行测试，例如存储过程、触发器和其他组件。这些都需要在每次模式更改时进行测试，以确保它们仍然按预期工作。

性能和可用性影响

最后，模式更改可能很困难，因为它们可能对性能和可用性产生巨大影响。这类问题可能很难在测试环境中模拟，因为在测试环境中，数据集、请求负载和访问模式可能无法反映生产值。

在技术上可能有效的更改可能会带来无法接受的性能成本，这可能很难在暂存环境中推断出来。如果您的部署过程有可能影响可用性，那将是更大的问题。

计划内维护：使用停机时间升级模式

实现模式迁移的最古老且最不复杂的策略之一是简单地使您的数据库在迁移期间离线，并将停机时间视为可接受的成本。出于显而易见的原因，这种方法不适用于许多用例，因为正常运行时间和可用性通常是许多组织最高优先级的目标之一。

尽管如此，离线执行模式更改和数据突变仍然是一种有效的策略，在某些情况下可能很有用。如果这是一种选择，那么这种方法有很多优点

• 模式更改可以与客户端代码更改在单个步骤中协调实施。
• 可以检查和测试模式和存储数据的更改，而无需考虑它们对正在运行的进程的性能影响。
• 没有“过渡”期，在此期间，条件代码路径或同一数据结构的多个变体导致复杂性的暂时激增。
• 实施此方法所需的最小基础设施和系统。
• 与其他一些系统相比，大型更改可能更容易合并。

然而，缺点也不容忽视

• 可用性损失可能对 SLA、收入、声誉和其他重要指标产生巨大影响。
• 如果在受限的“维护”窗口内工作，部署期间的意外问题会更具影响力，因为它们直接影响到重新建立可用性的时间。
• 下游服务也将中断，导致任何依赖软件的级联停机。
• 计划内维护往往是“全员出动”的事件，这可能具有挑战性，特别是当它是您部署更改的主要方法时。

在停机期间部署数据库模式更改的过程在实践中相当简单。生成面向用户的响应的应用程序或组件应该理想地在维护块之前提前警告任何计划的停机时间。这可以帮助用户和下游服务就他们自己的需求做出决策。

在维护窗口之前，应设计一个计划或清单，以定义必须执行的确切操作。部署本身应尽可能脚本化和自动化，以减少人为错误并尽可能快地执行所需的操作。所有必需的资产和人员都应在服务关闭之前准备就绪。

在维护窗口期间，应用程序应更新其响应以指示计划内维护正在进行以及服务再次可用的任何估计时间范围。应将经过测试的更改过程应用于生产环境，之后，应检查和测试新的代码和数据模式。

部署完成后，可以重新启动应用程序并开始使用新代码和模式为请求提供服务。

蓝/绿部署

蓝/绿部署是另一种常用于在应用程序上下文中部署新代码的策略。它可以在一定程度上用于数据库模式更改，但确实存在一些明显的缺点。

蓝/绿部署是一种方法，它涉及为您的数据库客户端设置两组相同的基础设施，总共代表运行生产流量所需资源的双倍。

一组基础设施服务于当前的生产流量。另一组基础设施用于设置下一个版本。当一切就绪时，负载均衡器或其他流量导向器路由客户端请求，将流量从第一组切换到第二组以引入新的更改。如果出现问题，可以将流量切换回原始基础设施。如果一切顺利，原始的、现在未使用的基础设施将成为暂存下一个部署的目标。

蓝/绿部署很有吸引力，因为它们允许您在生产就绪的基础设施上部署更改，而不会影响当前的生产环境。通过将部署过程与更改的“发布”分离，开发人员可以在实际运行的基础设施上测试他们的更改，而不会停机。通过切换机制发布新代码和更改使您可以轻松地恢复更改。

虽然蓝/绿部署在许多情况下都很有帮助，但在模式更改中应用它们可能具有挑战性。当仅更改应用程序代码（没有与数据相关的更改）时，恢复有问题的代码就像将流量导向回原始基础设施集一样简单。但是，当数据模式更改时，可能会出现不兼容性。恢复到以前的基础设施可能会导致数据丢失，因为模式结构被删除等。

当将蓝/绿部署与模式更改一起使用时，避免这些问题的一种方法是使用扩展和收缩模式（稍后讨论）来构建您的部署。

功能标志

功能标志是软件开发中的一种设计模式，它允许开发人员在运行时基于应用程序外部设置的值来修改应用程序的控制流。当应用程序遇到某个代码路径时，它会检查众所周知的外部位置的当前值。该值告诉应用程序是否执行某个代码路径，或者在多个路径中选择哪个路径。

功能标志本身不是一种部署策略，而是一种技术，它可以通过允许您将新功能的部署与该功能的激活分离来使其他策略的实现更容易。应用程序可以像最初一样继续运行，直到它在检查标志时看到不同的值。然后，它可以立即切换到使用新功能。

在引入模式更改方面，功能标志尤其有价值，因为您的应用程序可以被设计为与模式的多个迭代进行交互。功能标志可以设置为指示当前部署的模式版本，从而选择已设计为与之交互的代码。

使用功能标志的缺点通常很小，但应予以考虑。如果尚无可用的适当的键/值存储，则可能需要额外的基础设施来存储您的标志值。此外，功能标志可能会在其使用期间增加代码的复杂性。一旦功能标志过时，清理和简化代码路径可以帮助将额外的条件逻辑保持在最低限度。

金丝雀发布

可以与其他方法结合使用的另一种策略是金丝雀发布。金丝雀发布是一种部署策略，它简单地意味着更改首先在一个或少数几个客户端上引入，然后再部署到您的其余基础设施。

这使您可以尽早发现您在之前的测试中没有看到的问题。运行新代码的客户端子集充当代码在其余系统上运行状况的指标，并允许您在对更改的稳定性和功能性获得信心时逐步推出其他系统。

在数据库模式更改方面，金丝雀发布允许您通过降低引入更改的风险来验证模式更改及其相关的客户端代码是否适合生产环境。不是影响所有客户端，而是使用一小部分来评估更改。这使您有机会在更改产生意外后果时尽早回滚，并使用一部分真实世界的生产流量来查看性能。金丝雀发布帮助您最大限度地减少代码更改的影响，这可以帮助您的模式更改更顺利地进行。

扩展和收缩模式

引入模式更改的最佳方法可能是扩展和收缩模式。扩展和收缩模式允许您在原始模式旁边引入模式更改，将旧数据迁移到新结构，并在计划阶段逐步将生产流量移动到新结构。它可以与我们之前讨论的许多策略和技术结合使用，以在发生问题时引入具有多层安全性的更改。

扩展和收缩模式可以通过执行以下步骤来实现

1. 在原始模式旁边设计和部署所需的模式。
2. 修改客户端代码以同时写入两个模式。
3. 将现有数据从原始模式迁移到新模式，并在必要时对其进行修改以符合新结构。
4. 测试新模式，以确保其功能正确且数据已正确传输。
5. 修改客户端代码以开始从新模式读取数据。
6. 修改客户端代码以停止写入原始模式。
7. 删除原始模式。

通过执行上述阶段，您的模式更改会分布在更长的时间内。然而，这使您可以逐步更改生产环境中的应用程序代码以处理模式中的更改。

此策略的主要优势之一是将读取与写入新数据模式分离。这种方法意味着应用程序在新模式影响任何面向客户端的响应之前很久就使用了新模式，并且客户端代码积极参与将新数据写入模式，而旧数据可以在后台回填。

您可以在关于使用扩展和收缩模式进行模式更改的指南中阅读有关此方法的更多详细信息。