PlanetScale 分支与 Amazon Aurora 蓝/绿部署对比

蓝/绿部署是 Amazon 为其 RDS 和 Aurora 数据库提供的维护任务解决方案。创建蓝/绿部署时，会复制现有的数据库环境来进行更改。这种方法在某些方面与 PlanetScale 的分支技术有相似之处，但从根本上来说，两者的解决方案有很大的不同。
本文将介绍 Amazon Aurora 蓝/绿部署的工作原理，并阐明它与 PlanetScale 分支技术的区别。

什么是蓝/绿部署？

在探讨 Amazon Aurora 的蓝/绿部署之前，有必要先了解该部署策略本身。传统的 DevOps 流程包含八个步骤，旨在帮助企业快速将新功能推向生产环境。第六步是部署阶段，在此阶段，构建好的制品被推送到生产环境并释放给用户使用。
蓝/绿部署是一种在 DevOps 的部署阶段使用的策略，能够实现代码的无缝上线。
采用蓝/绿策略发布新功能时，通常会出现两个可充当生产环境的完全独立的环境。例如，“蓝”环境表示当前的生产环境，“绿”环境则是一个后备环境，用来发布新制品并最终成为生产环境。当制品发布到绿环境后，流量会被切换到绿环境，绿环境便成为新的生产环境。
此后，流量会根据最新发布的代码在两个环境之间交替流转，蓝/绿环境分别接替彼此的生产状态。

Amazon Aurora 蓝/绿部署的工作方式

Aurora 将上述蓝/绿流程应用于数据库。
设置 Amazon Aurora 的蓝/绿数据库部署时，AWS 会克隆当前的 Aurora 集群，并启动一个全新的“绿”环境。新集群配置完成后，AWS 会在两个集群之间配置 binlog（二进制日志）复制，以确保数据的持续同步。新环境可以用于更改数据库架构或配置。
完成所有计划的更改后，可以执行切换操作，将“绿”环境提升为生产环境并引导流量到该环境。
触发切换时，在将流量指向新生产环境之前需要完成一些操作。Amazon 会通过一系列防护措施（Guardrails）确保变更兼容性，并保证没有长时间运行的操作影响蓝环境。这些操作完成后，Amazon 会执行以下动作：

停止新数据的写入并断开所有数据库连接。
等待最后的写入与复制操作完成。
将蓝环境设置为只读状态。
对两个环境的资源进行重命名，使绿环境的资源采用蓝环境的原始命名。

从这时开始，所有事务都会在绿环境中处理，而蓝环境的资源仍然在线，但会被添加“old”前缀标签。

为什么使用 Amazon Aurora 的蓝/绿部署？

Amazon 推荐在 Aurora 集群需要维护时使用蓝/绿部署，以下是几种场景，这种方法能够显著减少通常需要的停机时间：

架构更改蓝/绿部署可以用来实施轻量级的架构更改，如在表末尾添加新列、创建索引或删除索引。然而，由于蓝/绿部署依赖 binlog 同步数据，因此架构更改必须与 MySQL 的 binlog 复制功能兼容，否则会阻碍切换操作的完成。
版本升级MySQL 会定期发布新版本，包括具有新功能的重大版本或仅修复安全漏洞的次要版本。通过蓝/绿部署，可以在隔离的环境中测试新版本，同时保持当前生产环境完全匹配。
计算实例类型调整如果 Aurora 实例类型计算资源不足，可能需要选择新的实例类型进行扩展。这通常会导致关闭旧计算节点并启动新节点，此过程中数据库会暂时不可用。蓝/绿部署可以减少因实例类型调整带来的停机时间。

什么是 PlanetScale 分支技术？

