3.3 分布式系统

概述与动机

分布式系统是指其组件运行在多台机器上、并通过网络进行协调的任何系统。一旦你的进程边界跨越了网络，你就继承了一些单个进程内部根本不存在的严酷现实：网络是不可靠的，其延迟也会变化。消息可能丢失、重复、延迟或乱序。远程组件会独立地发生故障。没有共享的时钟。那条经典的”分布式计算的谬误“（网络是可靠的、延迟为零、带宽无限、拓扑结构永不改变）恰恰点名了那些导致服务中断的错误假设。你的工作是从一开始就针对这些现实进行设计，而不是在一次事件中才重新发现它们。

对大型组织而言，分布是不可选的。任何服务于全国或全球规模、需要打通多个部门、或需要高可用性的系统，都会跨越许多台机器、数据中心，往往还有多个地理区域。企业运行着分布式事务系统、事件流水线和多区域部署。政府运行着跨机构集成系统，每个机构都拥有自己的系统，没有任何一方掌控全局。在这样的场景下，健壮设计与脆弱设计之间的差距，会以头条新闻式的服务中断、错发或漏发的福利款项，以及监管后果的形式呈现出来。本章介绍的各项技术（一致性推理、幂等性、带退避的重试、断路器、Saga 模式，以及分布式可观测性）就是你的标准防线。

分布式系统最难的地方在于，其故障是局部的、间歇性的。单机程序要么正常运行，要么直接崩溃。而一个分布式系统却可能处于”半工作”状态：一些请求成功了，一些超时了，还有一些悄无声息地丢失了，而这一切可能同时发生。本章聚焦于能让大型团队构建出可优雅降级、并在局部故障下依然保持可理解性的系统所需要的推理方式与设计模式。

关键原则

网络并不可靠。 设计每一次远程交互时，都要假定它可能变慢、失败、重复或乱序。
在发生网络分区时，你无法同时拥有完美的一致性和完美的可用性。 要针对每一次交互刻意做出选择（CAP/PACELC），并且要记住，即便没有发生分区，延迟本身也是一种成本。
让操作幂等化。 如果一个操作可以被安全地重试，那么大多数分布式故障处理问题就会变得可控。
每一次远程调用都需要超时时间。 无限等待会把一个缓慢的依赖项变成一次波及全系统的服务中断。
在业务允许的地方优先选用最终一致性，但要把这一点说清楚。 用户和审计人员必须明白，他们何时可能看到过时的数据。
隔离故障。 舱壁隔离和断路器能阻止一个正在失效的组件把故障级联到其他所有组件上。
看不见的东西就无法调试。 分布式流程需要跨越每一跳都相互关联的链路追踪、指标和日志。
“恰好一次投递”是一个神话；恰好一次处理才是一项工程成就。 应针对”至少一次投递加去重”进行设计。

建议

用 CAP 和 PACELC 来推理一致性

CAP 定理指出，在发生网络分区期间，系统必须在一致性（每次读取都能看到最新的写入）和可用性（每个请求都能得到响应）之间做出选择。PACELC 补充了第二种权衡：Else（即便没有分区）你依然要在L延迟和C一致性之间做取舍。不要把这个决定当作贴在整个系统上的一个标签，而应逐个操作分别决定。银行的余额转账需要强一致性，宁可拒绝执行也不愿冒重复扣款的风险。而一条社交动态或一个商品浏览计数器则可以接受一定的陈旧度，以换取可用性和速度。要把每条数据流所采用的一致性模型（强一致性、因果一致性、读己所写，还是最终一致性）明确记录下来，避免有人误以为系统提供了它实际上并不具备的保证。

把幂等性、超时、重试和退避作为一个整体来构建

要把这四项技术当作一个整体来对待。为每一次远程操作设置超时时间，这样一个挂起的依赖项就不会永远阻塞某个线程。在失败时进行重试，但仅限于那些可以安全重复执行的操作。可以安全重复执行，意味着这个操作是幂等的：为每个请求分配一个唯一的键，并让接收方据此去重，这样一次被重试的”扣款”请求就不会被扣两次款。用指数退避加抖动来拉开重试之间的间隔，从而避免出现同步化的重试风暴（）那会把一次短暂的小故障放大成一场自己造成的拒绝服务。要限定重试次数和总的时间预算，因为无休止的重试只会转移故障，而不是解决它。没有幂等性，重试就是危险的；没有退避，重试就是破坏性的。

