15-SaaS系统灰度发布滚动更新、金丝雀发布、不停机迭代一、为什么需要不停机发布传统发布方式停服务 → 替换包 → 启服务。在内部系统里勉强能用但在SaaS系统中是灾难。我们的无人售货柜SaaS平台服务全国几千台设备7×24小时营业。凌晨3点也有人在买东西你选哪个时间段停机选哪个时间段都有人用。不停机发布的本质让新版本和旧版本在一段时间内共存逐步把流量从旧版本切到新版本全程对用户透明。二、三种主流发布策略对比策略原理资源开销回滚速度适用场景滚动更新逐个替换Pod旧的下一个才上新的低不需要额外资源中需回滚替换常规版本迭代蓝绿部署两套环境并行切换流量高双倍资源快切流量即可大版本发布、需快速回滚金丝雀发布先放少量流量到新版本观察后逐步扩大中少量额外Pod快停止导流即可风险较高的版本迭代2.1 滚动更新Rolling UpdateK8s默认的更新策略。原理很直白初始状态[v1] [v1] [v1] [v1] 第一步 [v2] [v1] [v1] [v1] ← 替换第一个Pod 第二步 [v2] [v2] [v1] [v1] ← 替换第二个Pod 第三步 [v2] [v2] [v2] [v1] 第四步 [v2] [v2] [v2] [v2] ← 全部更新完成配置方式apiVersion:apps/v1kind:Deploymentmetadata:name:order-servicespec:replicas:4strategy:type:RollingUpdaterollingUpdate:maxSurge:1# 更新过程中最多超出期望副本数1个maxUnavailable:0# 更新过程中不允许有不可用Pod保证可用性template:spec:containers:-name:order-serviceimage:registry/smart-agri/order-service:1.3.0-a3f5c2e1-20260807readinessProbe:# 就绪探针只有通过检查才接流量httpGet:path:/actuator/healthport:8080initialDelaySeconds:30periodSeconds:10lifecycle:preStop:# 优雅停机收到SIGTERM后先等一会exec:command:[sh,-c,sleep 10]关键点maxUnavailable: 0确保更新过程中始终有足够的Pod服务流量readinessProbe确保新Pod真正就绪后才接收请求不是一启动就上preStop给旧Pod一个缓冲时间让网关把已建立的连接处理完再退出2.2 蓝绿部署Blue-Green Deployment两套完全相同的环境蓝色是当前线上版本绿色是新版本蓝色环境线上[v1] [v1] [v1] ← Service指向这里 绿色环境待命[v2] [v2] [v2] ← 验证通过后切过来切换瞬间完成只需改Service的selector# 当前Service指向蓝色环境apiVersion:v1kind:Servicemetadata:name:order-servicespec:selector:version:blue# 改成 green 即完成切换ports:-port:8080蓝绿部署的优点是回滚极快——把selector改回来就行。缺点是资源翻倍四个Pod变八个。适合重大版本发布比如数据库schema变更这种不能回滚的升级。2.3 金丝雀发布Canary Release名字来源于矿工带金丝雀下矿井——先放少量流量到新版本没问题再扩大。阶段1 5%流量 → v295%流量 → v1 ← 观察错误率、延迟 阶段2 25%流量 → v275%流量 → v1 阶段3 50%流量 → v250%流量 → v1 阶段4 100%流量 → v2 ← 全量发布三、K8s金丝雀发布实战3.1 基于多Deployment的流量切分# 稳定版Deployment接收大部分流量apiVersion:apps/v1kind:Deploymentmetadata:name:order-service-stablespec:replicas:9# 9个副本 90%流量template:metadata:labels:app:order-servicetrack:stablespec:containers:-name:order-serviceimage:registry/smart-agri/order-service:1.2.0---# 金丝雀Deployment接收小部分流量apiVersion:apps/v1kind:Deploymentmetadata:name:order-service-canaryspec:replicas:1# 1个副本 10%流量template:metadata:labels:app:order-servicetrack:canaryspec:containers:-name:order-serviceimage:registry/smart-agri/order-service:1.3.0-a3f5c2e1---# Service同时匹配两个Deployment的PodapiVersion:v1kind:Servicemetadata:name:order-servicespec:selector:app:order-service# 匹配 stable 和 canaryports:-port:8080通过调整两个Deployment的replicas比例来控制流量分配。9:1就是10%金丝雀流量1:1就是50%。3.2 使用Istio精确流量切分上面用副本数控制流量比例是粗粒度的依赖K8s的轮询负载均衡。如果需要精确到百分比用IstioapiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:order-servicespec:http:-route:-destination:host:order-service-stableweight:90# 90%流量到稳定版-destination:host:order-service-canaryweight:10# 10%流量到金丝雀Istio在网格层做流量切分精确到1%且不依赖Pod副本数。四、SpringCloud微服务灰度发布方案在SpringCloud微服务体系中除了K8s层面的灰度还需要在网关层做灰度路由。4.1 整体架构客户端请求 ↓ Spring Cloud Gateway网关 ↓ 根据请求头/用户ID/灰度规则路由 ├── 稳定版 user-servicev1.2.0 └── 灰度版 user-servicev1.3.04.2 Nacos元数据标记版本在application.yml中给服务实例打版本标签spring:cloud:nacos:discovery:metadata:version:1.3.0# 当前服务版本号gray-mark:canary# 标记为灰度节点4.3 网关灰度路由过滤器/** * 灰度发布网关过滤器 * 根据请求头中的 graytrue 或用户ID哈希路由到灰度节点 */ComponentpublicclassGrayReleaseGatewayFilterimplementsGlobalFilter,Ordered{AutowiredprivateNacosDiscoveryClientdiscoveryClient;OverridepublicMonoVoidfilter(ServerWebExchangeexchange,GatewayFilterChainchain){ServerHttpRequestrequestexchange.getRequest();StringgrayHeaderrequest.getHeaders().getFirst(X-Gray);// 判断是否走灰度请求头指定 或 用户ID哈希命中booleanuseGraytrue.equalsIgnoreCase(grayHeader);if(!useGray){StringuserIdrequest.getHeaders().getFirst(X-User-Id);if(userId!null){// 取用户ID哈希的末位小于2的走灰度约20%流量inthashMath.abs(userId.hashCode())%10;useGrayhash2;}}if(useGray){// 在请求头中标记灰度下游服务链路全走灰度ServerHttpRequestmutatedrequest.mutate().header(X-Gray-Version,canary).build();exchangeexchange.mutate().request(mutated).build();}returnchain.filter(exchange);}OverridepublicintgetOrder(){return-100;// 高优先级先于其他过滤器执行}}4.4 Feign灰度透传微服务之间通过Feign调用时灰度标记需要透传保证整条调用链都走灰度节点/** * Feign请求拦截器透传灰度标记 */ConfigurationpublicclassGrayFeignInterceptorimplementsRequestInterceptor{Overridepublicvoidapply(RequestTemplatetemplate){ServletRequestAttributesattributes(ServletRequestAttributes)RequestContextHolder.getRequestAttributes();if(attributes!null){HttpServletRequestrequestattributes.getRequest();StringgrayVersionrequest.getHeader(X-Gray-Version);if(grayVersion!null){template.header(X-Gray-Version,grayVersion);}}}}4.5 Nacos服务实例过滤根据灰度标记选择对应版本的服务实例/** * 基于Nacos元数据的服务实例过滤器 */publicclassGrayLoadBalancerimplementsReactorServiceInstanceLoadBalancer{privatefinalStringserviceId;privatefinalObjectProviderServiceInstanceListSuppliersupplierProvider;OverridepublicMonoResponseServiceInstancechoose(Requestrequest){// 从请求头获取灰度标记HttpHeadersheaders(HttpHeaders)request.getContext();StringgrayVersionheaders.getFirst(X-Gray-Version);returnsupplierProvider.getIfAvailable().get(request).next().map(instances-{ListServiceInstancefiltered;if(canary.equals(grayVersion)){// 灰度请求只选灰度节点filteredinstances.stream().filter(i-canary.equals(i.getMetadata().get(gray-mark))).collect(Collectors.toList());if(filtered.isEmpty()){filteredinstances;// 没有灰度节点时降级到稳定版}}else{// 正常请求只选稳定版节点filteredinstances.stream().filter(i-!canary.equals(i.getMetadata().get(gray-mark))).collect(Collectors.toList());if(filtered.isEmpty()){filteredinstances;}}ServiceInstancechosenfiltered.get(ThreadLocalRandom.current().nextInt(filtered.size()));returnnewDefaultResponse(chosen);});}}五、无人售货柜SaaS不停机迭代实战5.1 发布流程1. CI/CD构建新版本镜像 → 推送仓库 2. K8s金丝雀Deployment部署1个新版本Pod 3. 网关配置5%流量到灰度节点 4. 监控面板观察30分钟错误率、响应延迟、业务指标 5. 指标正常 → 逐步扩大到25% → 50% → 100% 6. 全量后下线旧版本Pod清理灰度标记5.2 监控指标灰度期间重点监控HTTP 5xx错误率新版本有没有引入新bugP99响应延迟新版本性能有没有退化业务指标订单创建成功率、支付成功率——这些直接关系到钱日志告警ERROR级别日志是否突增# Prometheus告警规则灰度期间错误率超过阈值自动告警groups:-name:canary-alertrules:-alert:CanaryHighErrorRateexpr:|sum(rate(http_server_requests_seconds_count{apporder-service, versioncanary, status~5..}[5m])) / sum(rate(http_server_requests_seconds_count{apporder-service, versioncanary}[5m])) 0.01for:2mlabels:severity:criticalannotations:summary:金丝雀版本错误率超过1%description:order-service灰度版本5xx错误率超标请检查或回滚5.3 自动回滚#!/bin/bash# 金丝雀发布自动回滚脚本CANARY_PODS$(kubectl get pods-ltrackcanary-ojsonpath{.items[*].metadata.name})ERROR_RATE$(curl-shttp://prometheus:9090/api/v1/query?querycanary_error_rate|jq.data.result[0].value[1])if(($(echo $ERROR_RATE0.05|bc-l)));thenecho错误率${ERROR_RATE}超过5%执行自动回滚kubectl scale deployment order-service-canary--replicas0# 发送告警通知curl-XPOSThttps://qyapi.weixin.qq.com/cgi-bin/webhook/send?key$WEBHOOK_KEY\-HContent-Type: application/json\-d{\msgtype\:\text\,\text\:{\content\:\⚠️ 金丝雀发布自动回滚order-service错误率${ERROR_RATE}\}}fi六、小结不停机发布的核心思路新旧共存、逐步切流、随时回滚。K8s滚动更新适合常规迭代金丝雀发布适合风险较高的版本蓝绿部署适合重大变更。SpringCloud微服务通过网关路由Nacos元数据Feign透传实现服务链路级别的灰度。监控和自动回滚是安全网——没有监控的灰度发布就是蒙眼狂奔。