市中心有一家生意火爆的“云上人家”餐厅，主厨最近研发了一道新菜。他当然希望所有客人都能尝到，但万一新菜翻车，老顾客全部失望，餐厅口碑就毁了。于是他想了个办法：先让传菜轨道把一小部分订单送到新厨房试做，给最先尝鲜的几桌客人上这道菜；观察他们的反应，如果没人皱眉，就再放多一些订单过去，直到最后每一桌都吃上新菜。整个过程里，客人完全无感，餐厅却稳稳地完成了“菜单升级”。 这套思路放到软件世界里，就是一个安全升级新版本的经典动作：把用户请求当作订单，把新版本服务当作新厨房，用一条智能传菜轨道控制每一份请求的去向，让新版本在真实流量中小步试错、渐进接管。本文就用这个餐厅故事，带你理解如何分割流量、如何分批放量、如何对比新旧效果，以及如何在厨房“冒烟”时及时切断传菜——这些都是云原生架构中的看家本领。

岗位关联

掌握流量管理与灰度发布，你就能像餐厅主厨一样在不打扰用户的前提下安全上线新功能，这是云架构师与 DevOps 工程师最核心的“降风险”技能。

目录
  1. 可视化演示
  2. 流量管理概述
  3. 金丝雀发布
  4. A/B测试路由
  5. 服务网格架构
  6. 灰度发布流程
  7. 流量治理实践
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示流量分割权重路由、金丝雀渐进发布策略与监控自动回滚机制，切换模式观察灰度发布全流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

流量分割权重路由 VirtualService按weight字段将请求按百分比分配到不同版本 v1权重90%接收大部分流量，v2权重10%灰度验证 traffic = v1·w1 + v2·w2, w1+w2=100% 流量分割是灰度发布与A/B测试的基础能力

流量管理概述

傍晚六点，“云上人家”迎来客流高峰。大堂的传菜调度台前，一张张点菜单从四面八方滑过来，调度员要在零点几秒内决定：这张单送去老厨房，那张单送去新厨房。客人不知道后厨有两个厨房，他们只关心菜能不能上齐。调度员的每一次选择，就是一次“流量管理”。

软件世界里，“流量”就是用户发出的一次次请求——登录、下单、刷视频，全都是。服务网格这条智能传菜轨道，负责把这些请求按规则送到不同版本的服务上。流量管理要回答三个问题：请求发给谁、发多少、出问题怎么调。

最基础的手段是流量分割：给每个目标服务一个权重，调度台按权重比例掷骰子。假设老厨房权重 \(w_1=7\)，新厨房权重 \(w_2=3\)，那么每 10 张订单大约有 7 张去老厨房、3 张去新厨房。这个比例计算是后面所有灰度策略的地基：

公式看着简单，却是主厨手里最灵活的旋钮：想多观察新菜，就把 \(w_2\) 调大；想保守一点，就调小。流量治理的三大目标——稳定、安全、可观测——全都建立在这枚小小旋钮之上。

Pi=wi∑j=1nwj\displaystyle P_i=\frac{w_i}{\sum_{j=1}^{n}w_j}
简单说就是：先把所有可选目的地（厨房）的权重加成一个总数，再拿单个厨房的权重除以总数，就知道它该接多少比例的订单。
  1. 分母求和先把所有参与路由的目的地权重加起来，得到总权重，相当于统计全部厨房的接待能力总和。
    S=∑j=1nwj\displaystyle S=\sum_{j=1}^{n}w_j
  2. 计算占比用目标服务自己的权重除以总权重，得到它应分到的流量比例。
    Pi=wiS\displaystyle P_i=\frac{w_i}{S}
  3. 校验总和所有目的地比例之和恒等于 1，保证流量既不会丢失也不会重复，就像每一张订单都恰好被送到一个厨房。
    ∑i=1nPi=1\displaystyle \sum_{i=1}^{n}P_i=1

金丝雀发布

