这是一个创建于 451 天前的主题,其中的信息可能已经有所发展或是发生改变。
或者蓝绿发布
有没有大佬能系统性的讲一下。
- 服务的 provider 、consumer 里的标签和条件模型该怎么构造?
- 怎么做新版本(灰度版本)的代码稳定性的监控?
- 业务稳定后,旧版本的实例该如何管理?
我目前比较简单的想法是:
- 预留部分资源用于发布灰度实例,发布灰度实例带上 dubbo.tag=gay 灰度标签。
- 开发测试时通过请求 header 中携带灰度标签,访问到灰度实例进行线上回归测试。
- 需要按权重灰度用户的场景,就是在 apisix 网关层或者 dubbo 过滤器中根据 userId 去查询 userId 的灰度标签。
- 这边就需要过滤新老实例的稳定性了, 通用的做法应该就是对比双方的请求失败率,报错数统计之类了,但是感觉基于 elk 和 sls 都很繁琐。这些有没有对应的 dubbo 生态的组件能够做到呢?
- 线上灰度通过后,下线灰度实例,然后走滚动发布的流程。