架构 · XB 现场笔记

优雅降级保留部分价值

Thu, 22 Apr 2027 00:00:00 +0000

优雅降级是在服务某一部分失效时，继续提供事先明确支持的功能子集。例如，文章页面可以暂时省略推荐区域，同时仍然显示用户请求的正文。关键是这种部分答案必须符合产品契约，既有用又如实说明限制。返回一点内容，并不天然比明确失败更安全；如果剩余内容会误导用户，就不能仅为了保持成功状态码而继续提供它。

先决定哪些东西可以缺少

编写回退代码之前，应分清可选区域和必须满足的结果。侧栏推荐消失可能可以接受，但默默跳过权限检查、把结果未确认的支付说成成功，或用未经验证的价格替代当前报价，都可能破坏核心承诺。这些情况需要明确失败或另行批准的处理流程，不能套用一个“页面总要保持绿色”的统一开关。降级范围应来自业务语义，而不是依赖清单上哪个接口最容易被捕获异常。

可选依赖应尽可能避免占住核心响应的关键路径。它的调用需要有界预算，但调用方等待超时，不代表底层工作已经停止。还应限制并发和排队，避免大量已经失去价值的任务继续占用线程或连接。占位说明应告诉用户缺少什么能力，同时避免暴露内部错误细节，也不能暗示已经取得当前数据。核心页面能否正常工作，应在强制关闭可选区域时单独检查。

把陈旧数据的可接受条件写清楚

最后一次良好数据只在明确范围与年龄政策内有用。需要记录数据取得时间，保留所属对象和授权范围，并规定年龄未知、超过限制或缓存为空时如何处理。一个时间戳本身不能证明数据正确：某些状态发生变化后，即使缓存只有很短时间，也不能继续用于作出授权或交易决定。因此，是否可以复用，是契约问题，不是看到缓存还有内容就可以决定。

上游失败后提供旧数据，与 stale-while-revalidate 并不相同，后者可以在发起验证的同时提供符合条件的陈旧响应。两者都需要有界的新鲜度与资源政策。成功刷新时，也必须真正替换缓存内容并重置年龄；否则系统可能不断声称提供“最近一次成功结果”，实际却永远返回更早的那份快照。显示年龄有助于观察，但不能代替这些状态更新与过期判断。

坏掉的样子

回退可能扩大事故。AWS 关于避免回退的文章描述了缓存故障后流量直接涌向数据库，最终超出数据库承受能力的事件。这份来源是在警告难以测试、很少运行的备用路径，并不是无条件支持“有部分答案就一定更好”。应该优先改善可预测的主要路径，并经常演练恢复行为，而不是把希望寄托在资源需求不明、只有事故时才启用的复杂分支上。

缓存同时到期、所有节点同时试探恢复，都可能制造突发负载。需要分散刷新工作，限制重试与并发，并检查备用路径是否还在争用已经耗尽的同一资源。熔断器决定是否继续调用依赖，降级政策决定剩下的答案是否可以接受。这是两个不同问题：熔断器打开，并不能证明缓存仍然有效，也不能证明某个静态占位符合业务承诺。

恢复探测失败后，普通请求准入必须继续关闭。如果还没验证恢复就先闭合熔断器，流量可能过早回到故障依赖。生产实现还需要同步、探测调度和有界恢复并发，串行示例不能验证这些性质。降级响应也应有独立计数与数据年龄观测，避免 HTTP 200 掩盖持续的功能缺失；是否需要告警，还要结合影响范围、持续时间和实际可采取的动作。

快速验证

保存为 degrade_probe.py，执行 python3 degrade_probe.py。这个标准库样本只模拟一个可选推荐区域，不执行网络或文件系统操作。缓存年龄和依赖失败都是显式注入的输入，一百二十秒上限只是示范性的产品决定。探测由程序明确、同步地调用，没有实现自动计时器或并发请求准入，因此也不声称能够协调多个进程的半开请求。

class DependencyDown(Exception):
 pass

