运维发布/上线的方式

运维的各种发布方式

线上平稳发布的手段

• 蓝绿发布
• 金丝雀发布（灰度发布）
• 滚动发布
• 红黑发布

蓝绿发布

这是用于 0 downtime应用上线是的一套发布策略

在蓝绿发布的部署的方式中，无需停机，不停止老的版本，另外弄一套新的版本，等测试发现新版本之后，就把老版本删除，运用新版本
在说明流量管理，在部署新版本之前，需要将部署新版本的流量切断，全部弄到老版本上

金丝雀发布（灰度发布）

有个故事关于矿工下矿前会用金丝雀去探测是否有毒。

不停止老版本，额外搞一套新版本，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。不同版本应用共存，经常与A/B测试一起使用，用于测试选择多种方案。

大致过程简述：

掐断“金丝雀”服务器的流量；
“金丝雀”服务器更新升级到新版本；
在“金丝雀”服务器上对应用进行自动化测试。
将“金丝雀”服务器重新配置到LB中（连通性和健康检查）。
如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
因此，它是对某一产品的发布逐步扩大使用群体范围的一种发布方式，让用户尽早参与，获取用户反馈，完善产品功能，提升产品质量。

对于这个，我比较关注灰度发布如何落地。其实可以归纳为流量控制和数据收集。这样既能做风控又能辅助产品做决策。

1. 精确的流量分发控制

需要有确切的策略保证某特征用户访问新版本，某特征用户访问老版本。从产品角度看要做A/B test，必须控制测试样本。

2. 做监控

运维: 错误率，吞吐量，延迟，cpu内存消耗
PM: pv, uv
3. 需要灵活发布应用

周期可能会持续很久，所以新旧版本会并存。同时，还有可能各个版本需要各自迭代。版本之间能够区分对应的监控日志信息。

小批次的切换

滚动发布

比蓝绿部署节约资源，但是服务器节点数量多，会很慢。

部署过程简述：

发布一台金丝雀，主要做流量验证。
需要准备好发布工具和智能LB，平滑的版本替换和流量的拉入拉出。
每次发布先将老版本V1流量从LB移除，然后清楚老版本，发新版本V2，再将LB流量接入新版本。
一次滚动式发布一般由若干个发布批次组成，每批次发布数量可配置。并且每批次之间有时间间隔，所以导致滚动发布过程比较缓慢。
回退，发布的逆过程，所以一样缓慢

批量切换

红黑发布

这是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，所以它利用AWS的特性，在部署新的版本时，通过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration创建新的服务器。测试不通过，找到问题原因后，直接干掉新生成的服务器以及Autoscaling Group就可以，测试通过，则将ELB指向新的服务器集群，然后销毁掉旧的服务器集群以及AutoScaling Group。

红黑部署的好处是服务始终在线，同时采用不可变部署的方式，也不像蓝绿部署一样得保持冗余的服务始终在线。

需要注意： 在蓝绿色部署中，两个版本可能暂时同时获取请求，而在红黑中，只有一个版本在任何时间点获得流量。