想象你生活在一个热闹的美食广场：几十个档口同时出餐，顾客点完酸菜鱼又去点奶茶，后厨之间还要互相借调料。如果没有统一调度，很快就会有人喊“我的外卖怎么还没来”，后厨也会因为压力太大直接摆烂。Service Mesh 就是给每个档口门口配一位“金牌调度小哥”：顾客不直接对后厨喊话，而是把需求告诉小哥，由小哥负责排队、传菜、催单、甚至在后厨着火时挂出“暂停营业”的牌子。 这位调度小哥要掌握四样本领：熔断——后厨起火就果断停止送单，避免火越烧越大；限流——门口取号限量放行，防止小店被挤爆；重试——餐洒了就重新下单，但绝不重复扣款；超时——超过出餐时间就直接取消，谁也不傻等。这四个本领，正是微服务治理中最核心的稳定性武器。理解了它们，你就掌握了云原生时代服务间通信的“保命术”。

岗位关联

对 AI 从业者而言，模型推理、RAG 检索、智能体编排都依赖大量服务调用；掌握熔断、限流、重试、超时，能让你设计的 AI 系统在大流量下不崩、关键时刻能降级、对外永远有响应。

目录
  1. 可视化演示
  2. 服务治理概述
  3. 熔断机制
  4. 限流算法
  5. 重试策略
  6. 超时控制
  7. 组合最佳实践
  8. 实战案例
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示熔断器三态状态机转换、令牌桶与漏桶限流算法对比及指数退避重试机制，交互切换各模式查看细节。

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

熔断器：三态状态机自动保护 闭态：请求正常通过，持续统计失败率 开态：失败率超阈值时熔断，请求快速失败 失败率 > 50% → Closed转Open 半开态探测恢复后自动回到闭态

服务治理概述

在美食广场里，顾客不需要冲进后厨大喊“少放辣”，而是对档口外面的调度小哥下订单。这位小哥站在每个服务旁边，所有进出的请求都要经过他，这就是 Sidecar 代理。所有 Sidecar 连成一张网，称为数据面；而广场管理办公室负责下发菜单、限购规则、营业时间，这就是控制面。服务本身完全不感知这些规则，商家不需要改菜谱，只需在档口门口“加一个小哥”——这种接入方式称为非侵入式接入。

技术上讲，Service Mesh 把原本散落在业务代码里的容错逻辑下沉到基础设施层。以前每个微服务都要自己写超时、重试、熔断代码，现在统一由 Sidecar 完成。业务开发只需要专注“做菜”，稳定性交给“调度小哥”。但在享受便利的同时，也要知道小哥本身也会消耗时间。无论 Sidecar 多轻量，每多一跳都会增加延迟，这在大规模调用链上必须被度量。

调度小哥会带来一点“跑腿费”，但只要这笔费用远小于业务价值，就值得。Service Mesh 的强大之处，正是用这可控的额外延迟，换回整个美食广场的秩序与安全。

Tall=Tbiz+Tproxy×Hhop\displaystyle T_{all} = T_{biz} + T_{proxy} \times H_{hop}
总耗时 = 业务处理时间 + 每个代理跳数乘以单跳代理开销。
  1. T_all 表示单次调用的总耗时即用户从发出请求到收到响应所经历的完整时间，是衡量服务体验的最终指标。
    Tall=Tbiz+Tproxy×Hhop\displaystyle T_{all} = T_{biz} + T_{proxy} \times H_{hop}
  2. T_biz 表示业务代码实际耗时类似于大厨真正炒菜的时间，与网络框架无关。
    Tbiz\displaystyle T_{biz}
  3. H_hop 表示请求经过的代理跳数一次调用经过多少个 Sidecar，每经过一个就多一次转发。
    Hhop\displaystyle H_{hop}
  4. T_proxy 表示单跳代理开销调度小哥每次登记、校验、转发所花的时间，把它乘以跳数就是总代理开销。
    Tproxy×Hhop\displaystyle T_{proxy} \times H_{hop}

熔断机制

