12

Amazon Web Services 可根据您的需要提供许多持续部署和管理工具，例如 Elastic Beanstalk、OpsWorks、Cloud Formation 和 Code Deploy。基本思想是在零停机的情况下促进代码部署和升级。他们还使用 AWS 资源帮助管理最佳架构实践。

为简单起见，让我们假设一个基本架构，其中您有一个 2 撕裂结构；负载均衡器后面的应用程序服务器集合，然后是使用多区域 RDS 数据库的持久层。

跨一组实例（应用服务器）的实际代码升级很容易理解。对于一个非常简单的概述，AWS 服务会依次升级每个节点并关闭连接，因此相关实例不会被使用。

但是，我不明白如何管理数据库升级。假设我们要从版本 1.0.0 升级到应用程序的 2.0.0，并且需要更改数据库结构。通常你会使用脚本或像 Flyway 这样的库来执行升级。但是，如果有一组服务器要升级，则存在一个点，即 1.0.0 和 2.0.0 应用程序存在于整个舰队中，每个应用程序都需要不同的数据库结构。

我需要了解这实际上是如何实现的（高级），以了解执行数据库迁移的最佳方式/时间是什么。我想他们可以通过多种方式实现这一目标，但我正在努力了解他们如何做到这一点并允许 1.0.0 和 2.0.0 保存数据而不会丢失。

如果他们使用第一个应用程序节点升级迁移数据库结构，同时创建 1.0.0 的缓存版本。连接到 1.0.0 应用程序的用户使用数据库的缓存版本保持不变，连接到 2.0.0 应用程序的用户保持到新迁移的数据库。迁移所有应用程序节点后，将缓存的数据合并到数据库中。

他们似乎不太可能做到这一点，因为合并会非常复杂，但我看不到另一种方式。任何指针/帮助将不胜感激。

4

1 回答 1

3

一旦您的应用程序基础架构进入多个应用程序节点，这是一个常见的问题。在过去，您可以将您的应用程序脱机以进行“维护窗口”，在此期间您可以：

  • 用“系统维护，很快回来”页面替换应用程序。
  • 执行数据库迁移（模式和/或数据）
  • 部署新的应用程序代码
  • 将应用程序重新上线

在 2015 年，真的好几年了，这种方法是不可接受的。您的用户期望 24/7 全天候运行，因此必须有更好的方法。当然有，答案是数据库重构的一系列模式。

始终牢记的基本概念是假设您必须维护应用程序的两个并发版本，并且这两个版本之间不能有重大更改。这意味着您有一个当前正在生产中的应用程序 (v1.0.0) 和计划部署的 (v2.0.0)。这两个版本必须在相同的模式上工作。在所有应用程序服务器上完全部署 v2.0.0 后，您就可以开发 v3.0.0 以完成任何最终的数据库更改。

于 2015-03-21T05:27:24.680 回答