添加断路器和舱壁隔离以阻止级联故障

断路器（circuit breaker） 会监视对某个依赖项的调用，一旦故障次数超过某个阈值就会”跳闸”：在一段冷却期内快速失败，而不是继续把更多请求压向一个已经不堪重负的服务，随后再进入”半开”状态以测试其是否已经恢复。这能阻止这样一种级联效应：一个缓慢的下游服务耗尽了每个调用方的线程，直到整个系统陷入停滞。舱壁隔离（bulkheads） 会将资源（线程池、连接池）进行分区，这样某个依赖项的饱和就不会侵占其他依赖项所需要的容量。要把这两者与优雅降级搭配使用：当某个非关键依赖项不可用时，返回缓存的或默认的响应，而不是让整个请求失败。

用 Saga 而不是两阶段提交来管理分布式事务

通常你无法在多个服务或数据库之间维持单一的ACID（原子性、一致性、隔离性、持久性）事务。分布式的两阶段提交速度慢、会锁定资源，还会削弱可用性。应改用 Saga 模式。把一次业务事务建模为一系列本地事务，每个事务在完成后都发布一个事件来触发下一个事务，并为每一步配备一个补偿动作，以便在后续步骤失败时将其撤销。Saga 有两种实现方式。编排式（choreography） 让各个服务对彼此的事件做出反应，没有中央控制器。编排协调式（orchestration） 则由一个中央协调器来驱动各个步骤，这种方式更便于推理和监控。Saga 拥抱的是最终一致性：系统会经历若干中间状态，然后再收敛。因此在设计用户体验和审计轨迹时，要把”进行中”和”已补偿”这些状态也考虑进去。

把”恰好一次”当作”至少一次加去重”来对待

消息代理无法在跨越故障的情况下真正保证恰好一次投递。它们和你真正能够做到的，是带有幂等处理的至少一次投递，这样就能产生恰好一次的效果。要把消费者设计成能够安全处理重复消息，可以使用幂等键，或维护一份已处理消息日志。要精确了解你所用消息代理的顺序保证和投递保证。对于流式处理，要有意识地使用消费者组、分区和偏移量管理，并确保重新处理是安全的，这样你就可以在修复某个缺陷之后重放一个流，而不会破坏下游状态。

端到端地为分布式流程加上监测手段

要采用可观测性的三大支柱，并在服务边界之间相互关联。在每一跳中传递一个链路追踪 / 关联 ID（trace/correlation ID），这样你就能跟踪单个用户请求所经过的全部服务（分布式链路追踪）。为每个服务和每个依赖项发出结构化的指标（metrics）（延迟百分位数、错误率、饱和度、吞吐量）。发出携带关联 ID 的结构化日志（logs）。利用这一切来设定服务水平目标，并针对用户真正能感受到的症状（例如错误率和延迟）设置告警，而不仅仅依据单台机器的健康状况。在一个分布式系统中，可观测性不是可有可无的工具，而是理解局部故障下系统行为的唯一途径。

权衡：利与弊

技术	优点	缺点 / 成本
强一致性	心智模型简单，不存在过时读取	分区期间可用性降低、延迟更高、协调成本上升
最终一致性	高可用性、低延迟、可扩展	存在过时读取、推理更复杂、需要冲突解决机制
带退避的重试	能自动挺过瞬时故障	使用不当会放大负载；需要幂等性和上限约束
断路器 / 舱壁隔离	阻止级联故障、快速失败	增加复杂度、需要调优阈值、存在过早跳闸的风险
Saga（相对于两阶段提交）	可扩展、可用性高，无需分布式锁	最终一致性、需要补偿逻辑、推理难度更高

其中最核心的权衡在于协调与独立之间的取舍。你想要在多台机器之间获得的每一项保证（一致性、顺序、恰好一次）都要以延迟、可用性或复杂度为代价。它要求各台机器达成一致，而在一个不可靠的网络上达成一致的代价高昂。这门技艺的关键，是逐个操作地只购买业务真正需要的保证，其余的一切都按优雅降级来设计。过度购买一致性，系统就会变得缓慢而脆弱；购买不足，你就会得到悄无声息的数据损坏，而这往往要等到数月后的一次审计失败才会浮出水面。

