知识卡片
独立的速率限制微服务隔离变更冲动
内容
如果发布系统本身就能极快地推送变更，如何防止这个能力被误触发？一种做法是把”允许多快变更”从发布逻辑里剥离出来，做成单一职责、易于严格测试的独立微服务，由它签发短期有效的加密令牌来批准每次变更节奏的调整。这个额外依赖看似增加了发布链路的复杂度，但换来一个清晰信号——想绕开限速就必须绕开这个独立服务，这本身会被视为不安全操作而被劝阻，从架构层面降低工程师图省事跳过限速检查的可能性。
参考来源
- 位置：《Google系统架构解密：构建安全可靠的系统》第9章《面向恢复性的设计》9.2.1节隔离速率限制机制（源文件：`../OREILY动物书合辑 图灵新版/_epub-src/text/part0014_split_080.html`）
- 结论依据：原文提出将速率限制机制构建为独立的、用途单一的微服务，可提供短暂加密令牌代表审阅并批准某次更改，并说明这种明确分离能"劝服工程师不要规避速率限制服务"。
- 原始内容：一种策略是将速率限制机制构建为一个独立的、用途单一的微服务……速率限制微服务可能会提供一个短暂的加密令牌，用来代表微服务在某个时间审阅并批准了某个特定的更改……它也能劝服工程师不要规避速率限制服务。