每次听别人说到各种部署方式时，都多多少少听到有人信誓旦旦的将下面提到的部署方式张冠李戴了，有时候甚至自己也被弄糊涂了，作为一名程序猿，还是做到心中有数的好，这可是基础。
备注： 这个原本记录在自己OneDrive里面，正好有人和我讨论，于是share出来顺便自己也review下。
先根据使用目的给它们分分家吧！
线上平稳发布（部署）手段：
蓝绿部署灰度发布（金丝雀发布）滚动发布红黑部署效果验证手段：
AB测试 蓝绿部署首先，这是用于0 downtime应用上线时的一套部署策略。
其次，要知道蓝绿部署无需停机，不停止老版，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
再次，说明下流量管理，在部署新版本之前，需要将部署新版本的流量掐断，全部打到ok的老版本上。
最后，点一下注意使用条件，需要有两倍的机器资源。
Tag: 全量切换
灰度发布（金丝雀发布）主要有个故事关于矿工下矿前会用金丝雀去探测是否有毒。
不停止老版本，额外搞一套新版本，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。不同版本应用共存，经常与A/B测试一起使用，用于测试选择多种方案。
大致过程简述：
掐断“金丝雀”服务器的流量；“金丝雀”服务器更新升级到新版本；在“金丝雀”服务器上对应用进行自动化测试。将“金丝雀”服务器重新配置到LB中（连通性和健康检查）。如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）因此，它是对某一产品的发布逐步扩大使用群体范围的一种发布方式，让用户尽早参与，获取用户反馈，完善产品功能，提升产品质量。
对于这个，我比较关注灰度发布如何落地。其实可以归纳为流量控制和数据收集。这样既能做风控又能辅助产品做决策。
1. 精确的流量分发控制
需要有确切的策略保证某特征用户访问新版本，某特征用户访问老版本。从产品角度看要做A/B test，必须控制测试样本。
2. 做监控
运维: 错误率，吞吐量，延迟，cpu内存消耗PM: pv, uv3. 需要灵活发布应用
周期可能会持续很久，所以新旧版本会并存。同时，还有可能各个版本需要各自迭代。版本之间能够区分对应的监控日志信息。
Tag: 小批次切换
滚动发布一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
比蓝绿部署节约资源，但是服务器节点数量多，会很慢。
部署过程简述：
发布一台金丝雀，主要做流量验证。需要准备好发布工具和智能LB，平滑的版本替换和流量的拉入拉出。每次发布先将老版本V1流量从LB移除，然后清楚老版本，发新版本V2，再将LB流量接入新版本。一次滚动式发布一般由若干个发布批次组成，每批次发布数量可配置。并且每批次之间有时间间隔，所以导致滚动发布过程比较缓慢。回退，发布的逆过程，所以一样缓慢。Tag: 批量切换
红黑部署这是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，所以它利用AWS的特性，在部署新的版本时，通过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration创建新的服务器。测试不通过，找到问题原因后，直接干掉新生成的服务器以及Autoscaling Group就可以，测试通过，则将ELB指向新的服务器集群，然后销毁掉旧的服务器集群以及AutoScaling Group。
红黑部署的好处是服务始终在线，同时采用不可变部署的方式，也不像蓝绿部署一样得保持冗余的服务始终在线。
需要注意： 在蓝绿色部署中，两个版本可能暂时同时获取请求，而在红黑中，只有一个版本在任何时间点获得流量。
AB测试这个也叫做对照实验，重点是在几种方案中选择最优方案。
这是一种产品优化中的应用方法，在产品正式迭代发版本之前，为同一个目标定制两个或以上种方案，将用户流量对应分组，在确保每组用户特征相同的前提下，让用户分别看到不同的方案设计，根据每组用户的真实数据反馈，科学的帮助产品进行决策。
简单说就是将多种设计方案暴露给用户，分组对照测试，让用户在使用后决策哪种更优。
A/B测试的应用方式决定了它拥有的三大特性： 先验性、并行性和科学性。
先验性： 分组对照试验，由试验结果得出结论。并行性： 多组试验同环境同时间进行，更加科学客观对比优劣，且节省验证时间。科学性： 指的是流量分配的科学性——将相似特征的用户均匀的分配到试验组中，确保每个组的用户特征相似，避免有数据偏差，使得结论更具有代表性。优化内容：
产品UI文案内容页面布局产品功能推荐算法应用场景：
灰度发布广告着陆页Web/H5页面App用户体验媒体广告投放与管理