来自 Web前端 2020-01-18 01:08 的文章
当前位置: 网上澳门金莎娱乐 > Web前端 > 正文

前端工程化:构建、部署、灰度

时间: 2019-08-18阅读: 135标签: 工程化

过去的10年里,很多大公司都在使用蓝绿部署,安全、可靠是这种部署方式的特点。蓝绿部署虽然算不上”Sliver Bullet“,但确实很实用。在有关于“微服务”、“DevOps”、“Cloud-native”的讨论中,蓝绿部署、A/B测试、灰度发布,这三种部署方式往往同时出镜。

优秀的技术方案很多,大部分时候我们感觉只是在现有技术方案里面做排列组合、求笛卡尔积、选择最优解,做出一个最适合当前项目的方案。未来,人类应该编写最核心的业务代码、设置规则,由云端和AI来根据当前项目情况自动选择和调整到最优的架构和方案。

那么问题来了,蓝绿部署、A/B测试、灰度发布,这三者之间究竟有何不同?

前言

蓝绿部署

Martin Flower曾在文章中阐述了蓝绿部署的整体要点,建议大家看看。

基本上,蓝绿部署是一种以可预测的方式发布应用的技术,目的是减少发布过程中服务停止的时间。

简单来说,你需要准备两个相同的环境(基础架构),在蓝色环境运行当前生产环境中的应用,也就是旧版本应用,如图中App1 version1、App2 version1、App3 version3。

网上澳门金莎娱乐 1

当你想要升级App2到version2,在蓝色环境中进行操作,即部署新版本应用,并进行测试。如果测试没问题,就可以把负载均衡器/反向代理/路由指向蓝色环境了。

网上澳门金莎娱乐 2

随后你需要监测新版本应用,也就是App2 version2是否有故障和异常。如果运行良好,就可以删除App2 version1使用的资源。如果运行出现了问题,你可以通过负载均衡器指向快速回滚到绿色环境。

理论上听起来很棒,但还是要注意一些细节:

  • 当你切换到蓝色环境时,需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理,会是一个比较麻烦的问题;

  • 有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况,如果在蓝绿部署中协调不好这两者,还是有可能导致服务停止的;

  • 需要提前考虑数据库与应用部署同步迁移/回滚的问题;

  • 蓝绿部署需要有基础设施支持

  • 在非隔离基础架构(VM、Docker等)上执行蓝绿部署,蓝色环境和绿色环境有被摧毁的风险

前端项目的工程化,不只对开发层面的组件化、模块化、规范化等,更涉及到构建、部署的工程化和自动化。工程化的一些概念,编译、构建、部署、发布、CI/CD、灰度等概念,其实都是软件工程中很成熟的概念,现在前端项目中也快速发展起来。

A/B Testing

A/B测试跟蓝绿部署完全是两码事。

A/B测试是用来测试应用功能表现的方法,例如可用性、受欢迎程度、可见性等等。A/B测试通常用在应用的前端上,不过当然需要后端来支持。

网上澳门金莎娱乐 3

A/B测试与蓝绿部署的区别在于,A/B测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论,并确信该结论在推广到全部流量可信;蓝绿部署的目的是安全稳定地发布新版本应用,并在必要时回滚。

A/B测试和蓝绿部署可以同时使用。

大部分知识在前后端项目中都是通用的,有些则根据项目有不同之处。

灰度发布/金丝雀发布

灰度发布是在原有版本可用的情况下,同时部署一个新版本应用作为“金丝雀”(金丝雀对瓦斯极敏感,矿井工人携带金丝雀,以便及时发发现危险),测试新版本的性能和表现,以保障整体系统稳定的情况下,尽早发现、调整问题。

网上澳门金莎娱乐 4

灰度发布/金丝雀发布由以下几个步骤组成:

  • 准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。
  • 从负载均衡列表中移除掉“金丝雀”服务器。
  • 升级“金丝雀”应用(排掉原有流量并进行部署)。
  • 对应用进行自动化测试。
  • 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
  • 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)

名词解释

总结

对于云计算来说,以上三种策略都是可用的。不难想象,通过docker和kubernetes,我们可以很简单的实现蓝绿部署、A/B测试、灰度发布……比如好雨云,深度整合Docker和Kubernetes,提供给用户包括代码滚动上线、一键代码回滚等功能和特性在内的强大的CI/CD体验:)

Author Christian Posta
Trans by 好雨科技

很多人对一些名词的理解是会有或多或少的误差的,在做一些事情之前,必然得把这些概念理解。

编译和构建构建产物(Artifacts)部署、发布蓝绿部署、滚动部署、金丝雀发布(灰度发布)、A/B测试编译和构建

编译(compile)和构建(build)概念有一些区别。

编译是指将源代码变为目标代码的过程,从源代码的语言转变为另外一种计算机语言(一般为比源代码语言更为底层的语言)。

构建是指一些列的处理,包括编译。不同的语言构建会有不通的处理步骤,最终产生可在具体特性环境运行的Artifact。