假设某天后厨的油锅起火了，如果调度小哥还在源源不断把订单送进去，火会越烧越大，厨师也会彻底崩溃。正确的做法是：一旦发现后厨连续出问题，小哥立刻挂出“暂停营业”的牌子，不再接收新订单，让后厨有时间灭火。这就是熔断。

熔断器有三种状态：关闭时请求正常通过；打开时直接快速失败，不再访问后端；半开时放少量探测请求，看看后厨是否恢复。判断是否熔断，不能只凭一两次失败，而要看滑动窗口内的失败率。窗口内记录最近 N 个请求的成功与失败情况，只有失败率超过阈值，才触发熔断。

熔断不是“永远停业”，而是给后厨一段灭火时间。等熔断器进入半开状态，只放一两个“探路订单”，成功后逐步恢复流量；如果再次失败，就继续打开。这套机制让美食广场在局部失火时，其他档口依然正常营业。

Rfail=FcountScount+Fcount\displaystyle R_{fail} = \frac{F_{count}}{S_{count} + F_{count}}
熔断判断的核心是滑动窗口里的失败率。
  1. F_count 表示失败请求数包括网络错误、超时、5xx 响应等让调用方无法拿到正确结果的请求。
    Fcount\displaystyle F_{count}
  2. S_count 表示成功请求数后端正常返回结果，业务方可以继续处理。
    Scount\displaystyle S_{count}
  3. R_fail 表示失败率失败数除以窗口内总请求数，也就是“后厨这段时间掉链子的比例”。
    Rfail=FcountScount+Fcount\displaystyle R_{fail} = \frac{F_{count}}{S_{count} + F_{count}}
  4. 阈值判定当失败率大于预设阈值，熔断器从关闭切换到打开，让新请求快速失败。
    Rfail≥Rthreshold\displaystyle R_{fail} \ge R_{threshold}

限流算法

周末开门前，美食广场门口已经排了几百人。如果同时涌进店，过道会被堵死，厕所、收银台全部超载。调度小哥的做法是“取号限流”：每分钟只放固定的客人进店，其他人先在外面排队。这就是限流——控制进入系统的请求速率，保护后端不被峰值流量冲垮。

Service Mesh 中常见的限流算法有三种：令牌桶允许一定程度的突发流量；漏桶把请求均匀地排出去；滑动窗口则精确统计最近一段时间内的请求数，避免固定窗口首尾交界处的流量尖刺。最常用的是令牌桶：桶像一个杯子，按固定速率往里放令牌，每个请求必须取走一枚令牌才能通过。杯子容量有限，因此允许的突发量也是有限制的。

每来一个请求，令牌数减一；如果令牌不足，请求就会被拦下或排队。限流不是拒绝所有客人，而是让美食广场始终处于可服务的状态：外面排长队总比店里彻底瘫痪要好。

Ntokens=min⁡(Cmax, Ntokens+(tnow−tlast)×r)\displaystyle N_{tokens} = \min(C_{max},\ N_{tokens} + (t_{now} - t_{last}) \times r)
令牌桶的核心公式：先按时间补充令牌，但不超过桶容量。
  1. N_tokens 表示当前令牌数可以理解为杯子里还剩多少枚“入场券”。
    Ntokens\displaystyle N_{tokens}
  2. (t_now - t_last) 表示距离上次补充的时间间隔时间过去越久，理论上补充的令牌越多。
    tnow−tlast\displaystyle t_{now} - t_{last}
  3. r 表示令牌补充速率每秒往杯子里放多少枚令牌，决定了系统的平均处理能力。
    (tnow−tlast)×r\displaystyle (t_{now} - t_{last}) \times r
  4. min(C_max, ……) 表示令牌上限杯子再大也有容量上限，所以瞬时突发流量被控制在 C_max 之内。
    Ntokens=min⁡(Cmax, Ntokens+(tnow−tlast)×r)\displaystyle N_{tokens} = \min(C_{max},\ N_{tokens} + (t_{now} - t_{last}) \times r)

重试策略

传菜小哥端着一碗酸菜鱼走向顾客，结果被绊倒，汤洒了一地。正确的做法是回到后厨重新下一单，而不是让顾客干等，更不是让后厨同时做三碗。但在分布式系统里，重试一定要讲策略：无脑重试会让后厨同时收到大量重复订单，直接压垮服务。

