HTTPRoute 与 Echo 不是原生组合，权重分流应由网关层（如 Nginx Ingress、Envoy Gateway）实现，Echo 仅负责业务处理；需通过 Ingress 注解或 HTTPRoute backendRefs 配置权重，并确保健康检查正常。
HTTPRoute + Echo 不是原生组合，得换思路
Echo 框架本身不支持 HTTPRoute，它是纯 Go Web 框架，运行在应用层，和 Kubernetes 的 HTTPRoute（Gateway API）属于不同抽象层级。想用“权重比例 AB 测试”，不能指望 Echo 自己解析 Gateway API 对象——它压根不感知集群、CRD 或网关控制面。
真正能做权重分流的，是部署在 Echo 前面的网关：比如 Nginx Ingress Controller、Envoy Gateway、Cilium Gateway，或者 LVS+Keepalived+Nginx 分层架构里的 Nginx 层。Echo 只负责把 /api/v1/user 这类路径处理好，流量怎么分到它身上，得靠上层网关决定。
Nginx Ingress Controller 的 weight 注解最常用但有坑
如果你用的是 Nginx Ingress Controller，最直接的方式是在 Ingress 资源里用 nginx.ingress.kubernetes.io/canary-weight 注解，配合两个 Service（分别指向 v1 和 v2 版本的 Echo 应用）：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: echo-app
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20"
nginx.ingress.kubernetes.io/canary-by-header: "ignored"
spec:
ingressClassName: nginx
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: echo-v1-svc
port:
number: 80
注意这个配置必须配对使用：echo-v1-svc 是主服务，echo-v2-svc 需要另起一个带 canary: true 标签的 Ingress，且不能写 canary-by-header-value 这类冲突注解，否则权重失效。
- 权重只在同 path、同 host 下生效，跨 path 不参与计算
-
canary-weight: "20"表示 20% 流量打到 canary Ingress 关联的服务，不是 20% 打到 annotation 所在的这个 Ingress - 该注解依赖 Nginx Ingress Controller v1.0+，旧版本用
nginx.ingress.kubernetes.io/canary-weight会静默忽略
用 Gateway API + Envoy Gateway 更干净，但 Echo 要暴露健康端点
如果已迁移到 Gateway API，推荐用 HTTPRoute 的 backendRefs 加 weight 字段。Echo 应用本身不需要改代码，但必须确保 readiness probe 正常响应，否则 Envoy 会把它从后端池剔除：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: echo-traffic
spec:
parentRefs:
- name: my-gateway
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: echo-v1-svc
port: 80
weight: 80
- name: echo-v2-svc
port: 80
weight: 20
这里的关键约束是：
-
echo-v1-svc和echo-v2-svc必须在同一个命名空间，或通过ReferenceGrant显式授权跨命名空间引用 - Envoy Gateway 要求后端 Pod 的 readiness probe 返回 200，建议 Echo 里加个
GET /healthz路由并返回200 OK - 权重总和不必等于 100，但实际分流比例按相对值算；
weight: 8和weight: 2等效于 80/20
自己在 Echo 里做权重路由？可以但不推荐
理论上你能在 Echo 的中间件里读取请求头或 Cookie，再用随机数决定转发到哪个下游服务（比如另一个 Echo 实例或 gRPC 后端）。但这种做法绕过了所有网关的可观测性、熔断、重试机制，还容易引发循环代理或 header 丢失。
真要这么做，至少注意三点：
- 不要用
math/rand，要用crypto/rand或带 seed 的伪随机，避免多实例间分流不一致 - 转发时显式透传原始
Host、X-Forwarded-For，否则日志和限流规则全乱 - 务必设置超时和重试逻辑，否则一个下游挂掉会导致整个请求失败
实际项目里，95% 的 AB 测试需求都应该交给网关层解决。Echo 的职责是把业务逻辑跑稳，而不是操心流量怎么分——那不是它的战场。