需要与团队讨论的问题

你的韧性模式是作为共享平台的默认能力交付的，还是每个团队都在各自重新发明超时和重试？ 本章将幂等性、超时、有上限的重试、断路器和链路追踪视为一次性构建进共享库和平台默认设置中最经济、最可靠的做法。在一个大型组织里，放任每个团队各自手搓这些能力，必然导致不一致：有些路径会重试非幂等的操作，有些没有超时时间，有些不发出任何关联 ID。带上证据：抽查一批服务，统计有多少服务对每一次远程调用都设置了明确的超时时间，并端到端地传递了链路追踪 ID。如果这个比例很低，那么解决办法是投入平台建设，而不是发一份培训备忘录。标准化的默认设置还能让韧性变得可测试、可审计，这正是金融和政府领域的监管方日益期望你能够证明的能力。
你的超时和重试预算是否在整条调用链上是可组合的，还是一个深层请求会把自己重试成一次服务中断？ 一次请求往往要经过很多跳，如果每一层都各自独立地用自己的超时时间重试三次，最内层的故障就会被成倍放大，外层调用方最终等待的时间会远超任何人能够容忍的极限。要为面向用户的请求设定一个总的时间预算，并沿着调用链向下分配，这样内层服务就能知道自己还剩多少时间，从而快速失败，而不是重试出一场风暴。带上你的依赖关系图和一份真实的链路追踪记录，把最坏情况下的超时与重试组合加总起来，与用户实际会等待的时长进行比较。带抖动的指数退避加上总尝试次数的上限，能防止一次短暂的小故障演变成一场自己造成的拒绝服务。深而繁琐的同步调用链在这里是天敌，因此答案可能会推动你转向异步流程，或减少调用跳数。
你上一次主动注入设计声称能够扛住的故障是什么时候，结果哪些地方出了你没预料到的问题？ 韧性模式在你真正让系统故意失效之前，都只是假设：杀掉一个实例、给某个依赖项增加延迟、丢弃一部分消息、把一批消息重复投递两次。在一个分布式系统中，真正有意思的故障是局部的、间歇性的，因此一个在代码里看起来正确的断路器或 Saga 补偿逻辑，在一次”可能已经完成也可能没完成”的真实超时面前仍然可能出错。带上一次真实的 game day 或故障注入演练的结果，而不是一份设计文档，并记下哪些告警被触发了、链路追踪定位故障用了多长时间，以及是否形成了任何重试风暴。在受监管的行业中，“曾经测试过故障”这一证据，正是向审计方证明运营韧性的一部分。如果你从未做过这样的实验，那么第一次实验应当放在一个爆炸半径很小、并配有中止开关的测试环境中进行。
对于每一条主要数据流，负责的团队能否说出它所提供的一致性模型，这个选择是否真正匹配业务实际需要的东西？ CAP 和 PACELC 强制你针对每个操作做出刻意的选择，然而在一个大型组织里，默认的走向却是”漂移”：一条最初为某个无关紧要的计数器而设计成最终一致的数据流，被重新用在了如今用于审批付款或授予访问权限的场景中，却没有人重新审视过这个保证是否依然合适。这里的相互竞争是真实存在的：强一致性会在分区期间牺牲可用性，即便没有分区也会带来延迟；而最终一致性用你必须自行设计应对的过时读取和冲突解决问题，换来了速度。带上你最重要的数据流清单，为每一条标注其当前的模型（强一致性、因果一致性、读己所写，或最终一致性），以及一次过时或丢失读取所带来的业务后果，然后找出那些保证强度与实际风险不匹配的地方（）无论是过强还是过弱。在企业金融以及政府的福利或身份系统中，一次隐藏在权威决策背后的最终一致性读取，正是那种会在数月后以审计发现或错误拒绝的形式浮出水面的隐性缺陷，因此这项审查本身就是审计方会要求查看的证据。
你的跨服务业务事务在进行到一半时表现如何，又是谁对那些撤销它们的补偿动作负责？ 用 Saga 取代两阶段提交，意味着系统会经历可见的中间状态，某一步可能成功了，而后续某一步却失败，并触发一个把前面动作撤销的补偿动作。对大型团队而言，这带来了棘手的归属问题：授权-扣款-入账-记账这条链条往往横跨多个团队，如果某个团队忘记实现其对应的补偿动作，资金或记录就会永久处于不一致状态。要权衡编排式（服务对彼此的事件做出反应，没有中央控制器，流程难以看清）与编排协调式（由一个协调器驱动并监控各个步骤，代价是需要运行一个额外的组件）之间的取舍。带上你最重要的那个 Saga 的状态图、补偿动作清单及其各自的负责人，以及”进行中”和”已补偿”状态在用户体验和审计轨迹中都得到了妥善处理的证据。在银行业和公共部门的案件管理中，监管方期望你能够准确还原一笔中途失败的事务究竟发生了什么，因此一个未被建模的中间状态不仅仅是一个缺陷，而是一个合规缺口。
你的消息消费者能否扛住重复和乱序的投递，你能否在消息代理逼着你回答这个问题之前就证明这一点？ 恰好一次投递是一个神话，你真正拥有的保证是至少一次投递，而一个假定每条消息都只会按顺序到达一次的消费者，终究会在消息代理因故障切换而重新投递一批消息的那一天出现重复处理。在多个团队之间，这种风险会被放大，因为共享流上的一个非幂等消费者，可能会破坏其他团队所依赖的下游状态，而这种故障在重放或分区导致事件乱序之前是不可见的。这里的权衡是幂等键、已处理消息日志，以及明确的偏移量和分区处理所带来的工程成本，与悄无声息的数据损坏所带来的成本之间的取舍。带上你的关键数据流上的消费者清单，记下哪些做了去重、哪些只是抱有侥幸心理，并带上一次真实的重新投递或重放测试的结果，而不是一句”应该没问题”的保证。对于跨机构的政府数据交换以及企业的事件流水线而言，在修复缺陷之后能够安全地重放一个流、且不产生重复的案件或扣款记录，既是一项运营上的必要能力，也是审计方希望看到被证明的能力。

