1. 灰度的来源

当软件升级迭代在遇到架构或功能大改动（技术层面），或是需求和操作的大调整（用户体验层面），往往不是全量发布，而是先小范围发布，没有问题再增量到全部用户，这一过程，类似由白到黑的过度，而白与黑之间均为灰色，所以这一部署过程也叫灰度测试

2. 目的

灰度测试是软件发布的一种测试方法，它通过向一小部分真实用户开放测试，接收他们的真实使用反馈和及时修复问题，从而降低改动带来的风险。

3. 流程

灰度测试的流程可以概括为以下几个步骤：

1. 确定测试目标和测试人员：在灰度测试前，需要明确测试的目标和测试人员，以便确定测试的范围和测试指标。
2. 确定策略：包括部署策略、用户规模、覆盖率和回滚策略。
3. 分批次放量：需要分批次放量，先将新版本软件部署给一部分用户使用，观察其运行情况。如果没有问题，再逐渐扩大用户量，直至将新版本软件全部部署。
4. 收集反馈和修复问题：在测试过程中，需要及时收集用户的反馈和问题，对问题进行分析和修复
5. 再次发布新版本，确保没问题后逐渐扩大用户覆盖范围，直到100%全覆盖

4. 注意事项

1. 在真实环境下进行灰度测试，尽可能模拟真实的用户使用场景。
2. 分析测试结果，并及时修复问题。
3. 有一个完善的测试计划和测试指标，以便于评估测试的效果。

综上所述，灰度测试是软件开发过程中不可或缺的环节，可以帮助开发人员及时发现和修复问题，提高软件的质量和用户体验。但是，在进行灰度测试时需要注意相关的注意事项，以确保测试的有效性和可靠性

5. 部署

本章图片均搜自谷歌，如有冒犯，请联系我删除

5.1 蓝绿部署

蓝色为原始版本环境，绿色为新版本环境

简单的说，就是在不停掉原版本的基础上，增加机器部署新版本，可以采取以下步骤：

1. 首先，需要准备两组环境，其中一组是当前正在运行的环境，另一组是新版本的环境，新版本环境要能撑住100%的访问量
2. 然后，将新版本部署到新环境中，并进行内部测试
3. 接着，将新环境中的机器逐步加入到原有的负载均衡器中，这样一来，新版本就可以逐渐的被部署到线上环境中
4. 当负载均衡100%指向新版本机器，测试各指标依然正常后，旧版本机器下线

需要注意的是，在蓝绿部署前要确保一点，新版本可以兼容旧版本的数据，包含数据库、后端接口或是前端的数据处理，并且在非隔离环境（VM，Docker）下，蓝绿环境均可能被不同版本的包或冲突，导致异常而宕机的风险

蓝绿部署的优点

1. 无需停掉原服务，不影响升级过程中，短暂无法访问所带来不友好的用户体验
2. 降低新版本风险，一旦发现新版本有重大问题，可以直接在负载均衡停掉新版本指向，而无需进行回滚

缺点：

1. 增加硬件成本，需要新增机器来部署新版本，在大型集群的环境，这种方式几乎不会采用
2. 数据库处理，新旧版本同时运行，即可能同时写入新旧格式的数据，对于版本迭代完全完成后，可能需要人工进行处理一些数据
3. 对于微服务架构，新旧版本可能会导致服务中止

5.2 滚动部署

在现有的集群环境中，逐个节点升级版本，直到所有节点升级完成

这种部署方式，无需新增硬件成本，只在原有环境进行升级发布

但是缺点就是回滚相当麻烦，而且定位问题相对困难

升级节点过程中，比如升级v2.0，当完成50%节点发现了问题，此时需要紧急更新补丁v2.1，于是有50%的节点需要从v2.0升级成v2.1，而此过程中，就有v1.0/v2.0/v2.1三个版本共存，如果此时有用户上报问题，需要定位时哪个版本产生的bug就比较麻烦

而且还有种极端情况，升级到90%的时候，发现新版本存在大访问量时的数据库缺陷，需要进行回滚，那简直是人间地狱

5.3 灰度部署

灰度部署也叫金士雀部署，来源是17世纪，英国旷工发现金士雀对瓦斯气体非常敏感，嗅觉到极微量的瓦斯时便停止歌唱，所以在下矿场时会用金士雀作为探测器使用

跟滚动部署有点类似，只需在现有环境部署

1. 从负载均衡停掉小部分节点
2. 停掉的节点进行金士雀版本升级
3. 负载均衡重新引入小部分真实用户到金士雀版本
4. 收集真实用户反馈，和各项测试指标
5. 进行全量升级

灰度部署网上有另一种说法，就是真实测试后进行增量升级，而非全量升级，那样就变成滚动部署了，我是觉得金士雀测试瓦斯，只有安全和不安全两种情况，所以测试后，只有回滚和全量升级两种情况

不管怎样都是需要结合真实环境做改动，一切从需求出发