DevOps实践蓝绿部署时踩的坑

蓝绿部署属于基于环境的发布模式。蓝绿部署模式中，会存在两个生产环境：蓝环境和绿环境。在任意时间里，都只有一个环境处理客户流量，另外一个环境用作测试新版本。蓝绿环境属于逻辑概念，处理客户流量的是绿环境。

image-20210122090921398.png

1.2 如何执行

任意情况下，绿环境提供用户流量，蓝环境用于部署新版本，测试人员在蓝环境中测试。

image-20210125144132930.png

升级的时候，蓝环境进行版本升级（升级到版本1.1），用户流量指向绿环境（版本1.0）。

image-20210125144409915.png

待蓝环境测试工作做完，确认一切正常后，用户流量切换到蓝环境 。

image-20210125144526590.png

就逻辑上而言，此时蓝环境应该是绿环境，绿环境是蓝环境。

image-20210125144653344.png

敏捷开发的情况下，新的迭代又开始了。新的版本此时部署到蓝环境。

image-20210125144753917.png

1.3 F&Q

上面的步骤看起来很简单，实际却暗藏深机，如果考虑不周，会踩很多坑。

比如：

F：蓝绿部署主要目的是为了解决生产上版本更新迭代问题的，最终必然会落实到生产环境。蓝环境在生产中部署，生产环境数据库产生测试的脏数据如何处理？

Q：财大气粗者，两套数据库安排上。若是精简持家，这个就是个很头疼的问题了，我现在就是卡在这个问题，暂时还没有什么好的解决方案。

F：多系统，多厂家合作的大型系统，怎么破？

Q：要么全部上蓝绿部署，至少在数据流转层面进行蓝绿区分。要么全部不上蓝绿部署，用灰度吧。这样的大系统应该在开工的时候就说好要不要上蓝绿部署的。

1.4 总结

优点：

1. 上线与部署解耦，开发人员可以在工作时段部署新版本，并开始测试工作。上线的工作只需要挑个良辰吉日把用户流量切换。熬夜通宵上线部署的日子一去不复返。
2. 生产环境也可以玩测试，因为版本不同导致上线问题的日子同样一去不复返，上线出现问题的概率大大降低，上线第二天再也不用提心吊胆了。
3. 如果出现问题，马上切换流量。切流量可比回滚快多了，从用户的角度看，也就是网络卡了一下吧，用户感知极低。

缺点：

1. 需要维护两套系统，运维成本翻倍。
2. 生产环境脏数据问题。
3. 多厂家合作的大型系统，协调成本不可避免。

END