前言
哲学有各种各样的流派，百家争鸣，但是只有一个哲学问题是严肃的，那就是生与死。而云端交付过程中也只有三个问题是严肃的。
- 如何重建你的系统 How to recreate your system？
- 如何安全地部署你的系统 How to safely change your system?
- 部署后的问题监控与解决 When something has gone wrong?
在前面的文章中，我们讲述了什么是云端交付，如何搭建从零搭建一个持续交付系统，而今天我们要谈的是如何安全的部署你的系统，部署这个名词包含了很多的含义，最简单的解释就是如何让你的程序运行在最终的环境上。但是部署的方式上面有非常多的最佳实践。接下来我们来讨论下常见的几种发布方式，以及如何利用容器发布实现最常用的零宕机发布方式蓝绿发布。
发布策略
常见的发布策略有蓝绿发布、金丝雀发布（灰度发布）、ABTest，在国内的开发者中，对这几个概念有独立的理解。蓝绿发布通常被大家成为热部署；金丝雀发布在国内的名头完全被他的变种发布方式盖过了，主要是灰度发布与ABTtest，下面我们来详细的为大家解释一下他们之间的异同。
蓝绿发布
在发布的过程中用户无感知服务的重启，通常情况下是通过新旧版本并存的方式实现，也就是说在发布的流程中，新的版本和旧的版本是相互热备的，通过切换路由权重的方式（非0即100）实现不同的应用的上线或者下线。
金丝雀发布
通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。
灰度发布
灰度发布是通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本的过程。虽然马丁·扶老耳朵大人认为灰度发布与金丝雀发布是等同的，但是在具体的操作和目的上面个还是有些许差别的。金丝雀发布更倾向于获取快速的反馈，而灰度发布更倾向于从一个版本到另一个版本平稳的切换。
ABTest
ABTest和灰度发布非常像，但是从发布的目的上，可以简单的区分灰度发布与ABTest，ABTest侧重的是从A版本或者B版本之间的差异，并根据这个结果进行决策。最终选择一个版本进行部署。因此和灰度发布相比，ABTest更倾向于去决策，和金丝雀发布相比，ABTest在权重和流量的切换上更灵活。
阿里云容器服务实现蓝绿发布
下面我们通过一个简单的例子来演示蓝绿发布的流程。假设我们要进行蓝绿发布的应用是一个nginx的静态页面,初始的应用模板如下
部署后会有“Welcome to nginx”的成功页面提示。如果用户想变更配置， 可以在操作面板上选择“变更配置”，进入信息修改阶段，选择变更的发布策略与新版本服务的配置。
在蓝绿发布中，新版本与旧版本不能共用同一个名字；如果共享同一个路由地址，那么需要添加aliyun.routing.coexist的label，这个label的含义是，当前的服务与其他服务共享路由地址，在蓝绿发布的场景中，为了保证应用的零宕机切换，新版本的服务的路由权重默认为0，需要通过路由管理页面进行调整，方可进行流量切换。
在进行发布的过程中，会经历两个状态，一个是蓝绿发布中，一个是蓝绿发布待确认。“蓝绿发布中”表示，新版本的服务尚未启动完成；而“蓝绿发布待确认”表示新版本的服务已经启动完成，此时需要进行发布确认或者发布回滚方可进行下一次发布。其中，新版本的应用和旧版本的应用并存，前者用绿色标明，后者用蓝色标明。如果一个服务在前后两个版本中都存在且没有变化，那么会使用黄色标记，表示这个应用在蓝绿发布中不会出现任何变化。
选择“路由列表”之后再点击“设置服务权重”，调整与之对应的路由权重。如图所示，旧版本服务的权重为100，新版本服务的权重为0；下面我们将旧版本服务的权重调整为0，新版本服务的权重调整为100。
由于默认路由服务是进行会话保持的，您可以打开一个新的浏览器窗口，访问新的版本，结果如下。
当整个发布流程验证完毕后，需要进行发布确认，方可进行下一次发布。
点击发布确认后，查看应用的详情，可以看到应用的服务列表已经更新了，旧的服务已经完全下线删除了。
复杂拓扑下的蓝绿发布
场景分析
大于大多数场景而言，对客户提供服务的软件的形态有三种。一种是前端类服务，用户可以直接或者间接通过网页、接口调用使用该服务提供的能力；一种是后端类服务，用户无法直接使用该服务提供的功能，该服务主要的使用者是其他服务，并通过其他服务最终将处理后的结果反馈给用户；第三种是调度任务类服务，即不被用户使用也不被其他服务调用，它的生命周期只存在在一个任务的执行生命周期中，通常任务的执行周期完毕，服务的生命周期就停止，通常为无状态资源密集性服务。
对于上述三种场景，以路由权重切换为主要实现方式的发布策略例如蓝绿发布、A/BTest等通常情况下比较适用于前端类服务与后端类服务。下面我们用一个简单的例子来拆解下如何使用阿里云容器服务来实现这两类服务的蓝绿发布。
在上一篇发布策略的文章中，有的开发者会问我的应用的拓扑关系不是单体的，不能通过单一容器级别的路由权重切换解决。在此要明确的一件事情，蓝绿发布是一种发布策略，部署的最小维度是容器，而发布的最小维度是应用。蓝绿发布的原理是老的应用的版本不变，新的应用版本进行部署，如果新版本与老版本之间应用的名字以及相关的配置没有改变，那么会认为这个应用是新老版本*用的，无需变更；需要进行变更的应用通过名字的不同进行区分。简单的来讲，蓝绿发布是一个应用级别的更新操作，你可以对一个服务进行两个版本之间的切换，服务是一个逻辑的概念，而不是容器这样一个实体的概念，蓝绿发布可以做复杂拓扑的应用更新操作。
DEMO
下面我们通过一个拓扑结构复杂一点的例子来讲述蓝绿发布。应用的拓扑结构如下：
serviceB会调用serviceA，这两个都是python构建的，代码如下：
serviceA通过接口返回数据“world!”
serviceB调用serviceA的接口，并将返回的数据字段前面添加“Hello ”
传统应用之间的调用方式可以是通过配置IP地址或者域名来调用，也可以通过服务注册中心中的地址的方式调用，但是对于一个无状态的多实例的服务，常见的做法是使用客户端的负载均衡器或者服务器的服务均衡器端点来实现。在容器服务中使用的方式是使用服务器端的负载均衡端点的方式，提供内部调用的路由端点，来实现后端服务的负载均衡。大致的调用方式如下。
serviceB通过external_links的方式将serviceA的内部路由端点引入，在环境变量中将
dep_endpoint=http://servicea.local，使用servicea.local作为调用的地址。
访问serviceB的对外访问地址，可以得到：
我们最开始基本结构的应用就已经部署完毕了，下面开始进行不同服务的蓝绿发布。
前端服务的蓝绿发布
首先我们先看如果做前端服务的蓝绿发布，也就是说要对serviceB进行蓝绿发布的流程。大致的结构图如下。
在这个应用中前端服务的蓝绿发布，也就是对serviceB进行蓝绿发布，下面我们修改serviceB的代码
修改编排模板，进行蓝绿发布
进行蓝绿发布更新后，可以看到更新后的服务列表，其中黄色的serviceA-v1表示当前的应用在蓝绿发布的过程中不会产生变化，serviceB-v1为老版本，serviceB-v2为新版本
通过路由列表选择相应的权重管理，进行权重的调整，将serviceA-v1的权重调整为0，将serviceA-v2的权重调整为100，此时访问serviceB的网址可以发现。
验证完毕，点击确认发布完成，完成蓝绿发布。
后端服务的蓝绿发布
我们再看下如何做后端服务的蓝绿发布，也就是说对serviceA进行蓝绿发布。大致的结构图如下。
修改编排模板
部署后的服务列表：
此时可以发现serviceB-v2在本次发布中不会进行变更，调整服务的权重
此时再访问serviceB的地址，可以得到如下的结果
总结
蓝绿发布是一种用于升级与更新的发布策略，对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求，希望给位开发者可以在自己的业务场景中，更灵活的使用和实现蓝绿发布。