【IT老齐035】蓝绿、红黑、灰度发布

【IT老齐035】蓝绿、红黑、灰度发布

尽可能减少服务停机时间

控制新版本带来的质量风险

全量发布

蓝绿部署

1709975325023

红黑部署

1709975532112

与蓝绿部署相比,红黑部署可以充分利用了云计算的弹性伸缩优势,从而获得了两个收益:简化了流程;避免了在升级的过程中,由于只有一半的服务器提供服务,而可能导致的系统过载问题

增量发布

灰度发布

灰度发布,也被叫作金丝雀发布。与蓝绿部署、红黑部署不同的是,灰度发布属于增量发布方法。也就是说,服务升级的过程中新旧版本会同时为用户提供服务

1709975809609

1709975867880

问题

考虑数据库变更对旧版本的兼容性影响
  • 对于新旧版本可以协同作业的情况
    • 要求团队成员写SQL必须明确字段
  • 对于新旧版本无法协同作业的情况
    • 放弃灰度,采用红黑方式全量发布
    • 可以考虑独立部署数据源进行迁移,为新旧版本分配独立的数据源,但新旧数据源之间数据同步会更考验架构师与DBA的智慧
灰度发布用户群的选择
  • 不能直接采用类似于Nginx的权重Weight,会导致一个用户不同请求在新旧版本间反复横跳,出现无法预期的Bug
    • 利用Nginx + Lua脚本化,基于IP或者LUA等用户稳定特性然后Hash取模来决定访问新旧版本
可以提升分配比例的时机
  • 在发布过程中,我们应该注意监测用户请求失败率、用户请求处理时长和异常出现数量这几个信息,以保证快速发现问题并及时回滚。在灰度发布的时候,可以部署相对较小的集群,让集群保持在高压力确认新版应用的性能情况,之后再酌情进行扩容
    • SkyWalking
    • ELK
    • Prometheus
posted @ 2024-03-14 20:01  Faetbwac  阅读(10)  评论(0编辑  收藏  举报