互联网项目的部署、发布与测试

本文中部分内容引用自以下文章列表：
https://www.jianshu.com/p/5862d7573bf2
https://www.jianshu.com/p/f7b63a4d1488
https://www.cnblogs.com/duanxz/p/5403980.html
极客时间：朱赟的技术管理课
*说明：本文是对已有概念的讲解，非原创，目的是为了将搜集到的资料更好的呈现给大家。

概念：发布vs部署

部署和发布的概念经常听到，但并不一定都能说得清楚，因此，先在开头澄清一下，方便大家理解：
部署（deploy），指的是我们把一个代码包拷贝到服务器上运行，但并不把它暴露给用户，也就是并不给用户提供服务。这个阶段比较耗时，但因为还没有面向用户，所以风险很小。
发布（release），是把部署好的服务暴露给用户的过程，也就是开始真正上线服务用户了。这个过程可以通过负载均衡的切换很快实现，但风险很大，一旦出现问题损失就会比较大。

1.互联网项目部署方案

1.1蓝绿部署

• 方案说明

蓝绿部署的目的：减少发布时的中断时间、能够快速撤回发布。
引用BlueGreenDeployment说明：It’s basically a technique for releasing your application in a predictable manner with an goal of reducing any downtime associated with a release. It’s a quick way to prime your app before releasing, and also quickly roll back if you find issues.
蓝绿部署，是采用两个分开的集群对软件版本进行升级的一种方式。一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。
最初，没有任何系统，没有蓝绿之分。
然后，第一套系统开发完成，直接上线，这个过程只有一个系统，也没有蓝绿之分。
后来，开发了新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。
这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

蓝色系统不对外提供服务，用来做啥？
用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）
蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统：

切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。
当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。
原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。
蓝绿部署只是上线策略中的一种，它不是可以应对所有情况的万能方案。
蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。
BlueGreenDeployment中给出的一张图特别形象：

• 方案总结

蓝绿部署的优点：
这种方式的好处在你可以始终很放心的去部署inactive环境，如果出错并不影响生产环境的服务，如果切换后出现问题，也可以在非常短的时间内把再做一次切换，就完成了回滚。而且同时在线的只有一个版本。蓝绿部署无需停机，并且风险较小。
蓝绿部署的弱点：
使用蓝绿部署需要注意的一些细节包括：
1、当切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果数据库后端无法处理，会是一个比较麻烦的问题。
2、有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务停止。
3、需要提前考虑数据库与应用部署同步迁移/回滚的问题。
4、蓝绿部署需要有基础设施支持。
5、在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。
6、另外，这种方式不好的地方还在于冗余产生的额外维护、配置的成本，以及服务器本身运行的开销。
蓝绿部署适用的场景：
1、不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。

1.2红黑部署

文档编写时在犹豫是否增加红黑部署的说明，再三思考后还是补充上了。
红黑部署与蓝绿部署其实并没有本质上的区别，通常是在不同工具，或者不同公司内部的叫法不一致造成的。甚至在Spinnaker，Kubernetes和Istio等工具的文档中，这两个术语都指的是相同的东西。
本人也实际搜索了很多文档，确实没有找到两者在本质上的明确区分。大家可以视为同一个技术。

2.互联网项目的发布方案

2.1灰度发布（又名金丝雀发布）

• 方案说明

灰度发布，也被叫作金丝雀发布。与蓝绿部署、红黑部署不同的是，灰度发布属于增量发布方法。也就是说，服务升级的过程中，新旧版本会同时为用户提供服务。
灰度发布的具体流程是这样的：在集群的一小部分机器上部署新版本，给一部分用户使用，以测试新版本的功能和性能；确认没有问题之后，再对整个集群进行升级。简单地说，灰度发布就是把部署好的服务分批次、逐步暴露给越来越多的用户，直到最终完全上线。
之所以叫作灰度发布，是因为它介于黑与白之间，并不是版本之间的直接切换，而是一个平滑过渡的过程。
之所以又被叫作金丝雀发布，是因为金丝雀对瓦斯极其敏感，17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
这就与灰色发布过程中，先发布给一部分用户来测试相似，因而得名。

• 灰度发布／金丝雀发布由以下几个步骤组成：

1、准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
2、从负载均衡列表中移除掉“金丝雀”服务器。
3、升级“金丝雀”应用（排掉原有流量并进行部署）。
4、对应用进行自动化测试。
5、将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
6、如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

• 方案总结

灰度发布/金丝雀部署适用的场景：
1、不停止老版本，额外搞一套新版本，不同版本应用共存。
2、灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。
3、经常与A/B测试一起使用，用于测试选择多种方案。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

2.2滚动发布

滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。
这种方式也有很多缺点，例如：
(1) 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
(2) 修改了现有的环境。
(3) 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚。此时，脾气不好的程序猿很可能想掀桌子，因为回滚是一个痛苦，并且漫长的过程。
(4) 有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。
并不是说滚动发布不好，滚动发布也有它非常合适的场景，比如由于种种限制，公司内部的验证环节无法百分之百模拟真实场景，生产环境的升级需要非常慎重，这种情况下，滚动发布就有了用武之地。

3.互联网项目的测试方案

3.1 集成测试、流量镜像

• 先来看一下镜像的简介：

镜像是指将经过指定端口（源端口或者镜像端口）的报文复制一份到另一个指定端口（目的端口或者观察端口）。

• 镜像目的：