class PageService:
 def __init__(self):
 self.cached_recs = ["cached-pick"]
 self.cached_age_s = 90 # Injected age, not a running clock.
 self.max_age_s = 120
 self.failures, self.threshold = 0, 3
 self.open = False
 self.live_calls = 0

 def live_recs(self, fail):
 self.live_calls += 1
 if fail:
 raise DependencyDown("recs down")
 return ["fresh-pick"]

 def fresh(self, data):
 self.cached_recs, self.cached_age_s = list(data), 0
 self.failures, self.open = 0, False
 return {"mode": "fresh", "data": data}

 def fallback(self, reason):
 if self.cached_recs and 0 <= self.cached_age_s <= self.max_age_s:
 return {"mode": "cached", "data": list(self.cached_recs),
 "age_s": self.cached_age_s, "reason": reason}
 return {"mode": "simplified", "data": ["popular-picks"], "reason": reason}

 def get_recs(self, fail=False):
 if self.open:
 return self.fallback("breaker-open")
 try:
 return self.fresh(self.live_recs(fail))
 except DependencyDown:
 self.failures += 1
 self.open = self.failures >= self.threshold
 return self.fallback("dependency-failed")

 def half_open_probe(self, fail=False):
 # Explicit synchronous trial; not a concurrent admission controller.
 assert self.open, "probe requires an open breaker"
 try:
 data = self.live_recs(fail)
 except DependencyDown:
 return self.fallback("probe-failed") # Leave the breaker open.
 return self.fresh(data) # Close only after success.

svc = PageService()
assert svc.get_recs() == {"mode": "fresh", "data": ["fresh-pick"]}
assert svc.cached_recs == ["fresh-pick"] and svc.cached_age_s == 0
svc.cached_age_s = 120
cached = svc.get_recs(fail=True)
assert cached["mode"] == "cached" and cached["age_s"] == 120
assert cached["data"] == ["fresh-pick"]
svc.cached_age_s = 121
assert svc.get_recs(fail=True)["mode"] == "simplified"
svc.get_recs(fail=True)
assert svc.open
calls = svc.live_calls
assert svc.get_recs()["reason"] == "breaker-open" and svc.live_calls == calls
assert svc.half_open_probe(fail=True)["reason"] == "probe-failed"
assert svc.open and svc.live_calls == calls + 1
calls = svc.live_calls
svc.get_recs()
assert svc.live_calls == calls # A failed probe must not reopen normal admission.
assert svc.half_open_probe()["mode"] == "fresh" and not svc.open
assert svc.cached_age_s == 0
svc.cached_recs = []
assert svc.get_recs(fail=True)["mode"] == "simplified"
svc.cached_recs, svc.cached_age_s = ["unknown-age"], -1
assert svc.get_recs(fail=True)["mode"] == "simplified"
print("PASS: fresh refresh, bounded cache, empty/invalid cache, open gate, failed/successful probe")

成功调用会刷新缓存。接下来依赖失败时，如果注入年龄恰好为一百二十秒，回退返回的确实是刚才取得的最新成功值；改为一百二十一秒，就选择明确简化的答案。连续三次失败使调用闸口打开，下一次普通请求继续得到回退，但实际调用计数不增加。这里验证的是旧数据仍然符合约定，而不仅仅是旧数据仍然存在。

失败探测只执行一次真实的模拟调用，并保持熔断器打开；随后普通请求依然不能增加调用数。成功探测才会关闭闸口并刷新缓存。独立的空缓存和负年龄对照也都选择简化响应。最后的 PASS 只覆盖这些确定性状态选择，没有测量真实服务的可用性，也没有证明其他机器会在同一时刻看到相同的恢复结果。

部署前，应在受控负载下对真实依赖故障和恢复验证已选择的契约，并分别检查截止时间、取消、授权范围、缓存年龄计算和可见的降级指标。示例中的静态推荐回退有意保持廉价，不需要访问另一个系统。它不能证明一个备用远程服务在相关性故障中仍然健康，更不能用来替代真实恢复并发与资源争用的验收。

