Gin本身不支持权重路由，因其是HTTP路由框架而非负载均衡器；权重分发需在网关层手动实现，推荐加权随机算法选实例，避免浮点精度误差与状态维护问题。
为什么 Gin 本身不支持权重路由
Gin 是 HTTP 路由框架，不是负载均衡器；gin.Engine 没有内置的 upstream 或 weighted round-robin 机制。你不能像 Nginx 那样写 server a:8080 weight=3 让 Gin 自动按比例转发请求。所有“权重分发”必须由你手动实现：解析标识 → 查权重配置 → 选目标实例 → 发起下游调用。
权重决策必须放在网关层，不能靠服务实例自己判断
灰度流量控制的关键是「路由决策前置」——不能等请求进到 v2 服务里再决定“要不要走 v2”，那已经晚了。Gin 网关中间件要负责：提取灰度标识（如 X-Release-Stage）、查当前各版本权重、按算法选目标地址、透传上下文并发起 http.Client 请求。
- 权重配置建议存在内存（如
sync.Map）或 etcd 中，避免每次读文件或 DB - 权重值应为正整数，且只看相对大小：比如
v1:95, v2:5和v1:19, v2:1效果一致，但后者更易计算、误差更小 - 别用浮点数做权重，Go 的
rand.Float64()+ 权重累加容易因精度导致分布偏差 - 实际选实例时推荐用「加权随机」而非「加权轮询」：轮询需维护状态（当前累计权重、上次选中索引），在并发请求下难保证线程安全；随机则无状态、易实现
加权随机选实例的 Go 实现要点
假设你有两个后端：v1.example.com:8080（权重 19）、v2.example.com:8080（权重 1），总权重为 20。你生成一个 [0, 20) 的随机整数，落在 [0,19) 就选 v1，[19,20) 就选 v2。
func selectBackend(weights map[string]int) string {
total := 0
for _, w := range weights {
total += w
}
r := rand.Intn(total)
for host, w := range weights {
if r < w {
return host
}
r -= w
}
return "" // fallback
}
- 注意：该函数需在每次请求中调用，不能复用
rand.Rand实例而不加锁；建议用rand.New(rand.NewSource(time.Now().UnixNano()))或全局sync.Pool管理 - 若权重动态更新（如从 etcd watch 变更），需加读锁保护
weightsmap，避免遍历时被修改 panic - 返回的 host 必须带端口（如
"v2.example.com:8080"），否则http.NewRequest会默认用 80
别忽略下游透传和可观测性
选完目标地址只是开始。用户看到的响应来自 v2，但 v2 日志里如果没带原始请求的灰度上下文，就无法关联排查。必须显式透传关键头：
- 把原始
X-Release-Stage、X-Request-ID、X-User-Id全部复制到下游req.Header中 - 给下游加一个新头：
X-Backend-Version: v2，方便日志聚合识别流量走向 - 在网关响应头里也加
X-Route-To: v2，用 curl 或脚本批量验证分流是否符合预期 - 记录每次选择结果（如
log.Printf("route %s → %s", reqID, backend)），别等出问题才翻日志找不着路径
权重灰度看着简单，真正落地时最容易卡在「配置没热更」「下游没透传」「日志没打标」这三处。只要目标地址可区分、权重存得稳、选得准、传得全，Gin 就能撑住中小规模灰度场景。