在网络运营与维护的过程中，为了便于业务监测和故障定位，网络管理员时常要获取设备上的业务报文进行分析。
在互联网测试过程中，为了保证测试环境的数据与真实环境尽可能的接近，需要模拟大量的用例。但为了避免出现一些场景下的漏测，测试人员也希望能够拿到真实环境的实际数据进行提前验证，因此就有了流量镜像的场景。
区别于前文提到的蓝绿部署，在流量镜像测试期间，待测试的成果物还未部署到生产环境，仍然是在测试环境中执行。因此不会对用户环境造成额外影响。

3.2 AB测试

• 方案说明

首先需要明确的是，A/B测试和蓝绿部署以及金丝雀，完全是两回事。
蓝绿部署和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。
A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）。
A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。
A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。

在A/B测试中，需要能够控制流量的分配，譬如说，为A版本分配10%的流量，为B版本分配10%的流量，为C版本分配80%的流量。

• 方案总结

原理就这么简单。下面我引用部分《朱赟技术管理课》中的经验，重点说一说 A/B 测试中需要注意哪些问题，观点会比较侧重于工程师视角，但是对产品经理也会有帮助。
第一点：永远不要过分相信你的直觉。 有时候，我们会觉得一个功能特征的改动是理所当然的，更新后效果肯定更好，做什么 A/B 测试，这显然是画蛇添足。
这就像一个资深的程序员修改线上代码一样：这样改，一定不会出问题。我们当然不否认这样的情况存在，但每当你开始有这样的念头时，我建议你先停下来，仔细地想一想，是不是就不那么确定了呢？
把你的想法和别的工程师、设计师、产品经理深入交流一下，看看他们会不会有不同的意见和建议。不同的角色背景也不同，考虑问题的方式也就不一样。当你不确定哪种方式更好的时候， A/B 测试就是你最好的选择。
第二点：实验样本的数量和分配很重要。 如果你的实验注定没有太多数据，也许就不要去做 A/B 测试了，小样本偏差会很大，帮不了太多的忙，除非你的测试结果出现“一边倒”的情况。
另外，请确保你在 A 组和 B 组随机分配的数据是绝对公平的。也就是说，你的分配算法不会让两个桶的数据产生额外的干扰。
比如，不要按不同时间段把用户分配到不同的组里，因为在不同时间段使用产品的用户本身就会出现一些不同的情况。区域分配也存在同样的问题，这些都可能导致偏差。
第三点：分析的维度尽可能全面。 文章开头举的例子是说，虽然你最在乎的是用户转化率，但是功能改动可能会影响很多指标，这些指标都要尽可能地测量和分析。
比如，虽然 A 组转化率略高于 B 组，但是 A 组点击后会引发 API 调用流程的变化，结果延迟高出很多，或者出错率变高了，那么 A 依然不是更好的设计。
换句话说， A/B 测试不能只关注单一指标，测试目标虽然是转化率，但倘若高转化率的方案会导致其他风险，比如提高了出错率，也应当舍弃。
第四点：其它组的改动对 A/B 测试产生的影响。 当 A/B 测试成为一个广泛使用的工具后，产品很多特性的改动都会用到这个工具。这也就意味着，当你在采集数据做分析的时候，别人也在做同样的事，只不过策略和数据样本不同。
换句话说，你在跑 A/B 测试比较 A 和 B 的优劣，另一个同事在跑 A/B 测试比较 C 和 D 的优劣，结果因为实现细节的原因， A 组中大部分样本同样也是 C 组改动过的样本。这样一来，两个实验可能就会相互影响。因此，你要做足够的分析，确保实验结果考虑到了这种相关性的影响。
第五点：比较值的趋势必须是收敛的，而不是发散的。 要想比较结果有实际的统计意义，一定是每天采集数据的比较结果逐步收敛，最终趋于稳定。如果一周内 A 比较好，后面又开始波动， B 变得更好，这样来回波动的结果是没有太大参考价值的。
另外，即使比较值趋于稳定，还要确保这个稳定数据所处的阶段不在一个特殊时期。如果恰好有促销或者类似的市场活动，那么即便获得了稳定的结果，这个结果也不一定是普适的。
第六点：数据埋点。 数据的埋点和采集是 A/B 测试成功的关键。
怎么样进行埋点呢？总体来说，这其实和每个公司的代码架构有很大的关系。公司使用哪种方式触动事件、记录事件，尽可能地重用。
前端埋点一般可以采集实时数据，后端埋点可以采集实时事件，也可能是一些聚合数据。要视具体情况和应用而定。
第七点：形成一个流程，或者设计一个工具。 这一点很重要。 A/B 测试作为一个工具，只有在它足够灵活、好用的情况下，才能更广泛地应用到日常的产品迭代和开发中。虽然说这个方法很简单，但是做好一套包括埋点、采集、处理和具备 UI 的工具，会让工程师事半功倍。
第八点：试图给每个结果一个合理的解释。 不用过分相信数据，也不要拿到什么分析结果都照单全收。试着去给每个结果一个合理的解释，不要觉得结果比期望值还好，就不用思考为什么结果如此完美。这可能并不是一件好事情，实际情况是：如果解释不了，可能它就是个 Bug。
第九点：必要的时候重新设计实验。 很多实验会有不同版本，每个版本都会根据实验结果做一些改动和调整。如果发现实验设计上有漏洞，或是代码实现有问题，那就需要随时调整或者重新设计实验，重新取样、分析。实验的版本控制，会让分析和重新设置的过程更加快捷。
第十点：不同客户端分开进行实验。 
Web 端、 iOS、 Android 尽可能分开观察。很多时候你会发现，同样的实验数据对比，在不同的客户端会有完全不同的结果。如果不分开，很可能让数据变得难以解读，或者出现“将只对移动客户端成立的结果扩展到 Web 端”，这样以偏概全的错误。