新钛云服已累计为您分享756篇技术干货
近些年,“DevOps”非常热门,最近,我们团队讨论了部署最佳实践、热部署、回滚等,当提到蓝绿部署时,大家表现出浓烈的兴趣。
蓝绿部署已经在像亚马逊这样的地方实践了 10 多年。它们是一种安全、经过验证的方法。现在,蓝绿部署不是灵丹妙药,但它们有一定的用处。
其实还有A/B 测试,甚至 Canary 测试,在所有微服务、DevOps和云原生交流中,有很多关于它们的讨论,因此,我简单归纳了它们的区别。
PART ONE
蓝绿部署
Blue Green Deployments的详细介绍请参阅Martin Fowler 关于蓝绿部署的链接(http://martinfowler.com/bliki/BlueGreenDeployment.html)。它给出了总体要点。
它基本上是一种以可预测的方式发布应用程序的技术,目的是减少与发布相关的任何停机时间。这是在发布前为您的应用做好准备的一种快速方式,如果您发现问题,也可以快速回滚。
简单地说,您有两个相同的环境(基础架构),其中绿色环境托管当前的生产应用程序(例如 app1 version1app2 version1app3 version1):
现在,当您准备对 app2 进行更改并将其升级到 v2 时,您将在蓝色环境中进行。在该环境中,您部署应用程序的新版本、运行冒烟测试和任何其他测试(包括那些用于运行/启动操作系统、缓存、CPU 等的测试)。当事情看起来不错时,您将负载均衡器/反向代理/路由器更改为指向蓝色环境
您监视由于发布而导致的任何故障或异常。如果一切看起来不错,您最终可以关闭绿色环境并使用它来发布任何新版本。如果没有,您可以通过将负载均衡器指向回快速回滚到绿色环境
理论上听起来不错。但是有一些事情需要注意。
• 绿色环境中长期运行的交易。当您切换到蓝色时,您必须优雅地处理那些未完成的交易以及新的交易。如果您的数据库后端无法处理此问题,这也会变得很麻烦(见下文);
• 企业部署通常不适合微服务风格的部署——也就是说,你可能有微服务风格的应用程序和一些传统的、难以更改的应用程序一起工作的混合体。为蓝绿部署在两者之间进行协调仍然可能导致停机;
• 数据库迁移可能会变得非常棘手,并且必须与应用程序部署一起迁移/回滚。有很好的工具和技术可以做到这一点,但在传统 RDBMSNoSQL 和文件系统支持的数据库的环境中,这些事情确实需要提前考虑;盲目地说你在做蓝绿部署没有任何帮助——实际上可能会造成伤害。
• 你需要有基础设施来做到这一点;
• 如果您尝试在非隔离的基础架构(VMDocker 等)上执行此操作,您将面临破坏蓝色和绿色环境的风险;
      正如我所说,有一些很好的技术可以克服这些挑战并使这种部署方式非常有效,包括插入到持续部署管道中,但不要轻易跳入其中。
PART TWO
A/B测试
A/B 测试不是蓝绿部署,有些人会混淆这一点。A/B 测试是一种出于各种原因(例如可用性、流行度、引人注目度等)以及这些因素如何影响底线而测试应用程序功能的方法。它通常与应用程序的 UI 部分相关联,但当然需要后端服务才能执行此操作。您可以使用应用程序级开关(即知道何时显示某些 UI 控件的智能逻辑)、静态开关(在应用程序中)以及使用 Canary 版本(如下所述)来实现这一点。
蓝绿部署和 A/B 测试之间的区别在于 A/B 测试用于测量应用程序中的功能。蓝绿部署是关于安全地发布新软件并按预期回滚。您显然可以将它们结合起来:使用蓝绿部署在可用于 A/B 测试的应用程序中部署新功能。
PART THREE
云雀发布
最后,Canary发布是一种将您的应用程序的新版本发送到生产环境的方式,它扮演云雀的角色,以了解它将如何执行(与其他应用程序、CPU、内存、磁盘使用情况等集成) )。这是另一种发布策略,可以缓解以下事实:无论您在较低环境中进行的测试级别如何,您仍然会在生产中遇到一些错误。云雀版本让您在完全释放扳机之前先试水。
您获得的反馈越快,部署失败或谨慎进行的速度就越快。出于与蓝绿部署相同的一些原因,请注意上述事项;即,数据库更改仍然会绊倒您。
PART FOUR
概括
无论您是否使用特定的云技术,都可以实施所有这些策略。但正如您想象的那样,DockerKubernetes等技术对实施这些策略非常有帮助(如果甚至没有内置规定)。例如,OpenShiftFabric8通过提供使用这些技术所需的工具而无需担心底层细节,从而大大简化了使用 Docker 和 Kubernetes
原文链接:https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/
    推荐阅读   
    推荐视频    
继续阅读
阅读原文