如果直接更换菜单，让所有客人点新菜，主厨等于拿餐厅口碑下注——这太冒险了。他想起老矿工的方法：下矿前先放一只金丝雀进矿洞，鸟没事人才敢下去。于是他吩咐调度台：先让 5% 的点单送到新厨房。

“金丝雀发布”由此得名：先部署新版本与旧版本并存，只把一小部分真实流量切过去，通过健康检查确认没问题，再逐步放量。它强调“渐进”两个字——5%、20%、50%、100%，每一步都带着刹车，这正是它与“一键全量发布”的本质区别。

配置灰度策略时，服务网格会做三件事：按比例或标签挑选流量，周期性采集新版本的错误率与延迟，一旦指标越过红线就自动把流量拨回旧版本。红线如何设定？靠的就是错误率阈值，也就是新厨房“翻车率”的容忍上限：

主厨的屏幕上挂着两张表：一张是新厨房的出错率，一张是老厨房的基线。只要新表的数字越过 \(\theta\)，传菜轨道就会“咔哒”一声自动切换——这就是自动化回滚，全程不需要客人察觉，更不需要半夜爬起来改代码。

Erate=NerrNall,Erate>θ ⇒ 自动回滚\displaystyle E_{\text{rate}}=\frac{N_{\text{err}}}{N_{\text{all}}},\quad E_{\text{rate}}>\theta\ \Rightarrow\ \text{自动回滚}
这里 \(N_{\text{err}}\) 是新版本在观察窗口内出错的请求数，\(N_{\text{all}}\) 是进入新版本的总请求数，两者的比值超过阈值 \(\theta\) 就触发自动回滚。
  1. 错误请求统计在观察窗口内记录新版本返回错误的请求数量，相当于统计新厨房做糊了几道菜。
    Nerr=窗口内错误请求数\displaystyle N_{\text{err}}=\text{窗口内错误请求数}
  2. 总请求统计统计同一窗口内进入新版本的全部请求，相当于统计新厨房一共接了多少单。
    Nall=窗口内总请求数\displaystyle N_{\text{all}}=\text{窗口内总请求数}
  3. 阈值判断错误率超过预设阈值 \(\theta\) 时，说明新菜确实有问题，调度台立刻把流量切回老版本，不再等客人生气。
    Erate>θ ⇒ 回滚\displaystyle E_{\text{rate}}>\theta\ \Rightarrow\ \text{回滚}

A/B测试路由

金丝雀发布回答“新菜能不能吃”，A/B 测试回答“新菜和旧菜哪个更好吃”。主厨同时保留两个厨房，随机让一部分客人吃到旧配方，另一部分吃到新配方，再用满意度问卷对比结果。两者都做流量拆分，但目的完全不同：一个求稳，一个求优。

实现的关键是路由规则与分桶。路由规则决定请求按什么特征分发，比如按用户 ID 哈希、按地域、按客户端类型；分桶策略则保证同一个用户始终被送到同一个版本，否则他一会儿吃旧菜一会儿吃新菜，对比数据就彻底失真了。

两组跑一段时间后，需要判断新版本的指标提升是真实效果还是运气。这时要用统计检验——看两组转化率的差异相对随机波动有多大：

实验周期结束时，如果 \(z\) 的绝对值足够大，主厨就有底气全量上新；如果差异不显著，就老老实实保留旧菜。数据说话，不靠拍脑袋。

