流量路由：精准控制模型请求分发

可视化演示

展示MLOps流量路由核心策略：从均匀分发到权重路由、灰度发布和流量切换，直观理解多版本模型请求分发控制机制。

认识路由——路口的交通指挥官

清晨七点的城市路口，红绿灯轮换、车道线清晰、交警手势利落，成千上万的车辆各归其位，没有一辆车会因为“不知道走哪条道”而停在原地。这套井然秩序的背后，是一套精细的调度逻辑。模型服务世界里也有同样的路口，只是“车”变成了请求，而“交警”就是流量路由。

一个模型随着迭代会产生多个版本：v1.0 稳定版、v1.1 性能优化版、v2.0 重构测试版，它们常常同时部署在线。流量路由要回答的只有一个问题：当前这个请求，该交给哪个版本处理？答案来自请求自身携带的信息——用户 ID、设备类型、参数——以及平台预先配置好的路由策略。

在 MLOps 架构中，流量路由通常由 API 网关或独立的 Router 组件承担。它拦截请求、解析特征、与路由规则比对，然后转发到对应版本的后端服务。理解流量路由要抓住它的核心价值：一是多版本并行，新旧模型互不干扰；二是风险可控，新版本出问题只影响分到它的那部分流量。另外要分清它与负载均衡的区别——负载均衡关心“每台机器别太累”，流量路由关心“这个请求该去哪个版本”。

有了这位交通指挥官，再混乱的车流也能各得其所。不过，指挥官手里的那本“交规”——路由规则——是怎么设计出来的？我们下一节来看。

路由规则设计——路口指示牌的编排

一个路口的指示牌不是胡乱立的：“左转车道 7:00—9:00 禁行”“公交车专用道”“学校路段减速”——每条规则都有明确的触发条件和作用对象。路由规则同样是路口的一张张“电子指示牌”，告诉每个请求：你符合什么条件，就去哪条路。

路由规则由两大要件构成：匹配条件（match）和目标动作（action）。匹配条件描述“什么请求”——比如用户 ID 在某个区间内、请求路径以 /v2 开头；目标动作描述“送到哪”——比如转发到 v2.0 版本的推理服务。两者组合起来，就是一条完整的规则。

规则之间讲究优先级：平台按优先级从高到低依次匹配，一旦命中立即执行动作，不再继续向下比对。工程上，规则支持热加载——在 MLOps 平台上修改规则后无需重启网关，路由组件会自动拉取最新规则表，这相当于“交警的指示牌实时远程更新”。多个条件之间还能用逻辑运算组合出复杂表达式，让“特定用户 + 特定路径”这类组合条件成为可能。

一块指示牌管一类车，一套规则管一类请求。规则井井有条，路口才不会乱——当指示牌能动态更新、按序生效，交通指挥就拥有了第一层智慧。

权重流量分配——信号灯的配时哲学

路口信号灯为什么直行给 70 秒、左转只给 30 秒？因为这大致匹配了两条车道的真实需求，让车辆按比例有序通过。流量路由的权重分配正是这种“配时哲学”：不给某条路“一刀切”的开关，而是按比例同时放行。

权重分配的核心思想很简单：给每个模型版本设置一个权重值，请求按权重占比被分发到对应版本。比如 v1.0 权重 70、v1.1 权重 30，那么长期来看，约 70% 的请求去 v1.0，30% 去 v1.1。

实现上有几种常见方案。最朴素的是“加权随机”：掷一次骰子，落在谁的区间就归谁，实现简单，但短时间窗口内流量比例会忽高忽低。工程上更常用平滑加权轮询（Smooth Weighted Round-Robin）：每一轮给所有版本加分、选中者减分，像“轮流值班 + 欠账补齐”一样让流量平稳。对于需要状态保持的场景（比如对话上下文），则用一致性哈希，让同一用户 ID 的请求始终打到同一版本，避免跨版本导致会话断裂。

信号灯的配时不是拍脑袋定的，权重分配同样被精确计算过——多一分拥堵，少一分不够。想在新旧版本之间安全地调配比例，光有权重还不够，还需要一条循序渐进的放行策略，这就是下一节的灰度发布。