Service Mesh 中的标准做法是指数退避：第一次失败后等 100ms 再试，第二次等 200ms，第三次等 400ms，逐渐拉开间隔。再加入随机抖动，让不同请求的重试时间错开，避免“整点集体重试”形成雷暴。同时要设置最大重试次数和重试预算，并且保证接口幂等——同一笔订单重试多次，也只扣一次款。

重试是“给后厨一次改过的机会”，但机会不能无限给。真正专业的调度小哥会记录每笔订单的幂等键，洒了汤就重新做，但绝不会让收银台重复扣两次款。

Dwait=min⁡(Dmax, Dbase×2(attempt−1)+rand(0,J))\displaystyle D_{wait} = \min(D_{max},\ D_{base} \times 2^{(attempt-1)} + \text{rand}(0, J))
指数退避 + 抖动：让重试间隔越来越大，并且带一点随机性。
  1. D_base 表示基础等待时间第一次重试前需要等待的初始时长，比如 100ms。
    Dbase\displaystyle D_{base}
  2. 2^(attempt-1) 表示按次数指数增长第 1 次重试乘 1，第 2 次乘 2，第 3 次乘 4，让重试越来越稀疏。
    2(attempt−1)\displaystyle 2^{(attempt-1)}
  3. rand(0, J) 表示随机抖动在等待时间上叠加一个随机值，避免所有请求同时重试。
    rand(0,J)\displaystyle \text{rand}(0, J)
  4. min(D_max, ……) 表示等待时间上限重试间隔不能无限增大，要设置一个最大值，否则用户等不起。
    Dwait=min⁡(Dmax, Dbase×2(attempt−1)+rand(0,J))\displaystyle D_{wait} = \min(D_{max},\ D_{base} \times 2^{(attempt-1)} + \text{rand}(0, J))

超时控制

顾客点了一杯现煮奶茶，调度小哥说“大约 10 分钟”。如果 30 分钟还没好，你是继续等，还是果断退单？在分布式系统里，答案一定是退单。因为每一次等待都在占用一个连接、一个线程、一份内存，全广场的人都在等的话，整个系统就会被“占着茅坑不拉屎”的请求拖垮。

超时分为连接超时和请求超时。连接超时是“连不上就放弃”，请求超时是“发出后等不到结果就放弃”。更高级的做法是设置全链路超时预算：一个外部请求总共有 3 秒预算，A 服务用了 1 秒，B 服务最多只能花 1.5 秒，还要留 0.5 秒给下游。Service Mesh 会把 Deadline 信息通过请求头传递下去，让链路上每个服务都知道自己还剩多少时间。

调度小哥心里有一张“倒计时表”：如果奶茶 10 分钟做不出来，就主动跟顾客说抱歉，而不是让顾客在吧台前无限等下去。超时是保护全局的最后一道闸门，宁可快速失败，不可无限挂起。

Tremaining=Tbudget−Telapsed,Tchild≤Tremaining−Tbuffer\displaystyle T_{remaining} = T_{budget} - T_{elapsed},\qquad T_{child} \le T_{remaining} - T_{buffer}
下游子调用能用多少时间，等于剩余预算减去预留安全垫。
  1. T_budget 表示总超时预算整个请求可以存活的最长时间，例如 3 秒。
    Tbudget\displaystyle T_{budget}
  2. T_elapsed 表示已经消耗的时间从链路入口开始到现在已经过去的时间。
    Telapsed\displaystyle T_{elapsed}
  3. T_remaining 表示剩余时间总预算减去已消耗时间，这是当前还能支配的时间。
    Tremaining=Tbudget−Telapsed\displaystyle T_{remaining} = T_{budget} - T_{elapsed}
  4. T_buffer 表示给下游预留的安全缓冲不能把剩余时间全花完，必须给以后可能出现的问题留余地。
    Tchild≤Tremaining−Tbuffer\displaystyle T_{child} \le T_{remaining} - T_{buffer}

组合最佳实践

熔断、限流、重试、超时不是四个孤立的工具，而是同一个调度小哥身上的四件套。优秀的小哥不会等后厨彻底起火才行动，而会在门口限流、在窗口看时间、在故障时熔断、在偶失误时重试。它们必须按正确顺序协作。

