DevOps之零停机部署

“零停机部署（ZDD）可在不中断现有服务的情况下部署新版系统。”

通过ZDD方式部署应用程序时，可在确保用户不会遭遇应用程序停机的前提下将新版应用引入生产环境。从用户和公司的角度来看，这应该是最佳部署方式，因为可以在不造成任何中断的情况下引入新功能并修复Bug。

下文将介绍4种技术：

1. 功能开关（Feature Flipping）
2. 摸黑启动（Dark launch）
3. 蓝／绿部署（Blue/Green Deployment）
4. 金丝雀发布（Canari release）

功能开关

功能开关可供我们在软件运行过程中启用／禁用相应的功能。这种技术其实非常容易理解和使用：为生产版本提供一个能彻底禁用某项功能的配置，并只在对应功能彻底完工可以正常工作后才将该属性激活。

举例来说，若要将某个应用程序内的一个功能全局禁用或激活：

if Feature.isEnabled('new_awesome_feature')
    # Do something new, cool and awesome
else
    # Do old, same as always stuff
end
或者如果要真对具体用户实现类似目的：
 
if Feature.isEnabled('new_awesome_feature', current_user)
    # Do something new, cool and awesome
else
    # Do old, same as always stuff
end 

摸黑启动

摸黑启动的目的在于通过生产环境进行负载模拟！

在测试环境中，通常很难为软件模拟出成百上千万用户规模的负载。

如果不进行切实的负载测试，就无法知道基础架构能否承受住最终面临的压力。

此时并不需要模拟负载，而是可以实际部署这样的功能，然后看看在不影响可用性的前提下到底会发生什么。

Facebook将这种做法称之为功能的“摸黑启动”。

假设我们要将一个有5亿用户使用的静态搜索字段变成一个包含自动补全功能的字段，借此让用户可以更快速获得搜索结果。为该功能构建一个Web服务，并且希望模拟所有用户同时输入文字，向该Web服务生成大量请求的场景。

此时即可通过摸黑启动策略为现有表单添加一个隐藏的后台进程，通过该进程将输入的搜索关键字发送给新增的自动补全服务，并自动发送多次。

就算新增的Web服务彻底崩溃了，也不会造成任何实质损害。网页上可以完全忽略服务器错误。而就算该服务崩溃了，我们至少还可以对该服务进行优化和完善，直到能承受如此大量的负载。

这就等于在现实世界中进行了一次负载测试。

蓝／绿部署

蓝／绿部署是指为下一版产品构建另一个完整的生产环境。开发和运维团队可以在这个单独的生产环境中放心地构建下一版产品。

当下一版产品全部完成后，可以修改负载均衡器的配置，以透明的方式将用户自动重定向至新发布的下一版。

随后可将上一版的生产环境回收，用于构建下下一版的产品。

以此类推。

（来源：Les Patterns des Géants du Web – Zero Downtime Deployment ）

这是一种相当有效简单的方法，但问题在于这种方式需要双倍的基础架构以及更多的服务器等。

假设一下Facebook希望将包含成千上万台服务器的环境“照原样再来一套”……

其实还有更好的方法。

金丝雀发布

从本质来看，金丝雀发布与蓝／绿部署非常类似，但无需准备额外的一套生产环境。

这种方式的目标在于以增量的方式将用户切换至新版本：随着越来越多的服务器从当前版本迁移至下一版，相同比例的用户也会被同时迁移。

通过这种方式，每个生产环境都能获得与负载需求相匹配的服务器数量。

首先，只将少量服务器和少部分用户迁移至下一版，借此还可以在无须冒险影响所有用户的前提下对新版进行测试。

当所有服务器最终从当前版迁移至下一版后，发布工作已经完成，又可以从头开始准备下下一版了。