灰度发布——新路先让少量车试跑

一条新修的路通车前，不会一夜之间把全部车流引过去，而是先放行少量车辆试跑，确认路基、标识、信号灯都正常后，再逐步加大放行量。如果试跑车辆反馈路况有问题，交警随时可以拉回旧路。灰度发布就是模型界的“新路试跑”。

灰度发布让新版本先接收一小部分真实流量（比如 5%），在监控指标确认健康后，按阶梯逐步放量：5% → 10% → 25% → 50% → 100%。它的好处显而易见：万一新版本效果差，影响面被限制在极小的范围内，绝大多数用户完全无感。

每一步放量都以健康检查为前提。健康检查的指标包括错误率、推理延迟、业务效果（如推荐点击率）等，一旦指标越过阈值，自动触发回滚——路由规则瞬间切回旧版本，不需要重新部署。发布观测贯穿整个流程，平台记录每个阶段的流量比例与指标趋势，形成一份可审计的发布报告，这就是“步步留痕”。

每多放一批车，交警都盯着监控确认安全；灰度发布的每步放量，同样以数据说话。但有些场景等不起渐进放量——比如安全补丁需要立刻全量生效，那就轮到蓝绿部署登场了。

蓝绿部署——双路并行整体切换

有些路口不适合渐进式试跑，而是在旁边直接修一条规格相同的新路，验证合格后，择日将所有车辆统一改道。这类“整体切换”的策略在部署界叫蓝绿部署：蓝色环境跑当前线上版本，绿色环境跑新版本，二者并行部署、互不干扰。

蓝绿部署的关键动作是切换：当绿色环境完成全量验证、健康度达标后，只需把路由入口从蓝色整体拨向绿色，流量便在一瞬间完成版本更替——这个过程是原子化的，不存在“切了一半”的中间态。同理，如果新版本上线后出现严重问题，回滚也只需要把路由再拨回蓝色，秒级完成。

蓝绿部署的优点突出：切换快、回滚简单、版本间完全隔离。缺点同样明显：资源成本近乎翻倍——两套环境需要同时在线运行，对 GPU 等昂贵算力并不友好。因此它更适合“重切换、轻迭代”的场景，比如大版本重构或安全补丁。切换前必须对绿色环境做充分验证，最常用的准入门槛就是健康度不低于约定的 SLO。

新路验收合格才能整体改道，蓝绿部署同样以指标为准绳，绝不做没把握的切换。无论是灰度还是蓝绿，都需要在“放行之前”尽量了解新路的路况——流量镜像正是那台不干预行驶的监控探头。

流量镜像——装一双不干预的观察眼

交警想知道某条新路线是否顺畅，不必真把车放上去，只需调出监控探头，把所有车的行驶数据复制一份来做分析。流量镜像干的就是这件事：把线上真实请求复制一份发给新模型版本，但新版本的输出直接被“观察者”收走，不返回给用户。

流量镜像也被称为影子流量（Shadow Traffic）。它的核心价值在于“零影响评估”：新模型在处理最真实的生产请求，用户却完全无感知——即使新模型答得再离谱，也不会伤害任何一位真实用户。这是灰度发布之前最好的一层“预检”。

实现上要注意三点：第一，请求复制由网关完成，采用异步发送，避免拖慢主链路响应；第二，镜像请求要打上特殊标记，防止它对数据库、下游服务产生“副作用”；第三，通过比对同一请求在新旧版本上的输出差异，量化新版本的优劣。当镜像评估通过后，再配合灰度发布逐步放真实流量，两者形成最稳妥的组合拳。

监控探头不影响任何一辆车的行驶，却让交警对路况了如指掌。路由、权重、放量、镜像各就各位之后，剩下的问题是如何把这些能力像智能交通系统一样管起来——这就是工程落地。

工程落地——从交警到智能交通系统

现代城市的交通管理早已不是一位交警站在路口，而是一整套智能交通系统：态势大屏实时刷新、异常事件自动预警、应急预案一键启动、调度平台统一配置。流量路由的工程落地，同样是从“单点交警”走向“体系化平台”。