z=p^A−p^Bpˉ(1−pˉ)(1nA+1nB)\displaystyle z=\frac{\hat{p}_A-\hat{p}_B}{\sqrt{\bar{p}\left(1-\bar{p}\right)\left(\dfrac{1}{n_A}+\dfrac{1}{n_B}\right)}}
这个公式是在问一个朴素问题：A、B 两组的差距，到底是新菜真的更好吃，还是只是今天碰巧来的客人口味不一样？
  1. 计算转化率分别统计 A、B 两组的成功行为占比，比如下单成功率、点击率，得到 \(\hat{p}_A\) 与 \(\hat{p}_B\)。
    p^A=A组成功数nA,p^B=B组成功数nB\displaystyle \hat{p}_A=\frac{\text{A组成功数}}{n_A},\quad \hat{p}_B=\frac{\text{B组成功数}}{n_B}
  2. 合并估计把两组数据合并算出总体比例 \(\bar{p}\)，作为判断“随机波动该有多大”的基准。
    pˉ=nA p^A+nB p^BnA+nB\displaystyle \bar{p}=\frac{n_A\,\hat{p}_A+n_B\,\hat{p}_B}{n_A+n_B}
  3. 求标准误差分母衡量两组差异因偶然因素而出现的程度；样本量越大，误差越小，结论越可信。
    SE=pˉ(1−pˉ)(1nA+1nB)\displaystyle SE=\sqrt{\bar{p}\left(1-\bar{p}\right)\left(\frac{1}{n_A}+\frac{1}{n_B}\right)}
  4. 比较显著性\(z\) 的绝对值越大，说明差异越不可能是偶然，越有底气把菜单全面换成新配方。
    ∣z∣>1.96 ⇒ 差异显著\displaystyle |z|>1.96\ \Rightarrow\ \text{差异显著}

服务网格架构

这条智能传菜轨道到底由什么构成？主厨发现，每个厨房门口都挂着一个“托盘机器人”——它负责把订单端进端出，厨房内部完全不用改造。这些机器人连成一张网，就是数据平面。

光有机器人还不够，还得有“调度总台”——控制平面。它从不亲手传菜，而是定期告诉每个托盘机器人：接下来哪些订单送新厨房、超时多久算失败、错误率达到多少打开熔断。总台与机器人各司其职，就构成了服务网格的基本架构。

实践中最常见的组合是 Envoy 与 Istio：Envoy 是数据平面里最有名的代理，相当于托盘机器人的标准型号；Istio 是目前最主流的控制平面，相当于调度总台的参考设计。业务代码一行不用改，治理能力全部下沉到轨道里。主厨最关心的整体上菜速度，可以用加权平均来估算：

托盘机器人让每个服务都获得了“透视眼”：请求从哪来、到哪去、花了多久，一目了然。这就是流量观测能力，也是主厨做出“再放一批”还是“立刻回滚”决策的数据来源。

L=∑i=1nwi li\displaystyle L=\sum_{i=1}^{n}w_i\,l_i
每一条传菜路径的耗时 \(l_i\)，用它承接的流量比例 \(w_i\) 做权重加权求和，就得到用户实际感受到的平均上菜速度。
  1. 路径延迟取值采集每条传菜路径 i 的平均耗时 \(l_i\)，比如老厨房 120 毫秒、新厨房 150 毫秒。
    li=第 i 条路径的平均延迟\displaystyle l_i=\text{第 }i\text{ 条路径的平均延迟}
  2. 流量权重加权用各路径的流量占比 \(w_i\) 作为系数，把各路径延迟按比例加权求和，谁流量大谁就影响大。
    L=∑i=1nwi li\displaystyle L=\sum_{i=1}^{n}w_i\,l_i
  3. 整体视图\(L\) 代表用户真实体验的平均延迟，是容量规划、限流阈值设计的关键输入，也是灰度放量时最常盯的指标之一。

灰度发布流程

一道新菜从研发到全店上桌，不能靠灵感，要靠流程。“云上人家”的后厨墙上贴着一张“新品上架 SOP”，主厨每次照章办事，才敢保证不出乱子。灰度发布也一样，是一套可重复、可审计的标准动作。

SOP 分四步：第一步，把新版本部署到新厨房，与老版本并存；第二步，通过控制平面下发灰度策略，比如“先放 5%”；第三步，每批流量停留一个观察窗口，紧盯错误率与延迟；第四步，根据观测结果决策——继续放量、暂停还是回滚。这个顺序缺一不可，跳步往往就是事故的开始。

放量节奏用累积比例描述：第 \(k\) 批之后，新版本承载的总流量占比是多少？只要每批增量固定，累积占比就是一个简单求和：

