蓝绿发布/金丝雀发布/A-BTest 区别
31 May 2023 - joy717
蓝绿发布/金丝雀发布/A-BTest 区别
前言
在讨论蓝绿发布、金丝雀发布、A-B Testing之前，让我们先看看早期发布一个应用时候，是怎么发布的。
传统发布应用的时候，往往采用的停机发布。发布流程一般为：
- 停机
- 发布
- 测试
- 测试一切正常，则对外开放。若有问题，则需要重新回滚回旧版本。
这样发布的弊端：
- 必须停机、停止服务，意味着客户无法使用，造成损失
- 在发布过程中的测试流程，必须尽可能的快，减少维护时间。
- 若新版本有问题，回滚的成本比较高。
在这个问题上，Dave Farley 与 Jez Humble 在 持续集成（Continuous Delivery）这本书里，提出了蓝绿发布（Blue-Green Deployment）的概念。
蓝绿发布(Blue-Green Deployment)
在生产环境里，准备2套尽可能一模一样的环境。其中一套我们称之为蓝，另外一套称之为绿。在任意时刻，蓝是对外开放的，即用户可以访问到业务。在绿环境里，我们准备了新版本，并在这环境里做最终测试。普通用户访问不到此环境。当绿环境里的应用测试准备完成之后，我们将用户流量导入到绿的环境，同时切断蓝的用户流量。即，蓝、绿角色完成互换。（一般通过LB之类的方式来实现切换）。需要注意的是，在这个发布的过程中，普通的用户是无法访问到新版本的。
流程大致是：
- 准备
绿的环境，部署新版本，进行测试 - 测试完了之后，将用户流量导入到
绿，并且切断蓝的用户流量
相比传统的发布，这种发布的好处是：
- 业务不用停止。
- 测试流程，就不必争分夺秒。
- 若切换到新版本后，发现新版本有问题，可以及时切回旧版本。
需要注意的是，涉及到数据库表结构变动等问题时候，需要进行特别处理。才有可能做到不停机发布。
金丝雀发布(Canary Release)
为了减小新版本的风险，采用，先将一小部分用户流量导入到新版本，待稳定，确认没问题之后，再将其他的用户流量也导入到新版本。 流程大致是：
- 不影响生产环境的服务情况下，部署一个新版本，QA对新版本进行测试
- 测试成功之后，将新版本开放给小部分用户，进行体验。而大部分用户，依然使用着旧版本
- 经过小部分用户一段时间的使用之后，若没问题，则将所有用户流量导入到新版本
- 最终发布新版本完成。
相比传统发布的，优点在于：
- 业务不用停止。
- 可以将风险控制在比较小的程度。
- 若新版本有问题，很方便的就可以将用户流量导入到旧版本中
如何将一小部分用户流量导入到新版本，这就涉及到各种策略。比如：
- 只根据权重，将x%的用户流量导入到新版本。所有用户一视同仁，并不关心具体的用户是谁；
- 将带有特定信息的用户，导入到新版本。特定信息可能存储在url的参数，cookie，header当中。
区别
金丝雀发布与蓝绿发布的区别的主要特征在于：未全面开放的新版本，是否对用户开放。以及多版本同时并存的存续时长。金丝雀发布是对部分用户开放的。蓝绿发布，主要聚焦于新版本的功能测试，测试新版本是否有bug等。而金丝雀发布，更多的时候，是为了避免版本大改动，带来的不确定性（市场是否认可新版本的改动等），采用小步测试市场反应。
AB-Testing
AB-Testing从出发点上，就与前两者不同。前两者是聚焦在部署方式上，为了解决部署时候的"不停机"，减少维护时间。而AB-Testing聚焦在用户身上，关注的是UI上，用户的使用。
比如，UI设计的时候，有时候会很难确定某些行为，什么实现方式更能被用户接受。 举个具体的例子来说，一个按钮，是放在右上角好，还是放在左上角好。这个不一定在设计的时候能够确定。相反的，交给用户来做决定，反而是种不错的选择。于是，在同样一个server端版本的情况下，有2个client端，一个是把按钮放在左上角，一个按钮是放在右上角。不同的用户获取到不同的client端，进而收集用户的使用情况，最终根据用户的偏好，确定按钮的位置的方案。
概念上，与金丝雀很类似，也是一部分用户M使用A版本，另外一部分用户N使用B版本。但是不同点在于，对于金丝雀来说，是小部分试用新版本，而AB-Testing，M,N在数量上并不一定是谁多谁少。并且A版本与B版本并不一定是一个新版本一个旧版本，而有可能两个都是同一个版本。更进一步说，AB-Testing并不是一种部署的方式，而是目的在于用户对于不同的操作、功能的使用反馈。版本上的区别，主要是集中在client端。而蓝绿发布与金丝雀发布，聚焦在server端的部署层面。