灰度发布核心模式：三种路由策略实战
灰度发布的核心，说白了就是怎么把用户流量精准地引到新版上去。我这些年折腾过不少项目，踩过坑也填过坑，发现路由策略选对了，灰度就成功了一半。下面咱们逐个拆解。
基于权重的灰度路由
这是最直白的方式。你给新版本分配一个流量比例，比如 10%，剩下的 90% 还是走老版本。工具自动按权重转发请求。
我个人习惯在 Kubernetes 上用 Service Mesh 来做，比如 Istio 的 VirtualService。配置起来很直观：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my-svc
spec:
hosts:
- my-svc
http:
- route:
- destination:
host: my-svc
subset: v2
weight: 10
- destination:
host: my-svc
subset: v1
weight: 90注意，权重总和必须等于 100。我这里写 10+90，你要是写 5+95 也完全没问题。
避坑指南：我曾经在一个高并发系统里只给了新版本 1% 的权重，结果因为新版本的数据库连接池配置少了一半，1% 的流量反而把那几个 Pod 打崩了。权重小不代表压力小，一定要做容量预估。
基于权重的最大优势是简单易控，缺点是什么？用户可能一会走新版本，一会走老版本，体验不一致。适合内部测试或对一致性要求不高的场景。
基于用户属性的灰度路由
这种模式更精细。你把用户分成不同组，比如按用户ID、会员等级、设备类型、登录状态等等，然后只让特定组的用户走新版本。
举个例子，我只想给付费VIP用户先尝鲜。那就在网关层根据请求头里的用户等级做路由。用 Nginx 的 lua 脚本或者 API 网关的插件都能实现。
我比较推荐在 Istio 里用请求头匹配：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my-svc
spec:
hosts:
- my-svc
http:
- match:
- headers:
user-tier:
exact: platinum
route:
- destination:
host: my-svc
subset: v2
- route:
- destination:
host: my-svc
subset: v1我的经验：基于用户属性时，别忘了考虑粘性会话。比如同一个用户多次请求，如果没做 session stickiness，可能会在灰度组和对照组间跳来跳去，导致 UI 或接口行为异常。我一般配合 Cookie 或 JWT 中的用户标识做一致性哈希。
这种模式适合做功能验证：先让内部员工用，再让白名单用户用，最后全量开放。可控制性好，但配置复杂度高，需要维护用户分组规则。
基于地域/环境的灰度路由
按照机房、Region、可用区，或者按 staging/production 环境来路由。本质上是把新版先部署到一小部分基础设施上，看看运行情况，再逐步扩大部署范围。
我记得有个项目上线前要先在美西区域跑一周，没问题再推到美东。做法很简单：在 Ingress 层按来源 IP 的地理位置分到不同后端 Service。也可以用 DNS 做地域解析，或者用全局负载均衡器。
| 策略 | 实现方式 | 典型工具 |
|---|---|---|
| 按地理位置 | Geo DNS / Anycast | AWS Route53, Cloudflare |
| 按可用区 | K8s topology key / Service Mesh | Istio Locality Load Balancing |
| 按环境 | Ingress 路由规则 + 独立 Service | Nginx Ingress, Traefik |
核心思考：地域路由天然隔离了故障影响范围。我曾经见过一个团队把新版本直接部署到全集群，结果一次配置错误导致所有 region 的数据库连接池爆掉。如果当时先用地域灰度，只影响一个 region，回滚会快得多。
三种模式的对比与选择
下面这张 SVG 图能帮你快速把握三种模式的适用场景和核心关系：
三种模式在实际项目中经常混用。比如你同时做基于权重的流量分配，又在权重组内部按用户属性做二次过滤。我个人更倾向这样搭配：先用地域环境做灰度部署，确保基础设施没问题，再用基于用户属性让内部员工先验证功能，最后按权重逐步放量给所有用户。
补充一点：不管选哪种模式，监控指标必须跟上。我通常会在灰度开始前就配置好错误率、延迟、业务转化率三个维度的仪表盘，一旦指标超过阈值就自动回滚。别等用户投诉了才发现问题。嗯，这里要注意，灰度路由引擎本身也要做高可用设计，不能因为路由配置错误导致全站不可用。
以上就是灰度发布的三种核心路由模式。理解它们各自的适用场景和局限，你就能根据业务需求灵活组合了。