DevOps的持续部署方法大全.docx

DevOps 的持续部署方法大全 DevOps 强调只有真正部署到生产环境的应用才真正体现价值。DevOps 的持续发布或部署是需要高度反脆弱性的，所谓反脆弱性就是所发布到生产环境的软件一定要非常稳定，即确保100%的软件部署成功。如果不成功也需要采取必要的机制快速回滚到上一个稳定的版本，以使业务快速恢复正常。为了更好地实现这种较高业务连续性的需求以及软件不同版本在生产环境的快速交割机制， DevOps 创造性地发明了几种不同的发布实践，我们耳熟能详的有蓝绿部署、金丝雀和灰度发布等。目前 DevOps 的良好实践主要来自互联网公司，比如谷歌 （Google）、百度和阿里巴巴等。它们已经在软件开发和部署实践中不断总结出很好的经验知识，并把这种知识以持续部署流水线的形式固化到自行研制的工具平台，比如阿里的云效、腾讯的蓝鲸等。IT 组织可以利用这种覆盖软件开发全生命周期的平台，确实保证在频繁触发自动化部署时能够兼顾业务的连续性， 即反脆弱性。 下面介绍一下 DevOps 在持续交付或部署层面已经检验过的良好实践或做法。 1、蓝绿部署 蓝绿部署（blue-green deployment）强调在生产环境同时有两套版本，一个叫做“蓝环境”一个叫做“绿环境”。当需要发布新版本应用时，发布部署的机制是一次只发布新的软件版本到一个系统环境中，比如说把新的软件版本发布到蓝环境中，让新版本的应用程序先热一下身，至于热身的时限可以由应用所在的行业或企业自行决定。由于只在蓝环境做新版本的发布，绿环境不会受到影响。我们可以在蓝环境上运行“冒烟测试”，来检查蓝环境的正常情况。如果情况正常，通过网络的路由设置来切换原先在绿环境的用户流量到蓝环境。这样，蓝环境就成了主要承载生产运营和用户访问流量的生产环境，如果蓝环境突发异常情况，路由设置会再次自动启动，把原先在蓝环境的用户流量瞬间再切回到之前的绿环境版本。通过蓝绿部署的机制来确保业务连续性的需求能够长期被满足。 另外，在蓝绿部署中还要有一个需要处理的问题，即在两个环境切换时，针对正在进行的业务交易事务处理，应该如何保证业务数据交易的前后一致性的问题。一般来说，蓝绿环境的切换不是在瞬间完成的。我们可以基本遵循一般操作就是在切换过程中所遇到的全新的业务交易请求直接被导向到新版本的环境，不再允许访问旧版本的环境。对于那些在切换发生时尚未返回结果的旧的请求，旧版本的环境允许其访问完成，之后不再接收新的请求即可。 以下是关于蓝绿发布的示意图： 图 1 蓝绿部署图 2、金丝雀发布 金丝雀发布（canary release）的名字很是好听。我们都知道以前矿工在下井采矿之前会把一种名叫金丝雀的鸟儿投入或携带到矿井中，如果鸟儿能够从矿井中飞出就表示井下有氧气，矿工就可以安心下井采矿了。通过这个故事的讲述我们可能已经猜到金丝雀发布的含义了。是的，所谓金丝雀发布就是把应用程序的某个新版本部署到生产环境中的部分服务器中，从而快速得到反馈。就像通过金丝雀发现矿井是否有氧气一样，金丝雀发布可以快速而有效地发现软件新版本存在的问题。 以下是关于金丝雀发布的示意图： 图 2 金丝雀发布图 在互联网公司经常流行一种说法叫做灰度发布，其实金丝雀和灰度发布的机理是一致的，即把应用程序的某个新版本部署到生产环境的部分服务器或部分用户群体中，从而得到快速反馈并降低可能的发布风险。您可以把金丝雀发布理解 为灰度发布的初始级别。灰度发布可以把发布分成不同的阶段，至于划分为几个阶段或每个阶段包括多少用户由具体组织的情况而定。 比如 BAT 之一的腾讯公司为了验证其QQ 或微信的新特性是否能够受到市场的青睐又不至于造成广大用户针对此新特性的负面评价，该公司往往采用灰度发布的做法，先把新特性按照不同的阶段或周期推送给其所谓的粉丝级用户群，在获得正面反馈后，再进入下一个预设阶段的推送，确保分批地把新特性推给更多目标用户。在确定新的软件特性在风险可控的情况下，再逐步部署到全部的服务器上，从而支持所有用户针对新特性的新体验。 3、滚动部署 滚动部署（rolling deployment）是指从服务器集群中选择一个或多个服务 单元，停止服务后执行版本更新，再重新将其投入使用。如此循环往复，直至在集群中所有的服务实例都更新到最新版本。它和蓝绿部署的方式相比，更加节省资源，而不需要准备两套一模一样的服务运行环境。因此，在同样业务量的情况下，这种部署方式所需服务器的数量会比蓝绿部署少一半。 当然，少的资源投入可能会存在功能的局限性。滚动部署无法像蓝绿部署那样只要直接通过控制流量切换的负载均衡器的动态设置来实现动态的环境切换。滚动部署所采取的回滚方式只能是针对特定服务器从新版本回退到旧版本。 4、暗部署 暗部署（dark launch）是指软件特性在正式发布之前