没做过灰度发布，但项目中存在这部分代码。最近看到一些概念，就做一番整理，也方便以后回头看。
两种灰度发布的方式
- 分批部署
- 按业务规则
分批部署灰度发布
分批部署的方式主要用于降低新版本服务对业务产生影响的风险。一旦发现重大问题，直接回退。如果发现得及时，可保证只影响部分客户。
服务部署期间可通过观测服务上报的 metrics 的方式以发现问题。
为了最小化对客户服务的影响范围，对于具有很多实例的系统，建议通过指数增量的方式来分组升级。比如，系统有15台实例（可能是物理机或是容器），按 1、2、4、8 进行分组，进行逐步升级。
为什么推荐指数的方式分批升级呢？这是因为，一来在实例数过多时，批次也不会太多，比如有 1000 多个实例，那么也就需要分 10 个组（2^10>1000）；二来对业务的影响范围最初会很小，比如 1000 个实例，最初部署一个时仅影响 1/1000 的业务，但如果按均分 10 组做灰度时，一开始就会影响 1/10 的业务，当总业务量为千万级别时，影响不可小觑。
通过业务规则做灰度
通过业务规则做灰度一般会让新旧两种版本共存一段时间做业务分流，来观察新版本是否有bug，按不同的规则进行灰度也可以用在做版本升级的场景。
业务规则可以有很多种：
- 按地域
- 按比例
- 按白名单
- 按某业务字段
- 按设备
- ……
用哈希算法做分发时
求哈希可用的算法非常多，比如 md5，crc32，sha1等等，挑选算法时需要考虑以下两个规则：
- 对 CPU 的使用越低越好
- 分布是否均匀
业界使用较多的算法是murmurhash（Redis中默认哈希就是用它）。它的性能比 md5、sha1 有三倍以上性能的提升；并且分布相当均匀。感兴趣的可以自己测试一下。
网友评论