一条请求进入系统后，通常先被限流拦一圈，再判断超时是否还够用，接着检查熔断是否打开，最后才真正发给后端。如果失败，再根据重试预算决定要不要重试。这四个动作可以用错误预算统一度量：假设可用性目标是 99.9%，那么一个周期内最多允许 0.1% 的请求失败。只要失败没有超过预算，就可以继续重试；一旦预算消耗过快，就要主动降级。

最佳实践还包括故障注入：定期故意让某个服务变慢或返回错误，验证整套治理机制是否真的有效；同时依赖可观测性，让调度小哥的每一个动作都有日志、指标和链路追踪。四件套只有经过演练，才敢在大促时真正信任。

Fallowed=Rtotal×(1−Sgoal)\displaystyle F_{allowed} = R_{total} \times (1 - S_{goal})
错误预算：允许失败的请求数 = 总请求数 ×（1 - 可用性目标）。
  1. R_total 表示周期内总请求数例如一天有 100 万次请求。
    Rtotal\displaystyle R_{total}
  2. S_goal 表示可用性目标例如 99.9%，代表系统在大多数时间都能正常服务。
    Sgoal\displaystyle S_{goal}
  3. 1 - S_goal 表示可容忍的失败比例999 次成功里最多允许 1 次失败。
    1−Sgoal\displaystyle 1 - S_{goal}
  4. F_allowed 表示允许失败的最大请求数错误预算耗尽前你可以放心重试，耗尽后必须停止“折腾”。
    Fallowed=Rtotal×(1−Sgoal)\displaystyle F_{allowed} = R_{total} \times (1 - S_{goal})

实战案例

以电商支付链路为例：用户点击“付款”后，请求要经过订单服务、支付服务、账务服务三个档口。如果账务服务是后厨里最脆弱的环节，调度小哥会在账务服务门口设置熔断和限流；用户发起支付时，网关先限流削峰，请求带上全链路 3 秒超时预算。账务服务连续失败时，熔断器打开，支付请求快速返回“系统繁忙，请稍后再试”，而不是让用户在转圈页面里等待。

为什么支付链路最怕“无限重试”？因为每一环的可用性会相乘。假设三个服务的可用性分别是 0.99、0.999、0.99，整条链路的可用性远低于任何单点。计算公式是：

另一个经典案例是购物车削峰：大促开始时流量暴增，网关通过令牌桶限制每秒进入购物车服务的请求数；如果下游库存服务过载，熔断器打开，前端直接展示“降级提示”而不是报错。等到峰值过去，熔断器半开探测成功后，流量自动恢复。美食广场也许很忙，但有了这套机制，总能保证每一单都有交代。

Achain=Aorder×Apayment×Aledger\displaystyle A_{chain} = A_{order} \times A_{payment} \times A_{ledger}
链路上每个服务的可用性相乘，链路越长，整体可用性越低。
  1. A_order 表示订单服务的可用性订单服务有 99% 的时间能正常工作。
    Aorder\displaystyle A_{order}
  2. A_payment 表示支付服务的可用性支付通道通常较强，例如 99.9%。
    Apayment\displaystyle A_{payment}
  3. A_ledger 表示账务服务的可用性账务系统最容易成为瓶颈，也需要重点保护。
    Aledger\displaystyle A_{ledger}
  4. 整体可用性等于三者乘积任何一个环节出问题，整笔支付都会失败，所以必须给关键环节配置熔断、限流、重试和超时。
    Achain=Aorder×Apayment×Aledger\displaystyle A_{chain} = A_{order} \times A_{payment} \times A_{ledger}

AI 应用场景

大模型 API 网关限流保护

阶段：模型部署与在线推理

解决的问题：大模型推理服务对 GPU 资源敏感，突发流量会让算力耗尽、排队暴涨。传统方式靠不断扩容，成本高且反应慢；在 Service Mesh 中通过令牌桶做网关限流，可以稳定控制进入推理服务的并发量，保护 GPU 集群。