主厨的体会是：灰度不是赌博，而是一次次带刹车的试探。每批放量都留出观察时间，让数据替决策说话，全量切换就成了水到渠成的最后一小步。

Ck=∑i=1kpi,当 Ck=1 时完成全量\displaystyle C_k=\sum_{i=1}^{k}p_i,\quad \text{当 }C_k=1\text{ 时完成全量}
\(p_i\) 是第 \(i\) 批新增的流量占比，把所有批次的占比加起来，就是新版本目前一共接了多少比例的流量。加到 1，灰度就结束了。
  1. 分批放量每次只新增一小批流量，批比例记作 \(p_i\)，相当于主厨每次只多放 5% 或 10% 的点单到新厨房。
    pi=第 i 批新增流量占比\displaystyle p_i=\text{第 }i\text{ 批新增流量占比}
  2. 累积求和把前 \(k\) 批的比例逐项相加，得到新版本当前承载的总流量占比 \(C_k\)。
    Ck=p1+p2+⋯+pk\displaystyle C_k=p_1+p_2+\cdots+p_k
  3. 全量判定当 \(C_k=1\) 即 100% 时，灰度结束，菜单完成切换，旧厨房进入待命状态。
    Ck=1 ⇒ 全量发布完成\displaystyle C_k=1\ \Rightarrow\ \text{全量发布完成}

流量治理实践

再严谨的流程，也挡不住意外：新厨房可能着火，托盘可能摔碎，客人可能突然爆满。于是“云上人家”在传菜轨道上加装了四样安全装置，让系统在意外面前依然稳得住。

第一样是流量镜像：把真实订单复印一份送给新厨房试做，复印件不影响真实上菜，适合大规模预演。第二样是熔断：新厨房故障率过高时，调度台直接断开这条轨道，订单快速走降级通道，不再往里送。第三样是限流：等位区控制进客速度，避免大厅被挤爆。第四样是故障注入：故意让某条轨道延迟几秒，看看整条链路会不会摔跟头，在演练中暴露弱点。

其中熔断最依赖数学判断：在一个滑动时间窗口里，失败请求数 \(F\) 与成功请求数 \(S\) 共同决定了故障比例，超过阈值 \(\phi\) 就打开开关：

有了这四样装置，即使新版本彻底翻车，主厨也能在几分钟内把损失控制到最小。到了多云多集群时代，这些治理手段还要跨地域协同下发——这正是云原生架构下流量治理的最后一公里。

FF+S≥ϕ ⇒ 熔断器打开\displaystyle \frac{F}{F+S}\ge \phi\ \Rightarrow\ \text{熔断器打开}
这个公式就是在问：最近这一段时间里，失败的单子占到总单子的多少？比例太高，说明那个厨房真的不行了，赶紧断粮止损。
  1. 滑动窗口计数在滑动时间窗口内分别记录失败请求数 \(F\) 与成功请求数 \(S\)，相当于统计最近一分钟内做糊了几道菜、上成了几道菜。
    F=窗口内失败数,S=窗口内成功数\displaystyle F=\text{窗口内失败数},\quad S=\text{窗口内成功数}
  2. 失败率计算用失败数除以总数，得到窗口内的失败比例。
    Rate=FF+S\displaystyle \text{Rate}=\frac{F}{F+S}
  3. 阈值触发失败率达到 \(\phi\) 时熔断打开，后续请求快速失败或降级返回，避免整条链路被一个坏厨房拖垮；等冷却期过后再半开试探，恢复则关闭熔断。

AI 应用场景

电商大促前的金丝雀发布

阶段：发布与运维

解决的问题：大促前电商团队必须上线新功能，但一次全量发布的风险极高——万一下单链路有缺陷，影响的是全站所有用户。传统做法“改完就全量上线”，出了问题只能紧急回滚，代价巨大。

