常见应用发布方式浅析_应用发布方式有哪些

作者：齐凯华，王文勤
时间：2018-04-12

---

一、部署方式浅析

1.滚动部署

1.1滚动部署介绍

1.1.1 基本概念

滚动部署：逐步替换线上应用实例的版本

1.1.2 实现方式

从LB控制用户到应用实例的请求，如某服务共计10个实例，每次更新两2个实例，则首先从负载均衡上摘除两个实例并更新，升级完毕后在LB中重新接入这两个实例，然后依次升级全部实例。

（图1）

（图2）

（图3）

1.2滚动部署优缺点

滚动部署的实现原理简单，其作为一种常用的应用更新方式，在使用的过程中具备以下优缺点：

1.2.1 优点
可以保持0 downtime ，实现了不停服更新
相对某些部署方式比较节省资源
1.2.2 缺点
在一段时间内，线上运行两个不同版本，出现问题时，无法保证一个稳定的线上环境
部署时间不可控、回滚困难
对做好不同版本与数据库、缓存等兼容性问题要求很高

2.蓝绿部署

2.1 蓝绿部署介绍

2.1.1 基本概念
蓝绿部署涉及两个生产环境，蓝色环境指当前正在使用的生产环境，绿色环境指将要发布新版本的环境（热备环境），通过在两个生产环境中切换流量来实现应用版本的更新。应用更新时，蓝色环境仍然对外提供服务，绿色环境升级应用版本，测试通过后，通过负载均衡变更，将流量指向绿色环境。

2.1.2 实现方式
如下图所示，在负载均衡上配置两个分组A和B（通常一个是offline，一个是online）,对offline环境中的应用进行版本更新，并最终将该环境接入线上（online）。

（图4）

（图5）

蓝绿部署的基本理念就是保证一个可以实时提供服务的线上环境。真正实现蓝绿部署也可以采用不同的方式，如蓝绿两个环境是否都对外提供服务，每个分组下要设置多少基础资源等都会有所差异。

2.2 蓝绿部署优缺点

2.2.1 优点

• 在绿色环境（offline）下进行新版本测试，测试过程与生产环境隔离，不会影响用户访问
• 当绿色环境（offline）升级完成后，只需要重定向用户流量，操作比较简单、易实现，实现 0downtime
• 将更新后的绿色环境接入生产环境并问题发生时，可很方便地从绿色环境回滚到蓝色环境，无需重新构建
• 蓝绿发布实现了应用版本的平滑发布，并提高了发布效率
  2.2.2 缺点
• 冗余会产生的额外维护、配置的成本，以及服务器本身运行的开销
• 不同环境之间切换时，新版本应用是否能对切换前用户的请求产生正确的响应

3.灰度部署/金丝雀发布

3.1灰度部署基本介绍

3.1.1 基本概念
灰度发布是采用从0到1、平滑过渡的方式完成应用发布，类似于蓝绿部署，但又不完全相同。灰度发布采用对用户有筛选的分流机制，将新版本应用只针对少量用户开放，在保障整体系统稳定的情况下，尽早发现、调整问题，这种方式也叫金丝雀发布。

3.1.2 实现方式
最简单的灰度发布可以在负载均衡处设置权重来控制。在负载均衡下，设置一个分组，该分组就是用来根据少量用户来提供新功能、版本测试的金丝雀分组。如图8、9所示，金丝雀分组有2台nginx服务器，权重为1；另外一个分组有4台nginx服务器，权重为2，整个金丝雀分组就能分担12/(24+1*2)=0.2 即20%的用户流量了。

（图6）

（图7）

3.2 灰度部署优缺点

灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度的最小化。它在使用过程中有一些优缺点：

3.2.1 优点
在技术上降低风险，通过小用户量发现问题并去解决问题
降低峰压，全量上线一个新功能可能导致流量陡增，对后端服务器造成很大压力
3.2.2 缺点
时间成本高，整个灰度从前期的灰度策略直到最后完全上线要耗费很大的时间
同时维护新旧两套代码、两套配置，以及版本之间的耦合问题

4.跨区域部署/灾备部署

4.1跨区域部署基本介绍

4.1.1 基本概念
跨区域服务部署就是将业务部署在不同区域的两个或多个机房

4.1.2 实现方式
跨区域部署一方面提升用户体验，让用户访问到离自己最近的数据中心；同时这也是一种灾备的考量，可以应对机房断电、自然灾害等严重事故，提升服务的可用性。跨区域部署的应用分布过程可用如下图进行表示：

（图8）

（图9）

（图10）

4.2跨区域部署优缺点

4.2.1 优点

• 提升用户体验
• 提高了整个业务的容灾能力
• 类似于蓝绿发布多分组发布的优点

4.2.2 缺点

• 跨区域部署如何处理数据同步的问题
• 应用更新时，单机房承受能力
• 资源冗余、成本较高

5.不可变部署

5.1不可变部署基本介绍