来源

AWS Builders’ Library：避免在分布式系统中回退，不常执行的回退路径与事故放大风险，已核验 2026-10-15。
Google SRE：优雅降级，丢负载以保住有用部分，已核验 2026-10-15。
Martin Fowler：熔断器，打开状态下拒绝调用，以及受控恢复探测，已核验 2026-10-15。

熔断器阻止对故障服务的轰炸

Tue, 06 Apr 2027 00:00:00 +0000

熔断器决定的是一个新的调用，是否还应该到达看起来不健康的依赖。它可以立即拒绝，避免继续为很可能失败的请求投入资源，但不会修复依赖、取消已经运行的调用，也不能证明所有被拒工作本来都会失败。它是否有用，取决于真正实现的失败信号、作用域和恢复政策，而不只是有没有三个状态名称。

明确政策，而不只是画出状态

关闭表示允许调用通过，不代表每次调用都会成功；断开表示按照熔断政策拒绝新调用；半开则允许有限的试探工作，先取得一些恢复证据，再决定是否重新放行普通流量。不能把状态名字直接读成依赖的客观健康证明。

检测规则也不一定是滑动窗口内的失败百分比。Fowler 的示例统计失败，并在成功后重置；其他实现可能使用时间窗口、失败比例、慢调用阈值或最小样本数。应该明确当前使用的规则，而不是借用一张状态图，就默认阈值和统计方法已经确定。

下面的实验按完成顺序统计连续两次已分类失败，使用五秒冷却期，并且只允许一个半开探测。一次成功会把连续失败数清零。这些数字方便验证状态转移，不是生产配置建议；实际门槛需要结合故障形态与业务容忍度决定。

分类失败，并限定影响范围

调用方参数错误，不一定表示依赖已经宕机。需要确定哪些异常、状态码和慢结果应该影响熔断判断。本地直接拒绝的请求，也不同于已经到达依赖后失败的请求；如果把二者混在同一个失败统计里，熔断器可能不断用自己的拒绝强化拒绝状态。

状态应覆盖你真正想保护的故障范围。某个分片或操作不可用，不一定意味着其他独立提供方也应该被阻止。反过来，如果有成千上万个进程各自维护熔断器，每个都允许一个探测，总探测量仍可能很大。“只放一个半开请求”可能只是每实例一个，不是全局一个。

超时仍然不可缺少。一个永远不结束的调用，会占住连接或工作线程，却可能始终不产生足以触发熔断的完成结果。准入决定不能替代截止期限、并发上限和资源清理；等待结果所消耗的资源，也应进入实际验收范围。

恢复是一场受控试探

冷却时间结束后，应原子地占用探测名额。如果多个线程都先看见“现在可以试一下”，然后各自放行，所谓单探测就变成了一批突发请求。实验使用锁保护很短的状态修改，不会在依赖操作实际运行期间一直持有这把锁。

已经在途的旧调用，其结果如何处理也需要明确。这里进入新的断开阶段时会增加本地代次，旧许可对应的结果不能关闭这个较新的断开状态。代次只是模型内部的记账，不是分布式 fencing token，也没有能力撤销已经发生的远程工作。

探测失败会开始另一轮冷却，探测成功则关闭这个实验里的熔断器。但是，一次成功不证明依赖已经能够承接所有返回流量。如果需要逐步恢复，应该验证真实的流量准入政策，而不是认为只要存在“半开”状态，就必然实现了平滑放量。

坏掉的样子

阈值过于激进，会拒绝原本可以成功的请求；冷却过长，又会在依赖恢复后继续阻止调用。范围过大容易掩盖局部健康，而重试循环如果不停捕获断开异常，即使没有继续请求下游，也仍可能浪费本地资源，使故障路径消耗超出预期。

