git灰度发布版本_Spring Cloud Gray 3.0 灰度解决方案

最新推荐文章于 2024-09-04 12:34:33 发布

夢旅十方

最新推荐文章于 2024-09-04 12:34:33 发布

阅读量450

点赞数 2

文章标签： git灰度发布版本

本文链接：https://blog.csdn.net/weixin_33870147/article/details/112269724

版权

本文详细介绍了Spring Cloud Gray，一个灰度发布的解决方案，支持实例、版本和服务级别的灰度策略，提供灵活的灰度粒度控制，降低线上发版风险。通过实例灰度、版本灰度和全链路灰度等策略，实现线上测试、放量和多版本控制，减少对正常用户的影响。此外，还介绍了Mock支持和灰度策略模型，以及Long Polling的实时增量信息同步，以提升灰度发布的效率和准确性。

摘要由CSDN通过智能技术生成

发版的故事

做为一位技术人员，是否经历过为了不影响线上环境的稳定，不影响线上用户的正常使用，需求上线、功能上线的时间都安排在晚上或者凌晨，发版测试过后精疲力尽，甚至可能在线上测试过程中发现新的问题，然后吭哧吭哧埋头找原因修bug，再发版测试，或者无法快速找到原因修复进行回滚，第二天晚上继续上线。这还不是最惨的，最惨的是晚上辛苦上线测试验证通过后，第二天用户功能出现问题，影响用户正常使用、生产数据异常，然后着急忙慌的回滚、修复数据，最后再背个故障

勊勊业业，勤勤恳恳的经过一段时间，被提拔为团队领导，晚上上线发布时仍是谨小慎微，出现问题时仍拖着疲惫不堪的身心安排协调解决问题，确保顺利上线，尤其是晚上发布出现问题时，沟通成本会增强，注意力会下降，这些都会使得发布风险大增；看着团队成员频繁晚上发布出现的满眼血丝、黑眼圈，同时还得为发布质量和风险思考解决方案。

发版的风险

由于发版引起的故障或损失占比有多高？

这个数据没有去仔细分析过，但是由于发版引发故障的比例确实不低，所以有的公司会规定，发版第二天后线上出现问题，如果在规定的时间段不能修复问题，就立即回滚。同时为了避免上述的情况，会采取一些方法减少发版造成的故障和损失，例如在发版时会进行灰度或者蓝绿。

灰度方案

上面关于上线发布的案例大部分人都经历过，或者正在经历，或者还在经历，要跳出这个痛苦的怪圈，需要使用一些方案或者手段，比如灰度。

Spring Cloud Gray是一个灰度发布解决方案，提供server管控端，拥有web界面，可以界面上编辑灰度策略实时控制请求路由；提供多种灰度粒度和灵活的灰度策略，可以根据需要的灰度场景进行组合，支持Http全链路灰度。

支持场景

线上测试先发布1台实例，用于测试验证，指定测试的流量进入这台实例，其它流量依然进入其它正常的实例。发布成本小，快速测试，不会影响正常用户使用，如果测试不通过，只需回滚这一台实例，用户无感知。
放量通过金丝雀测试后，可以逐渐放量到新发布的服务器上；放一定比例的流量到灰度服务器上，观察一段时间没异常，可调整加大灰度的流量，将发布产生的风险保持在可控范围内。
多版本控制允许线上存在多个版本，根据不同的灰度策略将不同的请求或者用户路由到不同版本的服务实例上。
蓝绿发布蓝绿发布是指线上存在两个版本的代码运行在服务器，请求访问的时候只能访问蓝色版本或者绿版本，可以快速的切换请求流向。

灰度策略

在上一个大版本中，灰度策略是灰度实例的一个属性，这能实现了灰度请求的判定和路由，可是却限定了灰度策略的能力，在新的一版中，将灰度策略从灰度实例中抽取出来，使灰度策略不仅仅只支持实例实例，让它的能力能够去解决更多的问题和场景。