具体案例：某电商平台在双十一前一周，用 Istio 的 VirtualService 把 5% 的流量切到新购物车服务。团队盯着下单成功率和 P95 延迟观察 30 分钟，确认平稳后依次放量到 20%、50%、100%。中途灰度版本出现过一次接口超时，健康检查触发自动回滚，新版本修复后才重新开始灰度。

金融 App 推荐算法的 A/B 测试

阶段：实验与决策

解决的问题：推荐算法新模型是否真的比旧模型好，靠直觉判断不可靠；直接全量替换又怕用户留存下降。需要一种能“同时跑、可对比、有统计结论”的验证方式。

具体案例：某金融 App 将用户按用户 ID 哈希分桶，50% 走旧推荐模型、50% 走新模型，运行两周后对比点击率与人均使用时长，用显著性检验确认新模型提升 3.2% 且差异显著，才决定全量切换。

故障演练中的流量镜像与注入

阶段：稳定性治理

解决的问题：新架构上线前，真实故障场景难以预演：机房断网、下游超时、流量突增，哪一种都可能在关键时刻爆发。靠“到时候再说”显然不够。

具体案例：某云厂商在预发集群中开启流量镜像，把生产环境真实请求复制一份灌入新架构；同时配合故障注入，人为让某条链路延迟 2 秒，验证熔断能否及时打开、降级接口是否兜得住，最终把多集群容灾能力提升到了分钟级。

Python 演示

python73 行
import random  class StableService:    # 老版本: 运行稳定 几乎不出错    def handle(self):        return "error" if random.random() < 0.01 else "ok"  class CanaryService:    # 新版本: buggy=True 时模拟带缺陷上线    def __init__(self, buggy=False):        self.bug_rate = 0.15 if buggy else 0.01     def handle(self):        return "error" if random.random() < self.bug_rate else "ok"  class CanaryRouter:    # 传菜调度台: 按权重把订单送到新旧两个厨房    def __init__(self, stable, canary, weight=0.1):        self.stable = stable        self.canary = canary        self.weight = weight        self.count_map = {"stable": 0, "canary": 0}        self.error_map = {"stable": 0, "canary": 0}     def route(self):        is_canary = random.random() < self.weight        name = "canary" if is_canary else "stable"        target = self.canary if is_canary else self.stable        self.count_map[name] += 1        if target.handle() == "error":            self.error_map[name] += 1        return name     def error_rate_of(self, name):        if self.count_map[name] == 0:            return 0.0        return self.error_map[name] / self.count_map[name]  def run_batch(router, size=1000):    for _ in range(size):        router.route()  def simulate(buggy, threshold=0.05):    router = CanaryRouter(StableService(), CanaryService(buggy))    plan = (0.2, 0.4, 0.8, 1.0)    for target in plan:        run_batch(router)        canary_err = router.error_rate_of("canary")        stable_err = router.error_rate_of("stable")        print("weight=%d%% canary_err=%.2f%% stable_err=%.2f%%" %              (router.weight * 100, canary_err * 100, stable_err * 100))        if canary_err > threshold:            print("canary unhealthy, rollback to stable")            return False        router.weight = target    print("full release finished")    return True  def main():    print("== scenario 1: healthy canary ==")    simulate(buggy=False)    print("== scenario 2: buggy canary ==")    simulate(buggy=True)  if __name__ == "__main__":    main()
目的：用纯 Python 模拟金丝雀发布全过程——按权重切分流量、分批放量、健康检查，并展示“健康版本成功全量”与“缺陷版本触发回滚”两种结局。
  1. class CanaryRouter:它就是传菜调度台，同时握着新旧两个厨房的出入口，负责按权重分单。
  2. self.weight = weight灰度比例，相当于调度台上“送多少单去新厨房”的旋钮。
  3. is_canary = random.random() < self.weight每张订单抵达时掷一次骰子，决定走老厨房还是新厨房。
  4. self.count_map[name] += 1给每种版本记一笔总单数，用于后面计算错误率。
  5. def error_rate_of(self, name):观察窗口内某一版本的出错比例，对应餐厅的投诉率统计。
  6. plan = (0.2, 0.4, 0.8, 1.0)放量节奏表：20%、40%、80%、100%，每批都要先观测再放量。
  7. if canary_err > threshold:新厨房投诉率超标，立刻停止放量并回滚到稳定版。
  8. simulate(buggy=True)故意带缺陷上线，用于演示自动回滚路径。

