灰度发布功能需求范围说明书
项⽬概述
项⽬背景
随着公司业务的快速发展,微服务架构下的应⽤更新迭代频繁。为了降低新版本发布⻛险,提⾼系统稳定性,需要
实现灰度发布功能,允许特定⽤户或特定标记的请求访问新版本服务,逐步验证新版本功能。
项⽬⽬标
基于 Spring Cloud 微服务架构,实现全链路灰度发布功能,⽀持:
- 基于⽤户、请求标记的精准灰度路由
- ⽹关到后端服务、服务间调⽤的全链路灰度⼀致性
- 灰度规则动态配置和管理
- 灰度流量监控和统计
⽅案
在 KubeSphere 上部署你的 Spring Cloud 服务,应用保持 Spring Cloud 技术栈,但流量治理(如灰度发布)则由底层的 Istio 服务网格来负责。
协同工作原理
下面的流程图清晰地展示了 Spring Cloud 应用如何在 KubeSphere 上通过 Istio 实现灰度发布:
KubeSphere 灰度发布策略
蓝绿发布
金丝雀发布
流量镜像
Spring Cloud 应用
部署至 K8s
(保持原有框架)
通过 KubeSphere 治理
方案A:直接部署为工作负载
方案B:使用 Spring Cloud 扩展
由 Istio 服务网格接管流量
由 KubeSphere Spring Cloud 扩展管理
利用 Istio 实现
蓝绿/金丝雀/镜像发布
完成灰度发布
关键实施步骤与检查点
基于上述架构,你可以参照以下路径进行操作:
阶段 核心步骤 关键检查点与说明
- 环境准备 启用 KubeSphere 服务网格 (Istio) 和 Spring Cloud 扩展组件。 在管理后台确认组件状态为"已启用"。这是所有功能的基础。
- 应用部署 方案A(直接):将应用作为普通工作负载(Deployment)部署。 方案B(推荐):通过 Spring Cloud > 微服务菜单创建,便于统一管理。 确保Pod内容器端口协议(如HTTP)设置正确,这是Istio进行流量识别和管理的前提。
- 服务注册与发现 应用需集成Nacos客户端,并配置其服务端地址。Spring Cloud扩展会提供Nacos服务。 应用能正常注册到KubeSphere提供的Nacos,这是微服务间通信的保障。
- 注入Sidecar 为应用的命名空间或工作负载启用Istio Sidecar自动注入。 应用Pod内应有两个容器(业务容器 + istio-proxy),表明已接入服务网格。
- 配置灰度发布 1. 部署新版本(如v2)工作负载。 2. 在服务网格或灰度发布菜单中,选择策略并配置流量规则。 KubeSphere支持蓝绿发布、金丝雀发布和流量镜像三种主流策略。
策略选择与后续建议
你可以参考以下建议选择灰度策略:
· 验证新功能可用性:蓝绿发布更合适,切换迅速。
· 观察新版本稳定性:金丝雀发布(逐步放量)或流量镜像(无风险复制流量)是更谨慎的选择。
官方文档
https://docs.kubesphere.com.cn/v4.2.1/11-use-extensions/06-service-mesh
流量控制权的转移
通过对比三种部署方式来理解:
场景 服务发现 (找谁) 流量路径 (怎么去) 谁控制流量?

详细解释:流量如何被"劫持"
在启用了Istio服务网格的KubeSphere环境中,会发生以下关键变化:
- Sidecar注入:您的Spring Cloud应用Pod里,除了业务容器,会被自动注入一个istio-proxy容器。这个代理容器会接管Pod的所有出入站网络流量。
- 流量拦截:您的Spring Boot应用代码里,Feign或RestTemplate发出的请求,目的地虽然是service-a,但出网流量首先被istio-proxy拦截。
- 网格内路由:istio-proxy根据从Istio控制平面下发的规则(您在KubeSphere界面上配置的灰度规则),决定将流量转发到service-a的v1版本Pod,还是v2版本Pod。这个过程完全绕过了K8s Service的负载均衡。
- 服务发现的作用:此时,Nacos的作用更多是作为一个服务注册中心,保证应用启动和健康检查。在严格模式下,网格内的服务通信甚至可以不依赖Nacos的发现结果,而是直接使用Istio内置的服务发现。
对您的影响与建议
理解了这一点,您就能明白:
· 您无需修改业务代码:您的Spring Cloud服务仍然像往常一样从Nacos查询和注册服务。
· 真正实现灰度的是Istio:您在KubeSphere控制台上配置的"金丝雀发布"规则,会被转换为Istio的VirtualService和DestinationRule,由istio-proxy执行,从而做到精准的流量切分、故障注入等。
· Nacos部署在哪影响不大:无论是K8s内部还是外部Nacos,在服务网格模式下,对流量控制的影响很小。选择的关键在于运维便利性、网络连通性和性能:
· K8s内部Nacos:部署管理方便,与K8s生态结合好,但需注意其资源消耗和高可用配置。
· 外部独立Nacos:性能可能更稳定,资源独立,但需要确保K8s集群内Pod能稳定访问到它。
结论与行动路线
所以,回到您最初的目标------在KubeSphere上为Spring Cloud服务实现灰度发布,正确路径是启用并依赖其服务网格(Istio)能力,而不是纠结于让Spring Cloud或Nacos自己来实现复杂的流量拆分。
建议的操作步骤:
- 在KubeSphere中为您应用的命名空间 启用Istio Sidecar自动注入。
- 像往常一样部署您的Spring Cloud应用(连接现有的Nacos)。
- 在KubeSphere的服务网格或灰度发布功能页面,为您服务的两个版本(如v1和v2)创建灰度发布任务,并配置流量比例。
完成以上步骤后,您就能通过KubeSphere的界面直观地管理和监控灰度发布过程,而背后的复杂流量控制则由Istio透明地完成。