具体案例：某 AI 绘画平台在大促活动上线前，在 Sidecar 层配置了“每秒 200 个请求、桶容量 50”的限流规则。活动峰值到来时，超出阈值的请求被快速排队或降级为“排队中”，GPU 集群始终没有被打垮，付费用户请求优先通过。

RAG 多模型编排的超时与重试

阶段：RAG 检索增强生成

解决的问题：一条 RAG 请求要依次调用 Embedding 模型、向量数据库、大模型生成服务。任何一个环节慢或失败，用户都会感受到卡顿；但无脑重试可能造成重复计算。通过在 Service Mesh 中设置全链路超时预算，并只对幂等的 Embedding 请求做指数退避重试，可以显著提升整体成功率。

具体案例：某智能客服系统采用 RAG 架构，原本高峰时段 20% 请求超时。接入 Mesh 后，给每条对话请求分配 5 秒超时预算；Embedding 调用失败时最多重试 2 次，且使用请求唯一 ID 去重；大模型服务连续返回 503 时熔断 3 秒。最终超时率降至 3% 左右。

推理服务故障注入演练

阶段：稳定性演练与混沌工程

解决的问题：AI 服务上线前很难准确评估“某个模型挂了”会带来什么影响。传统压测无法模拟细粒度故障；Service Mesh 可以按百分比注入延迟和错误，验证熔断、限流、超时策略是否真的生效。

具体案例：某自动驾驶数据平台对大模型推理服务注入 5% 的 500 错误，观察熔断器能否在失败率达到阈值后自动打开，并验证备用小模型是否接管。演练过程中通过错误预算监控发现重试次数过高，于是调低了重试上限，避免了故障放大。

Python 演示

python103 行
import timeimport random  class TokenBucket:    def __init__(self, capacity, refill_per_sec):        self.capacity = capacity        self.refill_per_sec = refill_per_sec        self.tokens = capacity        self.last = time.time()     def allow(self):        now = time.time()        self.tokens = min(self.capacity, self.tokens + (now - self.last) * self.refill_per_sec)        self.last = now        if self.tokens >= 1:            self.tokens -= 1            return True        return False  class CircuitBreaker:    def __init__(self, failure_threshold, min_requests, recovery_time):        self.failure_threshold = failure_threshold        self.min_requests = min_requests        self.recovery_time = recovery_time        self.open_until = 0.0        self.results = []     def allow(self):        if time.time() < self.open_until:            return False        if len(self.results) >= self.min_requests:            fail_sum = sum(0 if r else 1 for r in self.results)            if fail_sum / len(self.results) >= self.failure_threshold:                self.open_until = time.time() + self.recovery_time                return False        return True     def record(self, ok):        self.results.append(ok)        if len(self.results) > 20:            self.results.pop(0)  class FakeLLMBackend:    def __init__(self, fail_rate=0.35, latency=0.01):        self.fail_rate = fail_rate        self.latency = latency     def call(self):        time.sleep(self.latency)        if random.random() < self.fail_rate:            raise ConnectionError("503 model overloaded")        return "ok"  class ResilientClient:    def __init__(self, backend, bucket, circuit, timeout, max_retries, base_delay, max_delay, jitter):        self.backend = backend        self.bucket = bucket        self.circuit = circuit        self.timeout = timeout        self.max_retries = max_retries        self.base_delay = base_delay        self.max_delay = max_delay        self.jitter = jitter     def call(self):        deadline = time.time() + self.timeout        attempts = 0        while time.time() < deadline:            if not self.bucket.allow():                return "rate_limited"            if not self.circuit.allow():                return "circuit_open"            try:                result = self.backend.call()                self.circuit.record(True)                return result            except ConnectionError:                self.circuit.record(False)                attempts += 1                if attempts > self.max_retries:                    return "failed"                wait = min(self.max_delay, self.base_delay * (2 ** (attempts - 1)))                wait = min(wait + random.uniform(0, self.jitter), max(0.0, deadline - time.time()))                time.sleep(wait)        return "timeout"  def main():    bucket = TokenBucket(capacity=5, refill_per_sec=2)    circuit = CircuitBreaker(failure_threshold=0.5, min_requests=5, recovery_time=0.2)    backend = FakeLLMBackend(fail_rate=0.4, latency=0.005)    client = ResilientClient(backend, bucket, circuit, timeout=0.5, max_retries=3,                             base_delay=0.01, max_delay=0.04, jitter=0.02)    for i in range(30):        print(i, client.call())  if __name__ == "__main__":    main()
目的：模拟一个调用大模型推理服务的客户端，综合使用令牌桶限流、熔断、超时预算和指数退避重试，直观展示四种治理手段如何协作。
  1. self.tokens = min(self.capacity, self.tokens + (now - self.last) * self.refill_per_sec)按时间补充令牌，但不能超过桶容量。
  2. if self.tokens >= 1:有令牌才放行，体现限流判断。
  3. if len(self.results) >= self.min_requests:滑动窗口内积累足够样本后才计算失败率。
  4. fail_sum / len(self.results) >= self.failure_threshold失败率超过阈值时准备打开熔断器。
  5. self.open_until = time.time() + self.recovery_time打开熔断后进入恢复倒计时。
  6. deadline = time.time() + self.timeout给整个调用链设置超时预算。
  7. while time.time() < deadline:每次循环都检查是否已经超时。
  8. if not self.circuit.allow(): return "circuit_open"熔断打开时快速失败，不再访问后端。
  9. wait = min(self.max_delay, self.base_delay * (2 ** (attempts - 1)))指数退避计算重试等待时间。
  10. time.sleep(wait)真正等待一段时间后再进入下一次重试。