常见误区

误区“灰度发布就是把服务器拆成两半，一半跑新版一半跑旧版，然后再合并起来，本质是换机器。”

正解灰度发布的核心单位是“流量”而不是“机器”。新旧两套版本可以同时在线，关键在于用权重控制多少比例的请求进入新版本。机器只是承载流量的容器，真正被“切分”的是那份看不见的流量，正如餐厅里新旧两个厨房同时开着，区分客人的只是传菜轨道上的调度旋钮。

为何常见：人们习惯从资源视角理解部署，忽略了服务网格在流量层提供的抽象——调权重比换机器优雅得多，也快得多。

误区“金丝雀发布和 A/B 测试不都是新旧版本一起跑吗？一个意思。”

正解两者目标截然不同。金丝雀发布的目的是“验证稳定性并渐进放量直到全量”，是发布手段；A/B 测试的目的是“比较新旧版本的业务指标谁更优”，是实验手段，可以长期双跑、并不一定全量切换。就像金丝雀问“这菜能不能吃”，A/B 测试问“哪个更好吃”，问题不同，答案自然不同。

为何常见：两者都涉及流量拆分，表面流程相似，于是被误认为同一件事，实际上连决策指标都不一样。

误区“服务网格 = 在每个服务前面挂一个反向代理，跟负载均衡器没什么区别。”

正解数据平面的 sidecar 代理只是服务网格的一半。真正的价值在控制平面——集中下发行路、限流、熔断、观测等治理规则，像调度总台统一指挥所有托盘机器人。负载均衡只解决“往哪分发”，服务网格解决“如何统一治理、如何让流量变得可编程”。

为何常见：只看到了数据包被代理转发的表象，忽略了控制平面“集中管控、业务零改动”的架构精髓。

误区“新版本出问题了，那就把代码改回旧版本，重新发布一次。”

正解由于灰度发布天然要求新旧版本并存，回滚根本不需要重新部署——只要把流量权重从新版本拨回旧版本，秒级生效。这相当于传菜轨道上的开关一拨，订单全部回流老厨房，新厨房原地待命排查。把“发布”和“部署”混为一谈，是很多新手踩坑的根源。

为何常见：传统发布方式里改一次代码就要重新部署一次，形成思维定式；灰度发布最大的好处恰恰是“发布与部署分离”。

面试题

Q1. 金丝雀发布的核心思想是什么？

单选题 · easy

  • A.新版本一次性推送给所有用户
  • B.少量流量先试新版本再放量← 正确答案
  • C.新旧版本环境完全相同并行
  • D.新版本上线后立即删除旧版

答案：B。金丝雀发布先把少量真实流量导入新版本，观察健康指标后再逐步放量，强调“渐进”。一次性全量推送违背渐进原则；新旧环境完全并行只是必要条件，不是核心思想；立即删除旧版更是放弃了回滚的退路。

Q2. 服务网格中负责实际转发业务流量的部分是什么？

单选题 · easy

  • A.控制平面管理模块
  • B.数据平面代理组件← 正确答案
  • C.业务应用容器进程
  • D.配置数据库集群

答案：B。数据平面的 sidecar 代理像托盘机器人一样贴近每个服务，负责实际搬运请求；控制平面只负责下发规则、收集观测数据，不碰业务流量；业务容器和配置库都不是转发主体。

Q3. 灰度发布过程中，健康检查发现新版本错误率超过阈值，正确的做法是什么？

单选题 · mid

  • A.继续提高灰度比例等错误自愈
  • B.立即回滚到旧版本并排查问题← 正确答案
  • C.停止全部服务暂停对外业务
  • D.删除旧版本只保留新版本

