design-patterns - 如何处理蓝绿部署技术中的数据变化?

标签 design-patterns blue-green-deployment canary-deployment

我研究过this关于蓝/绿部署的文章,然后通过更多的谷歌搜索向我介绍了 this关于 Canary 发布的文章。
我有这个歧义:数据库会发生什么?我们应该如何使它们同步?
我有两种可能的情况:

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

  • 可能还有第三种情况,在主蓝/绿部署中为数据库实现蓝/绿部署。

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

    谢谢你

    最佳答案

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

    您的第三种情况也陷入了需要在数据库切片之间触发或镜像的陷阱。在 RDBMS 术语中,这通常是不受支持或完全不可能的,因为只有主数据库并且所有其他实例不接受写操作。这样做的净效果是主实例的版本是整个数据库的事实上的版本。

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

    关于design-patterns - 如何处理蓝绿部署技术中的数据变化?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30152339/

    相关文章:

    java - 使用 Split 方法创建分词器

    java - 具有多个具有内部调用的微服务的蓝绿部署

    deployment - 在Heroku或其他云平台上作为服务部署蓝绿色

    amazon-web-services - API Gateway 是否可以设置为金丝雀部署的粘性 session ?

    firebase - 如何在 Firebase 托管上的多个发行版本之间进行流量分配

    python - 使用中间结果调用链方法

    java - 设计模式 - 我应该在哪里操作从数据库检索的字符串。离它更近还是更远

    java - 这段代码是否滥用了观察者模式?

    azure - 插槽交换时连接丢失

    amazon-web-services - 如何处理 AWS elasticbeanstalk 上的金丝雀发布?