在 MLOps 平台中，流量路由必须与完整的可观测体系配合。核心指标包括：路由决策延迟（路由器本身不能成为瓶颈）、各版本流量占比（验证实际分流与配置一致）、错误率与 P99 延迟（衡量版本健康度）。指标上报到监控中心，异常触发告警，告警再联动自动回滚，形成“监控 → 告警 → 处置”的闭环。

工程规范同样重要：每次大版本发布前要做故障演练，提前验证回滚预案是否真的有效；路由配置的每次变更都要有审计记录，出了问题能追溯到人；平台化之后，研发只需在界面上拖动权重滑块或勾选规则条件，就能完成一次灰度比例调整，无需人工修改配置文件。这套体系让流量路由从“会转发的代码”升级为“可运营的基础设施”。

只有当指挥、监控、预案、平台各就各位，流量路由才能真正成为守护模型服务的“智能交通系统”。从认识概念到工程落地，六层能力环环相扣，共同构成 MLOps 中精准发号施令的中枢。

AI 应用场景

Python 演示

"""Simulate weighted traffic routing: random vs smooth weighted round-robin."""import randomfrom collections import Counter  class WeightedRouter:    """Router that distributes requests to model versions by weight.     versions: dict like {"v1.0": 70, "v1.1": 20, "v2.0": 10}    """     def __init__(self, versions):        self.names = list(versions.keys())        self.weights = list(versions.values())        self.total = sum(self.weights)        self.current = self.weights[:]  # 平滑轮询的积分器初始值     def pick_random(self):        """加权随机:掷一次骰子,落在谁的权重区间就选谁"""        r = random.uniform(0, self.total)        acc = 0        for i, name in enumerate(self.names):            acc += self.weights[i]            if r <= acc:                return name        return self.names[-1]     def pick_smooth(self):        """平滑加权轮询:每轮加分,选中者减分,流量更平稳"""        best = 0        for i in range(len(self.names)):            self.current[i] += self.weights[i]            if self.current[i] > self.current[best]:                best = i        self.current[best] -= self.total        return self.names[best]  def run(router, rounds, pick):    counter = Counter()    for _ in range(rounds):        counter[pick()] += 1    return counter  def max_deviation(router, rounds, pick, window=100):    worst = 0.0    for _ in range(rounds // window):        c = run(router, window, pick)        ratio = c["v1.0"] / window        worst = max(worst, abs(ratio - 0.7))    return worst  def main():    versions = {"v1.0": 70, "v1.1": 20, "v2.0": 10}    for label, method in (("random", "pick_random"), ("smooth", "pick_smooth")):        router = WeightedRouter(versions)        pick = getattr(router, method)        result = run(router, 100000, pick)        print("%s distribution (100000 requests):" % label)        for name in versions:            print("  %s -> %.2f%% (expected %d%%)" % (name, result[name] / 1000.0, versions[name]))        worst = max_deviation(WeightedRouter(versions), 100000, pick) * 100        print("  max deviation in 100-request windows: %.2f%%" % worst)  if __name__ == "__main__":    main()

1. self.total = sum(self.weights)提前算出总权重，作为“掷骰子”的区间上界和归一化分母。
2. self.current = self.weights[:]复制一份权重作为积分器，平滑轮询靠它记录每个版本“欠了多少流量”。
3. r = random.uniform(0, self.total)在 0 到总权重之间掷出随机数，落在哪个版本区间就选哪个版本。
4. if r <= acc:累加权重边界，判断随机数命中的版本，相当于把区间切成 n 段。
5. self.current[i] += self.weights[i]每个轮次先给所有版本加一次权重分，表示“应该获得这么多流量”。
6. if self.current[i] > self.current[best]:找出当前积分最高的版本，它是最“欠流量”的一个。
7. self.current[best] -= self.total选中后扣掉总权重，防止某个版本被持续选中，保证长期均衡。
8. counter[pick()] += 1用计数器统计实际分到的请求数，验证分配比例是否接近期望。
9. abs(ratio - 0.7)短窗口内 v1.0 实际占比与期望 70% 的偏差，偏差越小说明策略越平稳。

常见误区

面试题