应分别观察转发调用、已分类结果、本地拒绝、状态变化和探测结果。测试持续失败、偶尔成功、并发争抢探测以及迟到的完成消息。一个计数器单测通过，并不证明真实依赖会安全恢复；需要沿着请求、资源占用和实际恢复流量继续检查。

快速验证

保存为 breaker_check.py，用 Python 3.10 以上版本执行 python3 breaker_check.py。实验已在 Python 3.14.4 上运行，只使用标准库。代码模拟结果，并注入表示单调时间的数值，不真实等待，也不访问服务；半开名额则由八个真实线程竞争，检查准入决定是否一起完成。

from concurrent.futures import ThreadPoolExecutor
from threading import Barrier, Lock


class OpenCircuit(Exception):
 pass


class Breaker:
 # Explicit fixture policy: two consecutive classified failures, five-second cooldown.
 def __init__(self):
 self.state, self.failures, self.until = "closed", 0, 0
 self.epoch, self.probe_busy = 0, False
 self.lock = Lock()

 def acquire(self, now):
 with self.lock:
 if self.state == "open":
 if now < self.until:
 raise OpenCircuit
 self.state = "half-open"
 if self.state == "half-open":
 if self.probe_busy:
 raise OpenCircuit
 self.probe_busy = True
 return self.epoch, True
 return self.epoch, False

 def complete(self, permit, succeeded, now):
 epoch, probe = permit
 with self.lock:
 if epoch != self.epoch:
 return # This outcome belongs to an earlier breaker generation.
 if probe:
 self.probe_busy = False
 self.epoch += 1
 self.failures = 0
 self.state = "closed" if succeeded else "open"
 if not succeeded:
 self.until = now + 5
 elif self.state == "closed":
 self.failures = 0 if succeeded else self.failures + 1
 if self.failures >= 2:
 self.state, self.until = "open", now + 5
 self.epoch += 1


breaker = Breaker()
other_dependency = Breaker()
forwarded = []


def invoke(succeeded, now):
 permit = breaker.acquire(now)
 forwarded.append(now) # A modeled dependency invocation, not a network call.
 breaker.complete(permit, succeeded, now)


invoke(False, 0)
assert breaker.failures == 1
invoke(True, 1)
assert breaker.failures == 0
late = breaker.acquire(1)
invoke(False, 2)
invoke(False, 3)
assert breaker.state == "open" and breaker.until == 8
other_permit = other_dependency.acquire(4)
other_dependency.complete(other_permit, True, 4)
assert other_dependency.state == "closed"
before = len(forwarded)
try:
 invoke(True, 7.99)
except OpenCircuit:
 pass
else:
 raise AssertionError("open circuit must reject before dispatch")
assert len(forwarded) == before
breaker.complete(late, True, 7.99)
assert breaker.state == "open"
print("success resets consecutive failures; two later failures open until time 8")
print("open calls are not dispatched; an older in-flight success does not close a newer open generation")

gate = Barrier(8)


def probe_attempt(_):
 gate.wait(timeout=5)
 try:
 return breaker.acquire(8)
 except OpenCircuit:
 return None


with ThreadPoolExecutor(max_workers=8) as pool:
 permits = list(pool.map(probe_attempt, range(8)))
admitted = [permit for permit in permits if permit is not None]
assert len(admitted) == 1 and admitted[0][1] is True
assert breaker.state == "half-open" and breaker.probe_busy
breaker.complete(admitted[0], False, 8)
assert breaker.state == "open" and breaker.until == 13
print("eight simultaneous half-open candidates receive one probe permit and seven refusals")
print("failed probe opens a new cooldown ending at time 13")

try:
 breaker.acquire(12.99)
except OpenCircuit:
 pass
else:
 raise AssertionError("second cooldown must still apply")
probe = breaker.acquire(13)
breaker.complete(probe, True, 13)
assert breaker.state == "closed" and not breaker.probe_busy
invoke(True, 14)
assert other_dependency.state == "closed" and other_dependency.failures == 0
print("a successful later probe closes this breaker; another dependency has separate state")