行业视角

创业公司。 只有两三个活动部件，也没有平台团队，不要去构建一套你根本养不起的分布式机械装置。要把韧性能力尽量购买（）利用支付或消息服务商已经提供给你的 SDK 中现成的能力，把稀缺的注意力集中在能够防止不可逆损害的两个模式上：每一次涉及资金流转或账户变更的调用都带上幂等键，以及配上超时和有上限的重试，这样一个不稳定的连接就永远不会导致一个操作被执行两次。要把网络跳数控制在较小的数量，因为你添加的每一个同步依赖项，都是在还没人当班盯着的时候就可能出故障的又一个环节。

小型企业。 你很可能没有分布式系统专家，预算也很紧张，因此应把这当成一个”购买而非自建”的问题：优先选用托管队列、托管数据库，以及那些能替你处理重试、顺序和去重的平台，而不是你必须自己运维的基础设施。用直白的语言来框定风险：清楚哪些操作一旦被执行两次或返回过时数据会伤害到客户，并开启供应商已经提供的幂等性和至少一次投递功能。避免通过共享数据库把多个服务拼接在一起来假装拥有一个事务，因为那样做只会悄悄重新制造出最棘手的分布式问题，却没有任何工具来管理它。

企业。 核心问题在于跨众多团队的一致性，因此应当把幂等性、超时、有上限的重试、断路器和相互关联的链路追踪，作为共享平台的默认能力来交付，而不是任由每个团队各自手搓。要标准化每条数据流一致性模型和投递保证的声明方式，按固定节奏开展故障注入和 game day 演练，并让总的时间预算能够在深层调用链上组合起来，这样一个服务就不会把整个平台重试成一次服务中断。要把韧性当作一种被度量的能力来管理，针对用户可见的症状设定服务水平目标，因为在你这个规模上，一个缺失的超时设置就足以级联成一场头条新闻式的服务中断。

