/tags/canary-release/ Recent content in canary-release on Hugo -- gohugo.io en Tue, 14 Apr 2026 10:00:00 +0800 /posts/spring-cloud-gateway-canary-release/ Tue, 14 Apr 2026 10:00:00 +0800 /posts/spring-cloud-gateway-canary-release/ 本文基于的项目：https://github.com/meirongdev/shop（私有）。相关实现主要在 services/api-gateway。 从一个具体问题开始 buyer-bff 要升级一版，改动涉及订单接口的返回结构。上线前我们想让两三个内部测试账号先跑一段时间，其他人继续走旧版。出问题时能立刻回切，整个过程不要重启任何服务。 前提：环境里没有 Istio、没有 Linkerd，也没有 Argo Rollouts。Kubernetes 只有原生的 Service 和 Ingress。 在这种约束下，灰度发布能放在哪一层？ Kubernetes Service 权重：原生 Service 不支持按权重或按用户分流，它只是 round-robin。 应用内开关：让每个服务各自根据用户属性判断走新旧逻辑。问题是"谁是灰度用户"的判断会散落到每个服务里重复实现，也没法在入口做统一观测。代码层面的 feature flag 不是不能用，它和 Gateway 路由解的是不同层次的问题——本文末尾会讨论两者如何互补。 Service Mesh：能干净地做这件事，但引入一整套 sidecar/control plane，对这个项目太重。 API Gateway：请求进入系统的第一跳，比较自然地成为流量决策点。只要 Gateway 能按请求属性选择 upstream，就够了。 这个项目选了第四条。下面把每一个设计选择拆开讲。 Spring Cloud Gateway 在这里担任什么角色 Shop Platform 的 api-gateway 是 Spring Cloud Gateway Server MVC（不是 WebFlux 那套），运行在虚拟线程上。它在系统里承担的事情是常规的那几件： 路径路由（/api/buyer/** → buyer-bff，/auth/** → auth-server……） 鉴权（解析 JWT、注入 X-Buyer-Id 等可信 Header） 限流（基于 Redis 的令牌桶） CORS、OpenAPI 聚合 按用户做灰度路由 ← 本文主题 灰度在这里不是外挂的新组件，而是复用 Gateway 的路由匹配能力加一个自定义谓词。