蓝绿部署技术如何处理数据变化？ [关闭]

Posted 2023-03-04

【中文标题】蓝绿部署技术如何处理数据变化？ [关闭]

【英文标题】：How to handle data changes in Blue/Green deployment technique? [closed]

【发布时间】：2015-07-21 01:15:37

【问题描述】：

我研究了this关于蓝/绿部署的文章，然后一些更多的谷歌搜索将我介绍给this关于金丝雀发布的文章。 我有这样的歧义：数据库会发生什么？我们应该如何使它们同步？ 我有两种可能的情况：

假设每个环境有两个独立的数据库 （绿色和蓝色）在蓝色处于活动状态时，新记录将 插入它的数据库并且绿色不知道这些更改 除非我们提供类似触发器的机制（或任何其他机制） 更新绿色数据库。 第二种情况表明我们共享一个向后兼容的数据库 两种环境之间，但向后兼容并不是那么容易 在处理数据库时，我们必须发布数据库更改 在发布应用程序之前。

可能存在第三种情况，在主蓝/绿部署中为数据库实施蓝/绿部署。

您认为更好的解决方案是什么？为什么？您是否建议任何其他做法或众所周知的模式？

谢谢

【参考方案1】：

我个人只使用向后兼容的数据库方法。主要好处是它易于理解并且适用于各种部署类型，包括金丝雀和蓝绿；即使没有蓝绿部署策略（对所有服务器的普通滚动部署，本质上是快速金丝雀部署），我也使用了这种方法。与需要在不同数据库版本之间进行复杂的触发或镜像机制相比，必须在应用程序发布之前部署数据库更改对于几种部署策略来说并不那么繁琐。

您的第三个场景也落入了需要在数据库切片之间触发或镜像的陷阱。在 RDBMS 术语中，这通常是不受支持或完全不可能的，因为只有主数据库，而所有其他实例都不接受写操作。这样做的最终结果是主实例的版本是整个数据库的实际版本。

某些 No-SQL 数据库不会落入这个陷阱。例如，MongoDB 很乐意在同一个集合中允许多个不同版本的文档模式。这允许您的应用程序了解数据版本并以不同方式处理文档。但是，MongoDB 并不适用于所有应用程序（就像 RDBS 不是某些类型数据的正确数据存储一样）。

【讨论】：

向后兼容的数据库方法使部署成为“部分”金丝雀部署，因为旧服务和新服务都指向新升级的数据库。

【参考方案2】：

我从未见过 100% 蓝绿色或金丝雀的应用程序。原因是实际的“数据”层。我们不能在数据库层进行蓝绿部署，因为每种数据库类型都有自己的细微差别。这通常只用于应用程序（代码）层。

如果您想对数据库进行蓝绿部署，则需要在数据库级别进行数据迁移或至少恢复，这对于大多数团队来说实施起来既复杂又麻烦。这将非常耗时，并且回滚将是一个混乱的状态。只需使用向后兼容的数据库并在回滚时清理数据库更改。