常见误区

误区很多初学者认为“服务变慢了就限流，限不住就熔断，熔断和超时差不多”，把三种机制混为一谈。

正解限流是控制“进入”系统的流量，比如门口取号；熔断是当下游已经出问题时“快速失败”不再送单；超时是给每次调用限定等待时间。三者对象不同：限流保上游不出乱子，熔断保下游不被压垮，超时保调用方不被拖死。

为何常见：因为它们都在请求入口处起作用，而且经常同时配置，初学者容易只看到“请求被拒绝了”这一表象，忽略各自要解决的问题。

误区有人觉得“失败 3 次就再试 10 次，总能成功”，于是把重试次数调到很大，甚至无限重试。

正解重试会放大流量。当后端已经过载时，大量重试等于往火上浇油。正确做法是指数退避加随机抖动，同时设置最大重试次数、重试预算和幂等键。重试只适合“偶发瞬时失败”，不适合“系统已崩溃”的情况。

为何常见：日常开发中，手动点一下“重新加载”往往就成功了，让人误以为重试无害；但分布式系统的流量放大效应远比单机场景严重。

误区很多开发者怕慢请求被误杀，把超时时间设置成 10 秒甚至 30 秒，认为“多等等总能成功”。

正解超时越长，线程、连接、内存被占用的时间就越长。一个服务如果有 1000 个并发线程，每个请求等 30 秒，那它最多只能同时处理 1000 个慢请求，正常请求全部被堵死。正确方式是用全链路超时预算，给每个环节分配明确额度，并预留安全缓冲。

为何常见：从单个请求的视角看，等待似乎是安全的；但从系统整体看，等待的代价是资源被持续占用。这种“只见树木不见森林”的思维最容易踩坑。

误区有人以为给服务加上 Sidecar 后，熔断、限流、重试、超时就自动生效了，不需要额外配置。

正解Service Mesh 只是提供了“可以治理”的基础设施，真正生效需要控制面下发策略，例如熔断阈值、限流速率、超时预算、重试次数。没有配置的 Sidecar 只是一个透明代理，不会主动救你。

为何常见：Service Mesh 的“自动注入”特性容易让人误解为“全自动治理”，实际上它把能力从“代码里写死”变成了“配置中心下发”，治理规则依然需要人来定义。

面试题

Q1. Service Mesh 的数据面由什么组成？

单选题 · easy

  • A.业务代码中的工具类
  • B.每个服务旁边的 Sidecar 代理← 正确答案
  • C.独立部署的数据库集群
  • D.前端页面中的 JS 脚本

答案：B。数据面是靠近业务服务的 Sidecar 代理集合，负责拦截和转发流量。控制面才负责下发规则，“数据库集群”和“JS 脚本”都不属于 Service Mesh 的数据面。

