Istio服务网格的应用程序主流发布方案
1.Istio服务网格的应用程序主流发布方案
1.1.蓝绿发布
Web应用程序在逻辑上分为A、B两组,在升级过程中,首先将B组从负载均衡器中移除,然后在B组的Web服务器中进行V2版本的升级,A组V1版本依旧正常提供应用服务,当B组完成应用升级后,将B组重新挂载到负载均衡器中,然后将V1版本的A组从负载均衡器中移除,这种发布模式被称为蓝绿发布。
蓝绿发布的特点:
- 策略简单,过程通过脚本来实现,只需要从负载均衡中移除相应的服务器。
- 升级/回滚的速度快,当B组升级完提供线上服务时,A组虽然被负载均衡器移除了,但是也不会立刻进行版本升级,而是当一段时间后,线上程序稳定了再进行版本升级,当线上程序异常了,也可以直接将B组移除,将A组重新添加,不管是升级还是回滚的速度都非常快,只需要调整负载均衡的配置即可。
- 用户无感知、平滑过渡,整个过程中用户是没有感知的。
蓝绿发布的缺点:
- 需要正常业务程序提供流量支撑的两倍及以上的服务器资源,较为浪费资源。
- 有问题影响的范围比较广,例如新版本的问题发现的比较晚,AB两组的服务器全部升级版本了,涉及回滚就会比较麻烦。
1.2.滚动发布
Kubernetes集群的Pod程序版本升级的默认方式就是滚动发布,先运行一个新版本的Pod,健康检查机制通过后才会将旧版本的Pod删除,不断的执行这个过程,直到所有的Pod全部升级成新的版本为止。
**滚动发布的特点:**用户无感知、平滑过渡,新旧版本都存在于集群中,用户也不会感觉到程序进行了版本升级。
滚动发布的缺点:
- 部署的周期比较长,当健康检查通过后才会进行下一个Pod的升级。
- 不易回滚,回滚的方式也是一个一个Pod进行回滚,周期长。
- 影响的范围很大。
1.3.灰度发布
灰度发布又称为金丝雀发布,灰度发布是通过只升级集群中的一部分WEB的版本,然后进行流量访问控制,将一批用户的请求转发到新版本的应用程序上,另外一批用户继续使用旧版本的应用程序,如果用户对新版本的程序没有异常问题的发生,那么会逐步扩大范围,最终将所有的WEB进行版本升级。
灰度发布的特点:
- 影响范围略低,仅是某一批用户开始使用新的版本,即使存在问题也只是少数人。
- 保证整体系统的稳定性,可能只能20%的用户在使用新版本,剩下80%依旧是旧版本的程序。
- 用户无感知、平滑过渡。
**灰度发布的缺点:**灰度发布设计相对复杂,对自动化的要求比较高,要精确控制。
1.4.A/B测试发布
A/B测试发布是灰度发布的另一种模式,主要是针对不同批次用户使用不同版本后的信息采样,对收到的反馈数据进行对比,也就相当于全部上线新版本之前,先要看看用户的使用反馈,该加功能的加功能,改修复的修复,当用户都比较满意时,再进行版本是否要升级。
A/B测试的精确性更高,上线后的故障率也会相对降低,维护成本较高。
文章来源: jiangxl.blog.csdn.net,作者:Jiangxl~,版权归原作者所有,如需转载,请联系作者。
原文链接:jiangxl.blog.csdn.net/article/details/125118721
- 点赞
- 收藏
- 关注作者
评论(0)