答案：B。错误率超过阈值说明新版本存在缺陷，应立刻把流量切回旧版本止损。继续放量会扩大故障面；停止全部服务影响所有用户，代价更大；删除旧版本等于自断退路，都是错误选项。

Q4. A/B 测试中“分流”的本质是什么？

单选题 · mid

  • A.按权重将请求路由到不同版本← 正确答案
  • B.按服务器剩余内存分配请求
  • C.按用户地域就近分配请求
  • D.将请求复制发给全部服务端

答案：A。A/B 分流的本质是按规则（权重、用户特征等）把请求分发到不同版本上做对照实验。按内存分配是负载均衡的细枝末节，就近分配属于加速策略，复制请求则是流量镜像而非分流。

Q5. 流量权重公式 \(P_i=\frac{w_i}{\sum_{j=1}^{n}w_j}\) 中，分母的 \(j\) 表示什么？

单选题 · mid

  • A.参与路由的全部目标版本集合← 正确答案
  • B.当前请求所在用户的来源组
  • C.新版本内部署的实例数量
  • D.服务网格中控制平面的总数

答案：A。分母对所有权重求和，其中 \(w_j\) 是所有参与路由的目标版本各自的权重，\(j\) 遍历全部目标。用户来源、实例数量和控制平面数量都与权重公式无关，属于干扰项。

Q6. 熔断器打开之后，系统通常会如何处理进入的流量？

单选题 · hard

  • A.请求快速失败或降级处理返回← 正确答案
  • B.请求继续转发尝试探测服务
  • C.请求自动排队等待故障恢复
  • D.请求转移到备用机房重试

答案：A。熔断打开意味着目标服务已不健康，调用方不再等待超时，而是直接快速失败或走降级逻辑，保护自身不被拖垮。继续转发会加剧故障，排队等待和转移机房都不是熔断机制的语义。

Q7. 流量镜像（Traffic Mirroring）的主要用途是什么？

单选题 · easy

  • A.复制一份线上流量用于测试验证← 正确答案
  • B.把流量从主集群迁移到备集群
  • C.压缩流量以降低网络带宽占用
  • D.加密流量以防止数据被窃取

答案：A。流量镜像把真实请求复制一份发给测试环境，原请求不受任何影响，适合对新版本做无风险预演。迁移、压缩、加密都不是镜像的目标，镜像的核心是“复制、旁路、不影响线上”。

Q8. 以下哪些属于灰度发布的常见策略？

多选题 · mid

  • A.按用户比例逐渐放量灰度← 正确答案
  • B.按地域分区逐步灰度← 正确答案
  • C.按权重比例切割流量← 正确答案
  • D.一键全量升级全部节点

答案：ABC。常见灰度策略包括按用户比例放量、按地域分区放量、按权重切割流量，它们都符合“小步试错、逐步扩大”的原则。一键全量升级恰恰是灰度要避免的冒险动作。

Q9. 服务网格的控制平面通常负责哪些能力？

多选题 · mid

  • A.下发路由与限流策略配置← 正确答案
  • B.收集遥测并生成治理规则← 正确答案
  • C.逐包转发每个业务请求
  • D.管理服务间 TLS 证书签发← 正确答案

答案：ABD。控制平面类似调度总台，负责策略下发、遥测收集和证书管理；而逐包转发每个业务请求是数据平面代理的职责，不属于控制平面。搞混这两个平面的分工是常见面试失分点。

Q10. 关于灰度发布的回滚机制，下列说法正确的是？

多选题 · hard

  • A.自动回滚依赖健康检查指标← 正确答案
  • B.回滚通常只需调整流量权重← 正确答案
  • C.回滚前必须重新部署旧版本
  • D.回滚后需要保留观测日志← 正确答案

答案：ABD。自动回滚由健康检查触发，错误率、延迟等指标超过阈值即自动执行；由于新旧版本并存，调整流量权重即可实现秒级回滚，无需重新部署旧版本；回滚后保留观测日志有助于事后定位缺陷根因，因此 C 错误。