政府。 跨机构系统意味着没有任何一方掌控全局，因此要为你无法控制的边界进行设计：具备至少一次投递能力的持久化队列、基于稳定消息 ID 的去重机制，以及能够跨越机构边界流动的关联 ID，从而为审计人员提供一条端到端的追踪链路。采购和透明度规则会促使你把每一次集成的一致性模型和投递保证明文记录下来，并让权威性的决策（身份、资格审核、福利发放）依赖于强一致性读取，而不是缓存端点。要把”曾经测试过故障”以及”能够还原事务历史”当作可交付成果来对待，因为运营韧性和对公众的问责，是合同和法律层面的义务，而不是内部的锦上添花之举。

示例

创业公司。 一家小型金融科技创业公司只有两个通过网络通信的活动部件：它的应用和一家第三方支付服务商。即便规模如此之小，它也会让每一个扣款请求都携带一个幂等键，并把该调用包裹在带退避的重试逻辑中，这样一个在不稳定连接上丢失的响应就永远不会导致客户被重复扣款。第一天省略这一点看似划算，但第一次真实用户遭遇重复扣款，就会引发一场支持部门的救火行动、一笔退款，以及这家年轻公司经不起的信任损耗。

企业。 一个全球性的网约车平台通过一个 Saga 来处理行程付款：授权卡片、扣除乘客费用、向司机入账、记录账本条目，每一步都是一个本地事务，并配有相应的补偿性回滚动作。每一步都携带一个幂等键，因此网络超时之后的重试永远不会导致重复扣款。对欺诈评分服务的调用位于一个断路器之后；当该服务在高峰期性能下降时，断路器会跳闸，触发时会回退到一个保守的评分，而不是阻塞每一次行程。当客户对某次行程提出异议时，分布式链路追踪能让工程师在几秒钟内追踪到它所涉及的十几个服务。

政府。 一项国家身份服务被许多机构用于身份核验。它为权威性的状态核查提供强一致性读取（你绝不能依据过时的身份数据批准一项福利），同时也为高流量、非关键性的查询提供一个最终一致的缓存端点。跨机构数据交换通过一个具备至少一次投递能力的持久化消息队列进行，每个机构的消费者都基于消息 ID 进行去重，因此一条被重新投递的记录不会产生一个重复的案件。关联 ID 在各机构边界之间流动，为审计人员提供了公民数据在各部门之间流转的端到端追踪记录。

商业论证：动机、投资回报率与总拥有成本

分布式系统方面的纪律，购买成本低廉，而缺失它所付出的代价却是灾难性的。采纳成本是把幂等性、超时、重试、断路器和链路追踪构建进共享库和平台默认设置所需要的工程时间，这是一笔不算大、且大多为一次性的投入，之后每个团队都能从中受益。而不采纳它的成本，则要以重大服务中断来衡量：一个缺失的超时设置级联成一次全平台的服务中断，一条非幂等的支付路径给成千上万客户重复扣款，或是一个没有 Saga 保护的分布式事务让数据永久处于不一致状态。这些每一起都是头条式的事件，会带来直接的收入损失、补救成本和声誉损害，在受监管的行业中，还会带来罚款。

向领导层阐述这一论证时，应围绕可用性和爆炸半径来展开。韧性模式能直接降低严重事件的发生频率和持续时长，而这两者正是高管们已经在以正常运行时间和平均恢复时间（MTTR）来追踪的指标。分布式可观测性是撬动 MTTR 的单一最大杠杆：拥有相互关联的链路追踪能力的团队，能以远远更短的时间解决跨服务事件。由于这些能力最适合作为共享平台的默认功能来交付，每个团队为此付出的边际成本很低，而在整个组织范围内的回报则会不断累积。总拥有成本方面的论证很简单：从一开始就把韧性构建进去，其成本只是在被一次服务中断逼着补建之后才做同样事情的成本的一小部分。

反模式与常见陷阱

没有超时设置。 一个单一的挂起依赖项会耗尽所有线程，并拖垮整个系统。
重试非幂等操作。 产生重复的副作用：重复扣款、重复记录、重复邮件。
重试风暴。 没有退避和抖动的同步化重试，会把一次小故障放大成一场服务中断。
假定投递是恰好一次的。 构建出一旦收到消息代理迟早会投递的重复消息就会出错的消费者。
通过共享数据库实现分布式事务。 通过一个数据库把多个服务耦合在一起来假装拥有 ACID 特性，重新制造出一个分布式的单体系统。
忽视局部故障。 代码假定一次远程调用要么完全成功、要么完全失败，却没有处理”已超时但也许已经完成”这种情况。
没有关联 ID。 靠在十台机器上翻找互不相关的日志来调试一次跨服务事件。
繁琐的同步调用链。 深层的同步依赖关系图，其中任何一跳变慢都会拖住整个请求。