PlanetScale 的分支技术基于 Vitess，为每个分支创建独立的 Vitess 集群，并包含多种基础设施组件。例如，数据存储于一个称为“tablet”的容器中，该容器运行 MySQL 进程和一个叫做 vttablet 的辅助进程。此辅助进程允许容器与 Vitess 环境的其他部分通信。同时，vtgate 是一个轻量级代理路由服务，它与拓扑服务协作，将 MySQL 流量路由到正确的 tablet。如果某个 tablet 出现故障，PlanetScale 的系统会自动重新路由流量并分配新的 tablet 替换故障实例。
在生产分支中，至少有一个副本始终可用，用于只读工作负载或作为备用节点，以防写入节点下线。付费层自动提供额外副本，而企业级解决方案完全支持定制化。另一方面，开发分支默认使用低成本实例，但可以根据需求增强性能配置。
创建新的开发分支时，系统会启动一个完全与生产数据库分支隔离的 Vitess 集群。开发分支会复制上游分支的架构，为分支提供一致的数据库结构。因此，开发分支非常适合构建需要架构更改的新功能。这些更改可以通过部署请求（类似 GitHub 的 Pull Request）以非阻塞方式合并至上游分支，实现无停机状态下安全合并。

PlanetScale 数据分支技术

除标准分支功能外，PlanetScale 还支持数据分支技术（Data Branching®）。数据分支允许通过恢复生产备份的最新版本，在新分支中创建生产数据的副本。这使得开发人员能够在隔离的环境中测试新功能或运行分析操作，而不会对生产环境产生影响。

对比 PlanetScale 与 Aurora 蓝/绿部署的适用场景

架构更改

Aurora 的蓝/绿部署依赖 binlog 同步数据，因此在绿环境中进行的任何架构更改必须与 binlog 复制功能兼容，否则切换操作将无法完成。
PlanetScale 的方法与此不同，它分析两个架构之间的差异，并生成正确顺序的 DDL 语句以在上游分支执行。部署请求合并时，系统会在上游数据库中创建一个“幽灵”表（ghost），应用新的架构，同时在旧表与“幽灵”表之间同步数据，直到切换完成。

实例类型调整

Aurora 蓝/绿部署可通过防护措施提高切换成功率。然而，Aurora 的许多实例修改操作需要截断数据库连接，因而仍存在停机情况。
PlanetScale 使用 Vitess 和 Kubernetes 实现无缝滚动升级 tablet 实例，无需断开数据库连接。用户只需要选择新的实例类型，系统会完成剩余操作，从而保证应用继续正常运行。

版本升级

Aurora 可以在预定义的维护窗口中自动应用小版本升级，但这种方式可能会有停机风险。使用蓝/绿部署可以更好地控制版本升级过程，但需要耗费大量精力进行规划。
PlanetScale 工程团队会仔细验证新版本是否与系统兼容，然后通过滚动升级应用变更，利用 Vitess 的路由及 Kubernetes 技术避免传统维护窗口的停机风险。

使用 Aurora 蓝/绿部署的注意事项

成本

Aurora 蓝/绿部署会创建一个与现有集群完全相同的新集群，包括所有配置的读副本。这意味着在某些操作期间，你将为两个完整集群（蓝环境和绿环境）付费，但实际上仅使用了一半的资源。切换操作完成后，蓝环境仍在线运行，这会增加额外成本。
PlanetScale 仅创建完成架构更改所需的资源，用户可以选择更多资源或生产数据，但这并非强制性需求。这显著降低了更改数据库的成本。

失败回滚

蓝环境在切换后仍然在线，但只支持只读模式。Aurora 不允许直接回滚到蓝环境。如果需要回滚，必须重新创建新的蓝/绿部署，撤销绿色环境中的更改并再次切换。
PlanetScale 支持名为架构回滚（Schema Revert）的功能，可以撤销架构更改，同时保留合并部署请求后发生的写入操作。这些写入会同步到之前保留的旧表中，因此回滚时旧表会重新变为活动表，并包含所有合并后的数据变更。

数据不一致风险

Aurora 蓝/绿部署仅克隆计算资源，而数据存储采用写时复制机制。这种方法可能存在潜在的数据不一致问题。如果蓝绿环境都允许写入，同一数据可能在两个环境中发生不同变更，Aurora 无法自动解决冲突。数据一致性的责任由用户自己承担。
PlanetScale 的分支完全隔离生产环境，当你合并架构更改时，生产数据不会受到影响。