1.1 定义概述
蓝绿部署属于基于环境的发布模式。蓝绿部署模式中,会存在两个生产环境:蓝环境和绿环境。在任意时间里,都只有一个环境处理客户流量,另外一个环境用作测试新版本。蓝绿环境属于逻辑概念,处理客户流量的是绿环境。
1.2 如何执行
任意情况下,绿环境提供用户流量,蓝环境用于部署新版本,测试人员在蓝环境中测试。
升级的时候,蓝环境进行版本升级(升级到版本1.1),用户流量指向绿环境(版本1.0)。
待蓝环境测试工作做完,确认一切正常后,用户流量切换到蓝环境 。
就逻辑上而言,此时蓝环境应该是绿环境,绿环境是蓝环境。
敏捷开发的情况下,新的迭代又开始了。新的版本此时部署到蓝环境。
1.3 F&Q
上面的步骤看起来很简单,实际却暗藏深机,如果考虑不周,会踩很多坑。
比如:
F:蓝绿部署主要目的是为了解决生产上版本更新迭代问题的,最终必然会落实到生产环境。蓝环境在生产中部署,生产环境数据库产生测试的脏数据如何处理?
Q:财大气粗者,两套数据库安排上。若是精简持家,这个就是个很头疼的问题了,我现在就是卡在这个问题,暂时还没有什么好的解决方案。
F:多系统,多厂家合作的大型系统,怎么破?
Q:要么全部上蓝绿部署,至少在数据流转层面进行蓝绿区分。要么全部不上蓝绿部署,用灰度吧。这样的大系统应该在开工的时候就说好要不要上蓝绿部署的。
1.4 总结
优点:
- 上线与部署解耦,开发人员可以在工作时段部署新版本,并开始测试工作。上线的工作只需要挑个良辰吉日把用户流量切换。熬夜通宵上线部署的日子一去不复返。
- 生产环境也可以玩测试,因为版本不同导致上线问题的日子同样一去不复返,上线出现问题的概率大大降低,上线第二天再也不用提心吊胆了。
- 如果出现问题,马上切换流量。切流量可比回滚快多了,从用户的角度看,也就是网络卡了一下吧,用户感知极低。
缺点:
- 需要维护两套系统,运维成本翻倍。
- 生产环境脏数据问题。
- 多厂家合作的大型系统,协调成本不可避免。
END