开始时的一次成功会清零失败数；后面两次失败让熔断器断开到时间八。在这之前发起调用，不会增加模拟下游调用记录。先前获准、后来才完成的成功结果，也不能关闭新一代的断开状态；另一依赖早已存在的熔断器仍然可以使用，没有被一并影响。

到时间八，八个同时到来的候选请求中只有一个获得许可，其余七个被拒绝。这个探测失败后，又开始一轮到时间十三结束的冷却。之后的探测成功，会让当前熔断器关闭，并恢复普通调用准入。断言检查的是这些明确的状态和许可变化。

模型要求每个获准调用都恰好报告一次已经分类的完成结果。真实传输超时、取消、自动错误分类、跨进程探测协调、库集成和恢复吞吐量没有在本例中测试。适合时应复用成熟实现，并依据实际工作负载验证它的精确契约，而不是将这个小模型当作完整生产熔断库。

来源

Martin Fowler：熔断器，失败计数、成功重置与试探恢复，已核验 2026-09-08。
Azure 架构：熔断器，状态语义、异常分类、并发与故障范围，已核验 2026-09-08。
Python 线程工具，并发许可实验使用的锁与同步屏障，已核验 2026-09-08。

对象与块存储提供不同的更新契约

Wed, 17 Mar 2027 00:00:00 +0000

块存储通过设备接口暴露可寻址的数据块，对象存储通过接口暴露带名字的对象。仅凭这两个分类，不能决定耐久性、一致性、共享能力或价格。应先列出应用真正需要执行的操作，再核对具体服务的契约。文件系统、数据库和兼容层可以增加行为，但不能让所有底层接口自动变得可互换；一个路径能够被打开，并不证明它符合应用的恢复要求。

比较实际支持的操作

块卷可以先格式化为文件系统，也可以由软件直接管理数据布局。块服务并不一定预装文件系统。应用可以进行小范围覆盖而不必替换整块卷，但共享访问仍然需要协调。把一个卷同时连接到多台机器，不会让普通单机文件系统自动变成集群文件系统。数据库能否恢复，还依赖块接口之上的写入顺序、同步和持久性约定，不能把能够写入等同于断电以后仍然正确。

对象通过桶或其他服务定义的命名空间寻址。普通 S3 通用桶写入会替换整个对象；读取却可以指定字节范围，所以“对象存储每次必须读完整个对象”并不正确。分段上传把多个部分组装成一个完成的对象，不等于通用文件系统的随机写契约。特殊产品还可能提供追加或其他更新能力，因此必须核对选中的桶类型与接口，不能把下面的小模型当成所有产品永远不变的规则。

对象存储通常适合媒体、导出结果和备份文件，让许多客户端按需读取。块存储通常适合数据库文件与虚拟机磁盘。但这只是常见工作负载，并不是互斥分类：数据库可以专门围绕对象接口设计，共享文件系统也可以建立在块设备之上。选择之前应测量请求大小、并发量、恢复过程，以及请求与数据传输的完整成本，不能只比较每月每单位容量的标价。

坏掉的样子

不要默认对象存储采用最终一致性。Amazon S3 对对象写入、删除及对应读取和列举提供强一致性。客户端手里保留旧下载结果，仍然可能看见旧内容，但这不能证明重新向服务读取也会得到旧值。分发缓存、跨区域复制和跨多个对象的业务更新又是不同边界，必须各自检查保证。把这些现象都叫作“对象存储有一致性窗口”，会让排查方向从一开始就偏离事实。

成功的 S3 PUT 不会暴露半个上传对象。请求失败或结果不明时，应确认实际状态，不能直接推断新版本被截断。单个对象的原子替换也无法防止丢失更新：两个客户端可能读取同一旧值，再分别覆盖它。条件请求可以在接受更新之前比较校验标识，但要遵循服务文档中的条件语义。ETag 并不总是内容校验和，更不是把多个键包进同一个事务的承诺。