5.1.1 基本概念
不可变部署的一个重要概念就是不可变基础设施。不可变基础设施的构想是任何基础设施（包括服务器、容器等各种软硬件）一旦创建之后便不可对其进行任何更改。如果需要修改或升级该基础设施上的实例，唯一的方式就是创建一批新的实例以替换之。基于不可变基础设施，每次部署都从头开始，重新创建服务器，安装新版本的服务以及应用对应的新配置。在测试通过后，将负载均衡指向新的服务器集群，同时干掉旧的服务器集群，这样一种部署方式称为不可变部署。

5.1.2 实现方式
要支持不可变部署，需要制定虚拟化解决方案，尤其要具备通过工具/平台的方式动态创建服务器、更改配置，其实现的过程可用以下图表示：

（图11）

(图12）

（图13）

5.2不可变部署优缺点

不可变部署虽然在2013年才提出的构想，但基于目前各种开源软件以及云计算平台的发展，不可变部署有了很好的实践，得益于它维护简单，降低了运维的成本，提高了部署的成功率。当然它也存在一些缺点，比如需要更加流畅和稳定的自动化运维平台、较高成本的云计算平台使用。

6.直接替换部署

6.1直接部署基本介绍

6.1.1 基本概念
应用部署的时候停止服务，并对外提供维护页，应用部署完毕后，重新对外提供服务。

6.1.2 实现方式

（图14）

（图15）

（图16）

6.2直接部署优缺点

直接部署的方式一般应用于服务器需求较少的业务，这种方式降低了资源成本，部署起来也相当方便；它的缺点就是业务需要停止服务，如某些证券公司在不开盘的时候都会停服维护。

7. 红黑部署

7.1 部署方式介绍

7.1.1 基本概念
红黑部署是一种冷备式的蓝绿发布，采用的是一种不可变发布方式。在AWS提供的服务中，部署新的版本时，会通过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration创建新的服务器。测试通过后，则将ELB指向新的服务器集群，然后销毁掉旧的服务器集群以及AutoScaling Group。

7.1.2 实现方式
如下图19，是AWS中的一种蓝绿发布的框架图，这种设计架构下，可以实现新旧服务器集群的销毁，即实现所谓的红黑部署

（图17）

7.2红黑部署的优缺点

某种程度上，红黑部署是一种改进后的蓝绿部署，通过技术手段实现集群弹性的创建于销毁，降低了资源的冗余节省了成本，并且也更加容易管理和维护。它的缺点就是整体基于AWS的框架平台实现，对于架构复杂或资源是物理机的应用不很适用。

二、部署方式实践

1.京东云电商云业务部署实践

1.1 部署方式介绍

京东云电商云服务是基于微服务架构，web服务有基于java和nodejs两种。在日常的应用迭代更新中，采用的发布方式是一种蓝绿部署的方式。服务存在两个Nginx集群组，分别位于同区域的两个机房，每个集群组下nginx配置是完全一致。正常情况下LB会同时指向这两个反向代理集群组，并各接收50%流量。如下图，在发布变更的时候，切换LB至其中一个分组，并对另外一个集群进行变更；变更完后，会对新发布的版本进行测试回归，然后接入线上，并对另外一个分组进行变更，并最终保证两个分组全部完成版本升级。

（图18）

1.2 为什么采取这种方式

本文第一部分中介绍了蓝绿发布的一些优点，结合我们业务自身架构以及所使用的云产品特性，我们采用这种方式的原因如下：

1.电商云为满足不同租户需求的会有很多产品设计的更迭，基于蓝绿部署，更加方便、高效

2.基于京东云主机的业务部署，资源的冗余可接受

3.同一VPC下，两个分组未做完全数据隔离，两个分组都只对主写数据并底层进行跨可用区数据同步

4.京东云先进的自动化运维平台的有利支持

2.如何选择正确的部署方式

部署方式有很多种，但是真正选择一种部署方式并付诸实践却各不相同。在对蓝绿部署的实践上，在设置单分组集群规模上，要保证单分组可以抗压还要尽量减少资源消耗。我们自身在实践的过程中，单分组可以扛住日常的请求量，因此我们的冗余还是挺大的。

当然，这跟我们平时的流量有关。针对特别大流量的服务，如百度搜索，支持业务本身已经需要特别的多的服务器，更不会为每个模块都设置很大的冗余，因此这种情况下很多模块采用的是滚动发布的方式。

业务部署方式的选择通常跟业务本身的特性相关。如直接部署，停服这种貌似不可接受的方式也会被某些行业使用，就像上面讲到的证券公司周末或节假日维护服务器。因此，选择正确的部署方式，要结合业务属性、资源预算以及运维成本等综合考虑。

参考：

（1）https://helpcdn.aliyun.com/document_detail/57399.html?spm=a2c4g.11186623.6.635.FCCHUs

（2）https://martinfowler.com/bliki/BlueGreenDeployment.html

（3）http://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/

（4）https://aws.amazon.com/cn/blogs/china/performing-bluegreen-deployments-with-aws-codedeploy-and-auto-scaling-groups/

（5）http://www.10tiao.com/html/559/201511/400721710/1.html

（6）http://www.open-open.com/lib/view/open1439889185239.html