常见应用发布方式浅析

倖福魔咒の 提交于 2020-01-20 03:29:52

作者:齐凯华,王文勤
时间: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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!