生命周期删除与历史版本保留应通过真实恢复演练检验。打开版本控制不等于已经有独立备份，在程序里记一个版本数字，也不等于保存了所有旧载荷。大量小对象即使占用字节不多，请求开销仍可能主导成本。兼容挂载层能够接受数据库文件名，同样需要证明它满足锁、写入顺序与失败恢复语义，才能作为合适的数据库存放位置。

快速验证

保存为 storage_semantics.py，用 Python 3.9 或更新版本执行 python3 storage_semantics.py。这是使用虚构字节的独立内存模型，不访问服务，不测文件系统持久性，也不涉及网络延迟与计费。它只把明确写进类定义的规则变成可检查的操作，方便分辨几种常被混淆的保证。

"""In-memory API model, not an implementation of a storage service."""
class BlockVolume:
 def __init__(self, data):
 self.data = bytearray(data)
 def write(self, offset, chunk):
 if offset < 0 or offset + len(chunk) > len(self.data):
 raise ValueError("write outside fixed volume")
 self.data[offset:offset + len(chunk)] = chunk

class ObjectStore:
 def __init__(self):
 self.current = {}
 def put(self, key, data, expected=None):
 old = self.current.get(key)
 version = old[1] if old else 0
 if expected is not None and expected != version:
 raise ValueError("version conflict")
 self.current[key] = (bytes(data), version + 1)
 return version + 1
 def get(self, key):
 return self.current[key]

block = BlockVolume(b"ABCDEF")
block.write(2, b"XX")
assert block.data == b"ABXXEF"
try:
 block.write(5, b"too long")
except ValueError:
 pass
else:
 raise AssertionError("out-of-range write accepted")
assert block.data == b"ABXXEF"
store = ObjectStore()
assert store.put("report", b"ABCDEF", expected=0) == 1
cached = store.get("report")
assert store.put("report", b"XYZ", expected=1) == 2
assert store.get("report") == (b"XYZ", 2)
assert cached == (b"ABCDEF", 1)
try:
 store.put("report", b"stale overwrite", expected=cached[1])
except ValueError:
 pass
else:
 raise AssertionError("stale conditional update accepted")
assert store.get("report") == (b"XYZ", 2)
assert store.get("report")[0][1:3] == b"YZ"
print("PASS: bounded overwrite; complete replacement; cached copy differs; stale condition rejected")

块模型最初有六字节，覆盖中间两字节后，相邻内容保持不变。越界写入被拒绝，原数据没有因此变化。对象模型从第一版的六字节内容，整体替换成第二版的三字节内容；新的读取立即得到替换结果。另一个事先保存的元组仍然包含第一版，因为应用保留了自己的旧副本。这是本地缓存陈旧，不是服务读取出现最终一致性延迟。

使用旧版本发起的条件覆盖失败，最后的断言确认当前对象仍然完整不变。对已经取回的字节做切片，只演示选择一个范围，不是对真实 HTTP Range 请求的测试。末尾 PASS 证明的是这些显式模型规则，不证明厂商实现、跨客户端并发、历史载荷保留、崩溃原子性或灾难恢复。正式使用之前，还应通过所选服务的真实客户端，验证相关操作及失败处理流程，明确哪些结论来自模型，哪些来自系统本身。

来源

Amazon S3 data model，对象操作与强一致性，已核验 2026-10-15。
S3 PutObject，完整对象写入与条件请求，已核验 2026-10-15。
Amazon EBS，块卷与应用管理的文件系统，已核验 2026-10-15。

架构 · XB 现场笔记

优雅降级保留部分价值

先决定哪些东西可以缺少

把陈旧数据的可接受条件写清楚

坏掉的样子

快速验证

延伸阅读

来源

熔断器阻止对故障服务的轰炸

明确政策，而不只是画出状态

分类失败，并限定影响范围

恢复是一场受控试探

坏掉的样子

快速验证

延伸阅读

来源

对象与块存储提供不同的更新契约

比较实际支持的操作

坏掉的样子

快速验证

来源