互联网CD持续部署和DevOps落地实践

Posted 2021-04-16 云容器时代

互联网CD持续部署和DevOps落地实践

DevOps is everywhere，所有人都在说在做。DevOps转型的案例和故事很多，有些转型成功了，但也许失败的例子更多（虽然你没有机会听到他们出来分享了）。不同组织面临的情况和环境各不相同，其实很难简单的复制别人的成功。

我经常喜欢举的一个例子，学习DevOps有不同的方式，就像人类学习飞行时有鸟飞派和空气动力学派。人类的飞行梦想始于古老而又遥远的年代，但真正的飞行实践起源于仿鸟飞行，即给自己装上一对翅膀，学习鸟的扑翼动作而飞行，但大量长期的实践证明这样的尝试都是失败的。但还有另外一派，英国的科学家提出人造飞行器应该解决推进动力和升力等方面的问题，需要增强对空气动力学理论体系的基本认知，这使很多人放弃了单纯模仿鸟类飞行而逐渐接受和实践固定翼飞行器的设计思路，并最终由莱特兄弟发明了完全受控、可持续飞行的载人飞行器。

image.png

image.png

image.png

image.png

蓝绿部署

Martin Flower曾在文章中阐述了蓝绿部署的整体要点，建议大家看看。
基本上，蓝绿部署是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。
简单来说，你需要准备两个相同的环境（基础架构），在蓝色环境运行当前生产环境中的应用，也就是旧版本应用，如图中App1 version1、App2 version1、App3 version3。

[图片上传失败...(image-f89943-1521608396399)]
当你想要升级App2到version2，在蓝色环境中进行操作，即部署新版本应用，并进行测试。如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝色环境了。

[图片上传失败...(image-aaab78-1521608396399)]
随后你需要监测新版本应用，也就是App2 version2是否有故障和异常。如果运行良好，就可以删除App2 version1使用的资源。如果运行出现了问题，你可以通过负载均衡器指向快速回滚到绿色环境。

理论上听起来很棒，但还是要注意一些细节：

• 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题；

• 有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务停止的；

• 需要提前考虑数据库与应用部署同步迁移/回滚的问题；

• 蓝绿部署需要有基础设施支持

• 在非隔离基础架构（VM、Docker等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险

A/B Testing

A/B测试跟蓝绿部署完全是两码事。

A/B测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等。A/B测试通常用在应用的前端上，不过当然需要后端来支持。
[图片上传中...(image-b0de41-1521608396399-1)]

A/B测试与蓝绿部署的区别在于，A/B测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚。

A/B测试和蓝绿部署可以同时使用。

灰度发布／金丝雀发布

灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。

[图片上传失败...(image-5add9d-1521608396399)]

灰度发布／金丝雀发布由以下几个步骤组成：

• 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。

• 从负载均衡列表中移除掉“金丝雀”服务器。

• 升级“金丝雀”应用（排掉原有流量并进行部署）。

• 对应用进行自动化测试。

• 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。

• 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）