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

# 在线迁移期间迁移应用程序
<a name="migration-online-app-migration"></a>

在线迁移的第四阶段，您将迁移应用程序并过渡到作为主数据存储的 Amazon Keyspaces。这表示您可以将应用程序切换为直接从 Amazon Keyspaces 读取数据和向其中写入数据。为确保最大限度地减少对用户的干扰，这应该是一个精心策划和协调的过程。

有两种不同的应用程序迁移推荐解决方案可供选择，蓝绿切换策略和金丝雀切换策略。以下各节对这两种策略进行了详述。
+ **蓝绿策略** - 使用这种方法，您只需一步即可切换应用程序，将 Amazon Keyspaces 视为主数据存储，将 Cassandra 视为辅助数据存储。为此，您可以使用AWS AppConfig功能标志来控制应用程序实例中主数据存储和辅助数据存储的选择。有关特征标志更多信息，请参阅 [Creating a feature flag configuration profile in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html)。

  将 Amazon Keyspaces 设置为主数据存储后，您可以监控应用程序的行为和性能，确保 Amazon Keyspaces 满足您的要求并保证迁移成功。

  例如，如果您对应用程序实现了双重读取，则在应用程序迁移阶段，您可以将主读取从 Cassandra 切换到 Amazon Keyspaces，将辅助读取从 Amazon Keyspaces 切换到 Cassandra。切换后，您可以继续按照[数据验证](migration-online-validation.md)部分所述监控和比较结果，确保在停用 Cassandra 之前两个数据库之间实现一致。

  如果检测到任何问题，则可以通过恢复到作为主数据存储的 Cassandra 来快速回滚到之前的状态。只有当 Amazon Keyspaces 满足您对主数据存储的所有需求时，您再停止移。  
![\[使用蓝绿策略将应用程序从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **金丝雀策略** - 通过这种方法，您可以逐步向部分用户或流量推出迁移。最初，您的应用程序流量的一小部分（例如，所有流量的 5%）被路由到使用 Amazon Keyspaces 作为主数据存储的版本，而其余流量则继续使用 Cassandra 作为主数据存储。

  这让您可以使用真实流量对迁移版本进行全面测试，并监控其性能、稳定性以及调查潜在的问题。如果您未发现任何问题，则可以逐步增加路由到 Amazon Keyspaces 的流量百分比，直到它成为所有用户和流量的主数据存储。

  这种分阶段部署可最大限度地降低广泛服务中断的风险，并且可以对迁移过程进行更严格的控制。如果在金丝雀部署期间出现任何严重问题，则可以将 Cassandra 作为受影响流量段的主数据存储，来快速回滚到先前的版本。只有在您确认 Amazon Keyspaces 按预期处理所有用户和流量之后，您再停止迁移。

  下图展示了金丝雀策略的各个步骤。  
![\[使用金丝雀策略将应用程序从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-canary.png)