心里苦，了解业界常见服务发布手段~

前言

最近上线需求，服务发布成功后，不一会，告警群就开始滴滴滴，我一看，擦 空指针了，赶紧根据堆栈以及error日志定位到问题代码的行数，根据代码调用上下文迅速判断出出现空指针场景，提了个fix上线，让leader审批下，然后就被批斗怎么每次都出bug......

哎，虽然在测试环境一切正常，但总有测不到的场景，一上线，问题就暴露出来了，而且不同于绝大多数公司存在单点部署，滚动升级的策略，我们发布就是 一把梭哈，出事了就回滚或者赶紧修

借这个坏心情，整理一下业界常见的服务上线发布方式及流程~

---

服务发布方式

梭哈

目前我们的服务部署了5台机器

1. 再起同等数量的机器，部署新的代码
2. 都起来了之后，将流量全切到新机器上
3. 下线旧机器

称这种方式为梭哈 毫不过分，即使发现告警后及时进行回滚，回滚也需要一定时间，错误代码承接了全部流量，纯纯的风险最大化的操作。

---

单点部署、滚动升级

目前我们的服务部署了10台机器

1. 选择一台机器进行部署
2. 单点部署完毕后，进入容器内部观察一段时间日志，是否存在error日志（如果流量较少不好观察，可以再选择一台或多台机器进行部署，具体是业务场景而定）
3. 观察一段时间后，如果不存在error日志，代码运行正常，此时可选择滚动升级
4. 选择每个滚动升级的数量，比如选择3，则每次滚动升级三台机器，直至全部升级完毕

通过上述发布流程，我们可以看到一个字: 稳 ，经过一段时间的单点部署、日志观察，我们能够及时的发现代码问题，将事故最小化

---

蓝绿发布

目前我们的服务部署了10台机器

1. 再起同等数量的机器，部署新的代码
2. 进行流量控制，逐步将流量切换到新机器上，直至100%
3. 此时，新旧机器并行存在 ，当然，流量切换期间如果出现任何异常直接将流量再切换到旧机器上，保证服务的稳定性
4. 流量切换完毕后，新旧机器同时存在，此时再验证一段时间，如果没问题的话再下掉旧机器

蓝绿发布 存在与梭哈 相似之处，都是新起同等数量的机器 ，不过在之后的流量切换上做了稳妥机制，采用逐步切流的方式，来减小可能的事故影响

最后在流量切换完毕后，不会尽快下掉旧机器，新旧机器会并行存在一段时间，避免可能因为业务场景流量小不能够及时暴露问题，等流量全切后才暴露出来

此时，由于旧机器还存在，回滚只需要切流量即可~

---

灰度发布（金丝雀发布）

目前我们的服务部署了10台机器

1. 再起小部分机器，比如一两台，形成灰度集群，部署新代码
2. 引入小部分流量到灰度集群上去进行验证
3. 验证失败，则将所有流量切回旧机器
4. 验证成功，即可进行全量发布

灰度发布过程中引入了小部分流量进行验证，能够尽快发现问题，不过灰度发布一般容量有限，只会使用少部分机器，这样的话小流量情况下有些问题是无法暴露的，也算是一种缺点~

---

结尾

本文整理了业界一些常见服务发布方式及其流程，没有原理干货，hh，敬请谅解~

参考: 有赞灰度发布与蓝绿发布实践