导读:
哈喽,小伙伴们,我是黑马苗老师。
今天我们来聊一个有趣的话题,微服务项目如何丝滑升级。
没错,现在做技术都讲究丝滑,好用、易扩展、易维护、低成本...这都是丝滑的表现,微服务项目在升级时如果采用简单粗暴的流程:停机--》升级--》启用 势必会影响用户的体验,如果我们做到升级过程用户无感知,这是不是很丝滑?
今天我们聊的灰度发布就是微服务项目升级的过程实现用户无感知,并且整个实现过程无需单独引入第三方中间件,且开发过程简单。
本文案例选自大型项目云岚到家。
概念
灰度发布(也称为灰度升级、金丝雀发布或渐进式部署)是一种在软件开发和部署中使用的策略,它允许您逐步将新功能版本推向用户群。这种方法有助于降低风险,因为它可以确保新版本的稳定性和性能在完全推出之前得到验证。
灰度发布主要是运维人员的工作内容,但是也需要软件开发人员熟知并配合技术支持。
灰度发布的常见步骤包括:
小范围测试:通过请求入口控制,首先将新版本推送给一小部分用户,通常是从内部员工开始,然后是外部测试人员。
监控反馈与性能:密切监控这些用户的反馈以及新版本的性能指标,如错误率、延迟等,整个灰度过程新旧版本是并存的。
逐步扩大范围:如果一切正常,则逐渐增加接收新版本的用户数量,通过更改入口控制将更多的流放行到新版本程序。
全面发布:当所有测试都成功并通过足够的用户验证后,将新版本全面推向所有用户。
谈到灰度发布就不得不说蓝绿发布。
蓝绿发布(Blue-Green Deployment)是一种软件部署策略,它的主要目标是在部署新版本时尽量减少服务中断时间,并提供一个简单且快速的回滚机制。
核心概念:
-
两套相同的生产环境:
蓝绿发布涉及两个完全相同的应用环境,通常被称为“蓝色”环境和“绿色”环境。其中一个环境处于活动状态(提供服务),另一个环境则用于部署新版本。
-
活动与非活动状态:
在任何时候,只有一个环境是活动的,另一个是非活动的。活动环境接收所有用户请求,而非活动环境用于部署和测试新版本。
工作流程
-
初始状态:假设“绿色”环境是活动环境,提供当前版本的服务,而“蓝色”环境是非活动状态,用于部署新版本。
-
部署新版本:将新版本部署到“蓝色”环境中。在此阶段,“绿色”环境继续为用户提供服务。
-
测试新版本:在“蓝色”环境中进行必要的测试,确保新版本稳定可靠。
-
切换负载:如果测试成功,可以通过更改负载均衡器的设置,将所有用户流量切换到“蓝色”环境。这样,“蓝色”环境变成了新的活动环境,而“绿色”环境变为空闲状态。
-
回滚机制:如果新版本有问题,可以立即将流量切换回“绿色”环境,恢复到之前的状态,从而实现快速回滚。
各位,清楚蓝绿发布和灰度发布的主要区别了吗?
蓝绿发布 (Blue/Green Deployment)
并行环境:蓝绿发布涉及到两个并行的生产环境,通常一个是当前正在使用的“蓝色”环境,另一个是准备好的“绿色”环境用于部署新版本。
切换机制:一旦新版本在绿色环境中部署完毕并通过测试,流量会被切换到新的绿色环境,而旧的蓝色环境则被标记为备用或被废弃。
回滚简单:如果新版本有问题,可以立即切换回旧版本,因为旧版本的环境一直保持着。
适用场景:适用于对稳定性要求极高、需要快速回滚的场景
灰度发布 (Canary Release / Gradual Rollout)
逐步部署:灰度发布指的是向一小部分用户推出新版本,通常是通过版本间的流量划分实现。
监控反馈:通过观察这部分用户的使用情况和反馈来决定是否继续推广新版本或是回滚。
灵活性高:可以根据实际情况调整新版本的推广速度,甚至可以选择暂停推广。
适用场景:适用于需要逐步验证市场反应、用户体验等场景。
总的来说,蓝绿发布更注重系统的稳定性和快速回滚的能力,而灰度发布则更关注于对新版本的市场反馈和逐步推广的风险管理。选择哪一种发布策略取决于业务的需求、技术条件以及对新版本上线的自信程度。
好啦,下面开始今天的主角:灰度发布。
灰度发布流程
在实际操作中,灰度发布需要一些技术工具的支持,例如K8S、配置管理、流量控制和实时监控系统等,此外,还需要一个良好的回滚计划,以便在出现问题时能够迅速恢复到旧版本。
今天我们用微服务项目的标配工具: 网关(Spring Cloud Gateway)加 配置与服务中心(阿里 Nacos )来实现灰度发布,整个实现过程无须单独引入第三方工具。