成熟度模型

第 1 级：启动。 远程调用被当作本地调用来对待。超时设置缺失或过于天真，重试要么不存在、要么鲁莽行事，故障会在整个系统中级联蔓延。对一致性或投递方式没有共同的认知，调试一次跨服务事件意味着事后逐台机器地翻查日志。
第 2 级：发展。 一些团队添加了超时设置、基本的重试和一点幂等性，但这些做法在各服务之间并不一致。日志被集中收集了，但彼此之间并未关联，因此跨多跳追踪一个请求需要手工完成。分布式事务被寄希望于”应该没问题”，而不是被真正建模，一致性保证仅存在于个别工程师的脑海中。
第 3 级：标准化。 幂等性、有上限的重试、带抖动的退避、断路器和舱壁隔离，都通过共享库在整个组织范围内实现了标准化。带补偿动作的 Saga 处理跨服务事务，带关联 ID 的分布式链路追踪已经就位，每一条主要数据流都记录了自己的一致性模型和投递保证。这些规则被明文记录下来，并在全组织范围内强制执行，而不是任由各团队自行其是。
第 4 级：管理。 韧性能力不仅存在，还依据基线被持续度量。你会按服务和依赖项追踪错误率、延迟百分位数、饱和度和吞吐量，监视重试比例和断路器跳闸率，并针对用户可见的症状设定服务水平目标。总时间预算在调用链上的可组合性得到了验证，跨服务事件的平均恢复时间是一项被监控的指标，故障注入和 game day 的结果为每一次变更的放行决策提供数据支撑。
第 5 级：编排。 韧性成为持续改进、在整个组织范围内集成并能够随条件自适应的平台默认能力。故障注入在生产环境中作为常规操作运行，爆炸半径被严格控制，系统按设计能够优雅降级，一致性和投递方式的选择会随着负载和业务风险的变化而不断被重新审视。第 4 级中的各项指标驱动着自动化响应和持续的架构演进，因此整个分布式体系会随着每一次事件而变得更加健壮，而不仅仅是勉强挺过去。

讨论思路

你的哪些关键操作在今天是真正幂等的，哪些其实并不是，只是没人注意到？
对于每一条主要数据流，你的团队能否凭记忆说出它的一致性模型和投递保证？
在你上一次级联式服务中断中，断路器本可以在哪个环节阻止它？
目前追踪一个失败请求所经过的全部服务需要多长时间？
你的哪些”分布式事务”其实是在依赖运气，哪些才是真正带有补偿动作的 Saga？
如果你的消息代理把每条消息在一小时内重复投递两次，会出什么问题？

关键要点

假定网络不可靠、故障是局部的；针对变慢、丢失、重复和乱序，设计每一次远程交互。
用 CAP/PACELC 逐个操作地决定一致性与可用性之间的取舍；把每条数据流所提供的模型明文记录下来。
幂等性、超时、有上限的重试，以及带抖动的退避是一个整体；永远不要只采用重试而不采用其他三项。
断路器和舱壁隔离用于遏制故障；带补偿动作的 Saga 能取代难以运作的分布式事务。
把投递当作至少一次来对待，并让处理过程幂等化，从而实现恰好一次的效果。
相互关联的链路追踪、指标和日志，是理解和运维分布式流程的唯一途径。

参考资料与延伸阅读

Martin Kleppmann，Designing Data-Intensive Applications
Andrew Tanenbaum、Maarten van Steen，Distributed Systems: Principles and Paradigms
Michael Nygard，Release It!: Design and Deploy Production-Ready Software
Sam Newman，Building Microservices
Chris Richardson，Microservices Patterns（Saga、事务性消息传递）
Eric Brewer，“CAP Twelve Years Later”；Daniel Abadi 关于 PACELC 的论述
Leslie Lamport，“Time, Clocks, and the Ordering of Events in a Distributed System”
Cindy Sridharan，Distributed Systems Observability
Nassim Nicholas Taleb 的反脆弱（antifragility）概念（在韧性工程文献中的应用）