Q2. 熔断器从打开状态恢复到关闭状态，通常先经过？

单选题 · easy

  • A.全量放行所有
  • B.半开探测模式← 正确答案
  • C.直接重启服务
  • D.永久关闭熔断

答案：B。熔断器打开后不会直接恢复，而是先进入半开状态，放少量探测请求。如果探测成功再逐步关闭熔断器；全量放行和永久关闭都不符合标准的熔断状态机。

Q3. 令牌桶中的容量 C 主要控制什么？

单选题 · easy

  • A.请求平均速率大小
  • B.瞬时突发流量上限← 正确答案
  • C.后端最大并发数
  • D.每次重试等待时长

答案：B。令牌桶以固定速率加令牌，而桶容量 C 决定了最多能积累多少令牌，也就决定了允许的突发流量上限。平均速率由加令牌速率 r 控制，与容量 C 无关。

Q4. 指数退避重试的最大目的是？

单选题 · mid

  • A.让重试越来越频繁
  • B.让重试越来越稀疏← 正确答案
  • C.让请求全部并发发出
  • D.让超时时间逐渐减小

答案：B。指数退避让每次重试的等待时间按 2 的幂次增长，重试越来越稀疏，避免集中重试压垮后端。它并不会让重试更频繁，也不影响超时时间。

Q5. 全链路超时预算中，每个下游应分配？

单选题 · mid

  • A.全部剩余时间
  • B.剩余时间减缓冲← 正确答案
  • C.固定的一秒钟
  • D.与上游相同时间

答案：B。下游调用必须使用“剩余预算 - 安全缓冲”，不能把全部剩余时间花完，否则没有时间处理突发状况。固定时间或与上游相同都不科学。

Q6. Service Mesh 控制面的核心职责是？

单选题 · hard

  • A.转发每个业务请求
  • B.下发规则与配置管理← 正确答案
  • C.存储业务交易数据
  • D.渲染前端页面视图

答案：B。控制面负责管理 Sidecar、下发路由、熔断、限流等规则，不直接转发业务请求。转发是数据面的职责，存储数据和渲染页面则与服务治理无关。

Q7. 错误预算为 1% 时，一个周期内有 100 万请求，最多允许失败？

单选题 · hard

  • A.10 万次
  • B.1 万次← 正确答案
  • C.1000 次
  • D.100 次

答案：B。错误预算 = 总请求数 ×（1 - 可用性目标），即 1000000 × 1% = 10000 次。只有在错误预算内，重试和发布才是安全的；超过预算就要停止试验或降级。

Q8. 哪些措施可以降低重试带来的风险？

多选题 · mid

  • A.增加随机抖动← 正确答案
  • B.设置重试上限← 正确答案
  • C.保证接口幂等← 正确答案
  • D.取消所有超时

答案：ABC。随机抖动避免重试同步，重试上限防止无限放大流量，幂等保证重复请求不产生重复扣款或重复下单。取消超时会让系统被慢请求拖垮，属于错误做法。

Q9. 关于熔断和限流的区别，说法正确的是？

多选题 · mid

  • A.限流是控制入口流量← 正确答案
  • B.熔断是保护下游不稳← 正确答案
  • C.二者通常可以共存← 正确答案
  • D.熔断可以提升后端吞吐量

答案：ABC。限流在入口处控制请求速率，熔断在下游故障时快速失败，二者是不同维度但经常配合使用。熔断的作用是防止故障扩散，并非直接提升吞吐量。

Q10. 支付链路 A→B→C 的可用性分别是 0.99、0.999、0.99，正确的是？

多选题 · extreme

  • A.链路可用性约为 0.979← 正确答案
  • B.链路可用性约为 0.989
  • C.幂等重试能提升最终成功率← 正确答案
  • D.任一处熔断会使请求快速失败← 正确答案

答案：ACD。链路可用性等于 0.99 × 0.999 × 0.99 ≈ 0.979，因此 A 正确、B 错误。幂等重试可以抵消瞬时故障，提升最终成功率；熔断器打开时请求会快速失败而不会继续等待。