如何处理Blue/Green部署技术中的数据更改？

Question

我阅读了有关Blue/Green部署的这篇文章，然后通过一些搜索了解了这篇关于Canary Release的文章。 我有一个疑惑：数据库会发生什么？我们应该如何使它们同步？ 我有两种可能的情况：

• 假设有两个单独的数据库，每个环境都有一个（绿色和蓝色），当蓝色处于活动状态时，新记录将被插入到它的数据库中，绿色不知道这些更改，除非我们提供触发器等机制来更新绿色数据库。
• 第二种情况建议在两个环境之间共享向后兼容的数据库，但是处理数据库时向后兼容性并不容易，我们必须在发布应用程序之前发布数据库更改。

可能还有第三种情况，即在主Blue/Green部署内部实现数据库的Blue/Green部署。

你认为哪种解决方案更好，为什么？你建议采用其他实践或众所周知的模式吗？

谢谢

- MoienGK

Answer 1

我个人只使用向后兼容的数据库方法。其主要优点是它被广泛理解，并适用于各种部署类型，包括金丝雀和蓝绿色；我甚至在没有蓝绿色部署策略的情况下使用了这种方法（即对所有服务器进行快速金丝雀部署的平凡滚动部署）。必须在应用程序发布之前部署数据库更改是多种部署策略共同面临的问题，与需要复杂的触发或镜像机制相比，不算繁重。

你提出的第三种情况也陷入了需要触发或镜像数据库切片之间的陷阱。在关系型数据库管理系统（RDBMS）术语中，这通常是不受支持或完全不可能的，因为只有一个主数据库，所有其他实例都不接受写操作。这的净效果是主实例的版本是整个数据库的事实标准版本。

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

- Patrick M

---

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

Answer 2

我从未见过一个完全是蓝绿或金丝雀的应用程序。原因在于实际的“数据”层。我们无法在数据库层面上进行蓝绿部署，因为每种数据库类型都有其自己的细微差别。这通常仅用于应用程序（代码）级别。

如果您想要使用数据库进行蓝绿部署，则需要在DB级别进行数据迁移或至少还原，这对大多数团队来说是复杂和繁琐的。这将耗费时间，并且回滚将是一种混乱的状态。只需使用向后兼容的数据库并在回滚时清理数据库更改即可。

- Hussain Mansoor