前端的编译。为了更好的编程体验和更高的可维护性,会使用一些超集的语言,然后再转译为浏览器可以运行的语言。例如对 es5/6/7 等语法的转译为对应环境支持的代码;less、sass 等转译为 css;typescript、coffeescript 等转译 javascript 。

前端构建过程一般包括以下几个过程:

代码检查运行单元测试等语言编译依赖分析、打包、替换等代码压缩、spirit 图片压缩等版本生成

构建结果一般生成为一个或多个文件,里面包括直接可以在部署在特定环境中的所有内容。

Artifacts

每一次成功构建后产出的结果,被称为 Artifacts。Artifacts 可以直接部署到特定环境中并正常运行。每个构建结果一般都会版本保存,为后续部署、回滚、灰度等。

可能是因为构建的速度,后端都会有一个 Artifacts 制品库。而早期一般的前端项目对 Artifacts 的概念比较弱化(更早的前端项目直接没有构建的概念)一般会从 Code 直接构建部署到指定的环境。现有的规范化的项目都会有对构建产物所有版本的保存,一般都提供CND来访问。

部署、发布

部署(deploy)是指把构建后的新版本应用或服务“安装”到目标环境(开发、测试或者生产)中。这时候部署好的应用或服务应该是在目标环境中正常运行着(或者待着),但是不会有任何访问的流量。

发布(release)则是把新版本应用或者服务交付给最终用户使用的过程。相当于把流量切到部署好的新版本的过程。

前端项目部署一般是指文件的增量替换或全量替换。根据项目按需决定,部署和发布可以同时进行,也可以分开进行,前提是在不影响用户访问的同时,把前端的代码更新到相应的版本。

CI/CD

CI,Continuous Integration,持续集成。指代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。目的就是让产品可以快速迭代,同时还能保持高质量。

CD 对应有两个意思:CD,Continuous Delivery,持续交付。指的是任何的修改都经过验证,可以随时实施部署到生产环境。CD,Continuous Deployment,持续部署。持续部署是持续交付的更高阶段,指的是任何修改后的内容都经过验证,自动化的部署到生产环境。

两者的区别,在于是否自动部署到生产环境。持续交付,需要用户手动点击“部署”按钮才能部署到生产环境。

前端项目的 CI/CD ,因为一定的特殊性,对通用化的库或框架可以有覆盖率很高的单元测试/自动化测试,然而对业务代码的单元测试、端对端测试则成本很高,所以 CI 的过程一般就是运行构建脚本,未报错的生成静态文件则为成功。一般不会有 CD(持续部署) 的过程,合并到 develop 分支触发 CI 成功后快速发布部署到测试或预发布环境通过测试人员的测试和一定的自动化测试。到需要发布的时间点,再拉取 master 分支来构建部署发布。

蓝绿部署

蓝绿部署中,绿色代表代表正在给用户提供正常服务的系统;蓝色代表另外一套准备发布的系统,还未对外提供,可以做线上测试。

二套系统必须有相同的基础设置和配置环境,当蓝色系统测试通过,达到上线标准,就把绿色系统的流量全部切到蓝色系统中,一旦蓝色系统出现问题,把所有流量切回到绿色系统中,待蓝色系统稳定后就成为新的绿色系统,之前的绿色系统资源就可以释放用于下一个蓝色系统。

蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的,如果目标系统相当复杂,那么如何切换、两套系统的数据是否需要以及如何同步等,都需要仔细考虑。

滚动部署

网上澳门金莎娱乐,有多个集群实例的服务中,在不影响服务的情况下,停止一个或多个实例,进行版本更新,再启动加入到集群中提供正常服务,直到所有实例都更新到最新版本。

比起蓝绿部署不需要准备二套一样的集群,通过现有的机器或增加少量的机器就可以做到版本升级。但也引入了复杂度,需要控制好更新过程中服务会有新老版本用户共存的兼容情况、防止部署过程中自动伸缩的触发导致实例中版本的不确定、部署过程中出错的回滚策略等。

金丝雀发布(灰度发布)

一种比滚动部署更有控制力度的发布策略。

准备一个或多个服务实例(使用新机器或已有的机器都可),并确保该实例服务没有服务于线上的用户,在上面部署新版本的服务,并经过测试的验证。

通过定制好的策略,只更新部分服务实例到最新,使一部分用户使用到最新版本,如果服务正常,逐渐更新所有服务实例到最新。

发布过程中,需要有一些流量控制的策略跟随部署的过程,一般可以在负载均衡、路由、应用程序中做处理。

针对用户级别分流。比如先部署给内部用户,在逐渐根据外部用户的分类等级扩散。地域、IP 级别分流。只部署新版本到某地理地域,慢慢扩大到全量发布。应用程序中判断特性分流。比如通过什么渠道使用服务的、浏览器特征分析、某个使用触发才使用新版本。A/B测试

本文由网上澳门金莎娱乐发布于Web前端,转载请注明出处:前端工程化:构建、部署、灰度

关键词: