软件开发和部署，蓝绿环境、灰度环境

发布策略

目前常见的发布策略有蓝绿发布、红黑发布、金丝雀（灰度）发布、滚动发布等

在项目迭代的过程中，不可避免需要”上线“。上线对应着部署，或者重新部署；部署对应着修改；修改则意味着风险。

蓝绿发布

蓝绿环境是一种有效的软件部署策略，可以帮助企业实现快速、安全、可靠的软件发布和更新。

蓝绿部署是指有两个完全相同的、互相独立的生产环境，一个叫做“蓝环境”，一个叫做“绿环境”。蓝绿环境是逻辑概念，其中处理客户流量的环境是绿环境。蓝环境用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。

这种部署模式允许在升级或发布新版本时，先在蓝环境中进行版本升级和测试，待测试确认一切正常后，再将用户流量切换到蓝环境。在逻辑上，蓝环境变成了新的绿环境，而原来的绿环境则成为新的蓝环境，用于下一轮的版本升级和测试。这种模式通过运行两个相同的环境来减少风险和故障时间，从而确保应用的稳定性和可靠性。

绿环境是用户正在使用的生产环境。当要部署一个新版本的时候，先把这个新版本部署到蓝环境中，然后在蓝环境中运行冒烟测试，以检查新版本是否正常工作。如果测试通过，发布系统更新路由配置，将用户流量从绿环境导向蓝环境，蓝环境就变成了生产环境。这种切换可以在几乎零停机时间的情况下完成。

如果出了问题，把路由切回到绿环境上，再在蓝环境中调试，找到问题的原因。因此，蓝绿部署可以做到仅仅一次切换，立刻就向所有用户推出新版本，新功能对所有用户立刻生效可见。

优势：

实现了新旧版本的无缝切换，减少了停机时间和对用户的影响；
蓝绿部署提供了一个备份环境，如果新版本出现问题，可以快速切换回稳定的蓝色环境，保证业务的连续性和稳定性；
通过在绿色环境中进行测试和验证，可以在将新版本推送给真实用户之前发现和解决潜在问题，降低了部署和发布过程中的风险。

不足：

一次性的****全量切换，如果发布出现问题, 会对用户产生比较大的影响****
*需要两倍的机器资源*
需要中间件和应用自身支持热备集群的流量切换

适用场景：

对用户体验有一定容忍度的场景。
机器资源有富余或者可以按需分配（AWS 云，或自建容器云）

灰度发布

**定义：**灰度发布属于增量发布，新老版本同时为用户提供服务。灰度发布的主要目的是保证系统的可用性。逐步将新版本推送给一部分用户，而不是一次性对所有用户发布的策略。这允许团队收集反馈并确保新版本的稳定性，从而降低发布新版本的风险。而金丝雀发布是灰度发布的一种实现。

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB Test 就是一种灰度发布方式，让一部分用户继续用 A，一部分用户开始用 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

**发布流程：**在现有环境中部署少量服务的新版本（金丝雀），部署完成后，对线上流量进行监测，如果没有问题就对老版本服务进行全量升级。

优点：

降低风险：问题版本影响的用户数量有限。
真实反馈：可以从真实用户环境中收集数据和反馈。

缺点：

复杂的流量控制：需要复杂的路由逻辑来控制哪些用户接收到新版本。
长时间部署：整个过程可能需要较长时间，特别是对于大型用户基础。

适用场景

蓝绿部署适合那些对停机时间极度敏感，以及能够承担额外成本以快速回滚的场景；
灰度发布适合希望逐步推出新功能，收集用户反馈，并愿意投入时间逐步解决可能出现的问题的场景

滚动发布

按批次增量滚动发布，提供更平滑的用户体验。滚动发布通常指取出一个或多个服务，将其停止服务、升级到新版本；周而复始地重复这一过程，直到所有实例都升级到新版本。使用滚动发布，可以最大程度地避免因发布导致的流量丢失和服务不可用问题

优点

按批次增量滚动发布，提供更平滑的用户体验。；
不需要停机更新，无感知平滑更新；
版本更新成本小,不需要新旧版本共存；

缺点

更新时间长：每次只更新一个/多个镜像，需要频繁连续等待服务启动缓冲
旧版本环境无法得到备份：始终只有一个环境存在
回滚困难：如果滚动发布到一半出了问题，回滚时需要使用同样的滚动策略回滚旧版本

A/B测试

A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们[上线时可能采用了蓝绿部署的方式）。

A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。

A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。

环境介绍：

pro环境：生产环境，面向外部用户的环境，连接上互联网即可访问的正式环境。

需要高度稳定和安全，通常关闭错误报告并开启错误日志记录功能。
配置经过严格审查和优化，以满足业务需求和高性能要求。
部署的软件版本经过充分测试，并符合业务需求和质量标准。

pre环境：灰度环境，外部用户可以访问，在配置、网络设置、安全策略等方面保持一致的测试环境，它允许对一部分用户或流量展示新功能或更新，以便在全面推广到生产环境之前进行测试和验证。

test环境：测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定，测试人员对开发完成的代码进行集成测试、系统测试、验收测试等的环境。

配置应尽可能与生产环境相似，以模拟真实运行条件。
包含测试所需的测试数据、测试工具和测试人员。
用于验证软件是否满足需求规格说明书的要求，并检查软件在不同配置和场景下的稳定性和性能。

dev环境：开发环境，外部用户无法访问，开发人员用于编写、调试和测试代码的环境。

配置可能较为灵活，以满足开发过程中的各种需求。
通常包含完整的开发工具链，如IDE、版本控制系统等。
代码可能未经过严格的测试或优化。

灰度环境：

定义：
- 灰度环境是一个中间环境，介于开发和生产环境之间。它允许开发团队将新版本的软件或服务先部署给一小部分用户或流量，以收集实际使用中的反馈和测试其稳定性和性能。
目的：
- 降低风险：通过在小范围内测试新版本，可以避免直接面向全体用户发布可能带来的风险和问题。
- 收集反馈：通过用户在实际使用中的反馈，可以及时发现和修复潜在的问题，优化产品体验。
- 逐步推广：根据灰度测试的结果，可以逐步增加新版本的用户范围，实现平稳过渡。
工作流程：
- 初期：仅允许一小部分用户（如白名单用户）进入灰度环境，使用新版本的功能或服务。
- 中期：根据用户反馈和测试数据，调整或修复发现的问题，并可能扩大用户范围进行进一步测试。
- 后期：如果新版本在灰度环境中表现良好，且没有发现重大问题，可以逐步将其推广到全体用户。
应用场景：
- 新功能发布：在新功能上线前，先对一小部分用户进行灰度测试，以确保新功能的稳定性和用户体验。
- 系统升级：在系统升级前，先对一小部分用户进行灰度测试，以确保系统升级后不会出现严重的问题。
- A/B测试：将用户分为两组，对其中一组用户进行新功能的灰度测试，以比较新旧功能的差异，从而决定新功能是否正式上线。
优势：
- 早期发现问题：通过灰度环境，可以在正式发布前尽早发现和修复问题。
- 逐步推广：灰度环境允许开发团队逐步扩大新版本的用户范围，实现平稳过渡。
- 反馈收集：通过用户在实际使用中的反馈，可以持续优化产品体验。