软件|如何实现微服务的规模部署与批量发布？( 四 )
“金丝雀测试”的覆盖范围很小 ， 所针对的用户群体可以限制在很小的可控范围之内 。 就像笔者目前所负责的在线金融业务 ， 每当一个较大的功能上线时 ， 一般都会先让部门内部员工承担“金丝雀”的角色 ， 再将范围扩大到公司员工 ， 然后基于特定规则（地区、机型、年龄等）挑选一批用户 。
“金丝雀测试”无误后 ， 就可以进行全量滚动发布了 。
小贴士：
矿井工人面临的一大风险就是井下的瓦斯爆炸 ， 后来人们发现 ， 金丝雀对瓦斯气体非常敏感 ， 只要空气中存在极其微量的瓦斯气体 ， 金丝雀就会停止歌唱或死亡 。 因此 ， 在采矿设备不发达的古代 ， 矿井工人每次下井都会带上一只金丝雀 ， 并根据金丝雀的表现来判定是否有瓦斯 ， 以便在危险来临前及时撤离 。
基于版本号的灰度发布
对服务的升级 ， 会遇到两种情况 。 第一种情况是接口不变 ， 只是代码本身进行完善 。 这种情况处理起来比较简单 ， 因为提供给使用者的接口、方法都没有变 ， 只是内部的服务实现有变化 。 在这种情况下 ， 采用上述灰度发布的方式验证后全部发布即可 。 第二种情况是需要修改原有的接口 ， 如果只是在接口中增加新方法 ， 可以参考第一种情况处理 。 复杂的是接口方法的参数列表被修改了 ， 这时就需要有相应的手段来区分新旧接口方法 ， 比较通用的办法是通过增加服务接口的版本号来解决 ， 使用老方法的系统继续调用原来版本的服务 ， 需要使用新方法的系统则使用新版本的服务 。 这意味着 ， 在服务框架中 ， 必须通过“服务接口 + 版本号”的方式来唯一区分服务（在服务多租户的模式下 ， 还需要加入分组 group） 。 基于版本号的灰度发布升级如图 4.24 所示 。
在图 4.24 中 ， C1 代表服务调用方（消费者 ， Consumer） ， P1 代表服务提供方（提供者 ， Provider） ， V1、V2 代表版本号 。 总体流程是 ， 找一个访问低谷 ， 先将一部分服务提供方升级为新版本 ， 接着将所有服务调用方升级成新版本 ， 最后将剩余的服务提供方升级成新版本 。 这个过程涉及流量的各种调整 ， 具体可以参考图 4.24 中的各个步骤 。
本文插图
图 4.24 基于版本号的灰度发布升级
推荐阅读
- 模型|REVIT技巧！如何创建能量模型，实现能量优化
- 技术编程|如何利用数据库进行世界史研究
- 区块链|欧科云链任煜男做客西安广电电台节目，解读区块链如何赋能实体产业
- 苹果笔记本|如何让macbook合上时工作？解决苹果电脑合盖自动休眠问题-macw
- |如何分析“会员数据”，强化门店的竞争力？
- 数据|翼方健数解码隐私安全计算 实现数据“可用不可见”
- 拍照摄影|如何拍出赞爆朋友圈的自拍照？网红小姐姐公开拍照神器
- IOS系统|苹果免签封装如何实现？苹果免签封装会不会掉签？
- 帧数|帧数提升70% NV黑科技DLSS如何开启
- 拍照摄影|即将进入大学的新生想入手一台相机，该如何选？