工程哲学：Werner Vogels

核心要点

• 他的核心原则是:一切都会一直出故障,因此你要为故障而设计,而不是为防止故障而设计。 自2005年起担任 Amazon CTO 的 Werner Vogels,把一个直白的观察——在足够大的规模下,组件故障是持续的、统计上必然的——变成了一条设计教条:假定每一块磁盘、每一台服务器、每一条网络链路、每一项依赖都会出故障,并构建出能在故障之中依然保持可用的系统,而不是假装故障可以被防止。¹⁶
• 他是 Dynamo 论文的共同作者,这篇论文开创了现代 NoSQL 背后的种种思想。 《Dynamo: Amazon’s Highly Available Key-value Store》(SOSP 2007)把一致性哈希、向量时钟、宽松法定人数、基于流言的成员管理以及最终一致性,统统装进了一个始终可写的存储系统里,并直接影响了 Cassandra、Riak、Voldemort,以及 Amazon 自家的 DynamoDB。²³
• 他是最终一致性最重要的布道者。 他的文章《Eventually Consistent》把可用性与一致性之间的取舍讲得明明白白:当网络发生分区时——而在大规模下它一定会——你必须做出选择,而 Dynamo 选择了保持可用、随后很快收敛,而不是阻塞到所有副本达成一致为止。⁴⁷
• 他为工程文化留下了”you build it, you run it”(谁构建,谁运维)这句话。 在2006年的一次对话中,他描述了 Amazon 让开发者在生产环境中拥有自己服务的模式——界定范围、构建,并且运维——并主张让构建者背上呼机、站在客户面前,正是驱动质量的关键。⁵

这条原则

“Everything fails, all the time.”(一切都会一直出故障)—— Werner Vogels,Amazon CTO,谈如何设计可靠的分布式系统⁶

大多数工程都是为一切正常运转的情形而优化的。你写好正常路径,处理掉几个能想到的错误,然后发布。这种本能一直管用,直到你在大规模下运行系统——那时它就会背叛你。当你运行着几十万台机器时,”罕见”不再罕见。每块硬盘三年才出一次的磁盘故障,在你的机群某处每隔几分钟就会发生一次。每百万个数据包丢一个的网络链路,一天会丢掉数百万个数据包。Vogels 最著名的那句话把这一切压缩成四个词:一切都会一直出故障。⁶ 故障不是需要绕开去设计的例外;在大规模下,它是你必须针对它去设计的稳态条件。

由此推出的原则,是对常规原则的颠倒。如果你无法防止故障——而在大规模下你可被证明无法做到——那么防止它就是错误的目标。正确的目标是在事物正在出故障的同时保持可用。所以你假定每个组件都会死去,并这样设计:任何单一的死亡都能挺过去。把数据跨机器复制,让其中一份的丢失不可见;把服务解耦到 API 之后,让出故障的依赖只降级某个功能而不是掀翻整个系统;并且把任何单一故障的爆炸半径降到最小,使其无法拖垮整体。系统不是为了避开故障情形而建,而是为了让故障情形乏味无奇而建。¹⁶

这条原则还有后半部分,正是它让前半部分成真:一旦网络可能发生分区,你就无法同时拥有完美的一致性和完美的可用性,因此你必须选择——而 Vogels 选了可用性。 当网络分裂把你的副本彼此隔开时,系统要么拒绝作答、直到所有人达成一致(一致,但不可用),要么用手头已有的内容继续作答、稍后再调和(可用,但短暂地不一致)。对 Amazon 的购物车而言,拒绝作答是不可接受的——在分区期间拒绝”加入购物车”的购物车,就是丢失一笔销售的购物车。⁴ 所以 Dynamo 始终接受写入,让副本随后再收敛。代价是有一个短暂的时间窗口,不同副本可能返回不同的答案;回报则是一个永远不对客户说”不”的系统。这种取舍——保持可用、随后很快收敛,而不是阻塞到所有人达成一致为止——就是最终一致性,Vogels 用一生主张它在大规模下是正确的取舍。⁴⁷

背景

Werner Vogels 于1958年10月3日出生于荷兰埃尔默洛。¹ 他通往计算的道路,并不是穿过顶尖大学的那条常规直线。他在海牙应用科学大学攻读计算机科学,于1989年完成学业,直到很久以后才取得阿姆斯特丹自由大学的计算机科学博士学位——他2003年的论文《Scalable Cluster Technologies for Mission Critical Enterprise Computing》由 Henri Bal 和 Andrew Tanenbaum 指导,后者是分布式系统与操作系统领域的奠基人物之一。¹ 值得记住的细节是,这个博士学位是跟在多年真实系统工作之后,而非在它之前;是理论追上了实践。

最具塑造性的篇章发生在康奈尔大学,1994年至2004年间他在那里担任研究科学家,从事可扩展、可靠的企业系统研究。¹ 在康奈尔,他身处 Ken Birman 的分布式系统研究组——Isis 与可靠组通信的那条谱系,这一系工作探问的是:一组机器如何在成员不断故障与恢复的过程中达成一致、保持一致并持续运行。他与 Birman、Robbert van Renesse 共同创办了一家公司 Reliable Network Solutions,并出任其副总裁兼 CTO。¹ 这就是 Vogels 生长其中的思想土壤:不是”我们如何防止机器出故障”,而是”一群机器如何在其成员故障的同时保持正确与可用”。当他后来说一切都会一直出故障时,他并非即兴发挥——他是在陈述自己浸淫其中十年的可靠分布式系统传统的奠基前提。

他于2004年9月加入 Amazon,任系统研究总监,于2005年1月被任命为 CTO,并在2005年3月加上了副总裁头衔——此后他一直担任这一角色,推动公司整体的技术方向。¹ 他的到来恰逢 Amazon 发明现代云的那些年:Dynamo 存储系统在这一时期被构建并写成论文,Amazon Web Services 推出了它的基础服务,而 Vogels 成了这一切底层架构原则的公开代言人——为故障而设计、通过服务解耦、拥抱最终一致性,并让构建服务的人来负责运维它。²⁴⁵

这些工作

“一切都会一直出故障”:为故障而设计与最终一致性

从这里开始,因为这是被铸成工程的那条原则。这条教条有两步动作。第一步是为故障而设计:把每个组件都当成必将出故障的东西,让系统挺过它的丢失。这意味着冗余(复制,使任何一份副本都可以消失)、解耦(服务通过 API 对话,使生病的依赖优雅降级而非级联崩溃),以及爆炸半径围控(对系统分区,使故障被困在一个小单元里而非四处蔓延)。¹⁶ 一个设计的考验,不是”在一切健康时它能否运转”,而是”当这块部件在最糟糕的时刻死去时会发生什么”——而答案必须是”系统继续提供服务”。

第二步动作,正是让高可用在大规模下成为可能的那一步:最终一致性。Eric Brewer 的 CAP 观察指出,当网络发生分区时,分布式系统无法既完美一致又完全可用——它必须放弃其一。⁷ Vogels 的《Eventually Consistent》把这个选择讲明了,并精确定义了那条替代路径:在最终一致性下,”存储系统保证,如果不再对该对象做新的更新,最终所有访问都将返回最后更新的那个值。”⁴ 最终这个词就是这整桩取舍。一个强调可用性的系统”可能始终接受写入,但在某些条件下,一次读取不会反映出一次刚刚完成的写入的结果。”⁴ 在一个短暂、有界的时间窗口里,两个副本可以彼此不一致——但谁都绝不拒绝作答。收敛在后台进行,用户从不被阻塞。

为何它作为工程很重要:大多数开发者对数据库的心智模型是单机的那种,一次写入会立即对其后每一次读取可见,因为只有一份副本。那个模型在大规模下活不下来,因为一份副本是单点故障,而一台机器是吞吐量的天花板。一旦你开始复制——而为了可用你必须复制——你就继承了这个问题:当副本们还在追赶时,一个读者看到的是什么。Vogels 的贡献在于坚持:这不是一个要藏起来的缺陷,而是一个要刻意去选择的设计维度;并且给了工程师一套词汇——读己之写、单调读、会话一致性——让他们恰好挑出某个工作负载实际需要多少一致性,而不必在所有地方都为最强的保证付费。⁴

Dynamo 论文与 NoSQL 运动

这条原则有一件正典式的产物:《Dynamo: Amazon’s Highly Available Key-value Store》,由 Vogels 共同撰写,发表于该领域顶级的操作系统会议 SOSP 2007。² Dynamo 是 Amazon 对一个具体而残酷的需求给出的答案——购物车必须始终接受写入,哪怕在数据中心分区和磁盘故障期间也是如此,因为一个不可用的购物车会直接损失营收。²³ 为强一致性而调优的传统关系型数据库,在分区下无法做出这种承诺。于是 Amazon 构建了一个用一致性换可用性的存储系统,并把具体做法精确地写了下来。

Dynamo 是一份分布式系统技术的目录,被组装进一个始终可写、去中心化的系统里,而这篇论文的影响力,来自它把这些技术铺陈得多么干净利落。²³ 一致性哈希把数据分区到各节点上,使环可以增长或收缩而无需把一切重新洗牌——“渐进的、可能是线性的可扩展性”。³ 向量时钟追踪每个值的因果历史,使并发写入能够被检测到,而不是被悄无声息地丢失。宽松法定人数与提示移交让系统在部分副本不可达时仍可写入,把写入暂存在一个临时替身上,直到正主节点归来。基于默克尔树的反熵让副本能高效地找出并修复彼此的差异。基于流言的成员管理让节点无需中央协调者就能彼此知晓并检测故障——这一设计刻意保持对称与去中心化,所以”Dynamo 中的每个节点都应当与其同伴拥有同一套职责”,这意味着不存在哪个特殊节点,其死亡是灾难性的。³ 这每一个选择都服侍着同一个主人:在事物出故障时保持可用。

Amazon 从未发布 Dynamo 的代码,但那篇论文完成了使命——它成了那十年间最具影响力的系统论文之一,是 NoSQL 运动的思想种子。³ Apache Cassandra、Riak 和 Project Voldemort 那种无主、最终一致的设计,都可直接追溯到它。³ 而这个名字也以 Amazon DynamoDB 的形式在商业上延续了下来,它建立在 Dynamo 的原则之上,尽管在底层做出了不同的工程选择(单主复制,而非 Dynamo 那种纯粹的无主模型)。³ Dynamo 影响力本身的教训也值得一记:Amazon 的竞争护城河不是代码,而是清晰。通过精确解释他们放弃了哪些保证、为什么放弃,他们教会了一代工程师如何对这种取舍进行推理。

AWS、面向服务,以及”you build it, you run it”

Dynamo 是个存储系统;Vogels 更深层的贡献则是架构性的和文化性的。Amazon 的平台被构建成一张由只通过 API 对话的独立服务组成的网——没有谁伸手到幕后去碰共享数据库,没有隐藏的耦合。⁵ 这种纪律对故障至关重要:当服务被解耦到硬性接口之后,出故障的那一个只会降级它所支撑的那个具体功能,而不会损坏数据、或拖住所有触碰过它的东西的线程。面向服务,就是用架构表达出来的爆炸半径围控。它也正是让 AWS 成为可能的东西——一旦你的内部系统是干净的、可经 API 寻址的服务,把它们作为产品对外开放,就是顺理成章的下一步。

文化的那一半,是 Vogels 被引用得与”一切都会一直出故障”一样频繁的那句话:“you build it, you run it”(谁构建,谁运维)。 在2006年与 Jim Gray 的一次对话中,他描述了 Amazon 的模式,即每个服务由构建它的团队从头到尾拥有:”每个服务都有一个与之关联的团队,而那个团队对该服务负完全责任——从界定功能范围,到对它做架构设计,再到构建它、运维它。”⁵ 而其理由明确地关乎以拥有换取质量:”谁构建,谁运维。这让开发者接触到自己软件的日常运维。它也让他们与客户产生日常接触。”⁵ 没有一堵可以把代码扔过去的墙;写下这个服务的工程师为它背上呼机。其效果是一个紧密的反馈回路——最有能力修复某个脆弱点的人,正是在凌晨三点感受到那份痛苦的人;而设计了这个功能的人,直接听到客户的抱怨。在这里,”拥有”不是一句人力资源标语;它是一种可靠性机制。一个运维自己所构建之物的团队会为故障而设计,因为故障会把他们自己叫醒。

为云布道:爆炸半径、单元,以及良好架构的系统

Vogels 的第四类工作,与其说是单件产物,不如说是一个持续了二十年的角色:他是那位架构师兼布道者,系统化地讲清了如何在云之上构建,而不只是如何构建云本身。¹⁶ 反复出现的主题,是把这条原则应用到越来越大的范围。把爆炸半径降到最小:把系统切分成独立的单元,使一个故障、一次糟糕的部署、或一个有毒的请求被围控在一小片客户里,而不是全体客户。积极地解耦:相比那种一个慢依赖就会拖住整条调用链的紧密同步链条,更应偏向带有明确契约的异步、松耦合服务。把恢复自动化,而不是把它写进文档:一份需要人来执行的运维手册,在那个人睡着时不会被执行。把故障当作一种测试输入来拥抱:刻意注入故障以证明系统能挺过它们,而不是寄望它能。这每一条都是被转化为运维实践的”一切都会一直出故障”——这是一以贯之的信息,在演讲、写作以及多年后第二次 ACM 对话中反复出现:韧性是一种你从第一行代码起就设计进去的属性,而不是在演示跑通之后再加上去的一层。⁶

这套方法

横跨 Dynamo、最终一致性、面向服务,以及”you build it, you run it”去读,会发现同样的承诺在反复出现。Vogels 的方法与其说是一句口号,不如说是一组始终在场的习惯。

先为故障情形设计。 在大规模下,故障是稳态,而非例外,所以问题从来不是”这能不能跑”,而是”当这其中的每一块死去时会发生什么”。⁶ 这个教训远不止适用于 Amazon 的规模:不要先写好正常路径、再补上错误处理——先把故障模式枚举出来,让能跑的那条路径,从一个已经能挺过它们的系统里自然流出。这是把证据之门应用到可靠性上——“在演示里能跑”不是证据;”我在请求进行到一半时杀掉一个节点,它依然保持可用”才是,而这与 Radia Perlman 构建进网络的那种自愈是同一标准——那些网络无需人介入回路便能重新收敛。

选择你的一致性,而不是承袭它。 Dynamo 里最深的那步动作,是拒绝那个默认设定:每次读取都必须看到先前每一次写入。Vogels 把一致性变成一个你按工作负载来设定的旋钮——正确性要求的地方就调强,可用性更重要的地方就用最终——并对一个系统实际提供的是哪种保证保持精确。⁴⁷ 这套纪律,就是确切知道你的一致性主张所凭依的是什么,且绝不为某个工作负载并不需要的保证付费。这与 Leslie Lamport 为分布式时间带来的那种对正确性的精确如出一辙:不要假定那个性质,要把它精确地定义出来,并知道它何时成立。

通过解耦来围控爆炸半径。 硬性 API 之后的独立服务,意味着一个故障被困在它发生的地方,而不是级联蔓延。⁵ 这个始终在场的习惯,是这样去划定边界:让最坏情形是一个降级的功能,而绝不是一个宕掉的系统——对每一项依赖都问一句”当它出故障时,这个洞有多大”,并把洞做小。这是最小可敬产品的架构形态:最干净的边界,是那种恰好只做自己分内之事、并且独自出故障的边界。

让构建者拥有运维。 “you build it, you run it”把设计了某个服务的人放到它的呼机前,合上了脆弱点与那个能修复它的人之间的回路。⁵ 这个教训是:运维的痛苦,是世上最诚实的质量信号——一个与生产隔绝的团队会对韧性投入不足,因为脆弱的代价落在了别人身上。拥有是一种可靠性机制,这正是被铸成组织架构图的质量是唯一的变量:保证质量的唯一办法,是让构建者亲身感受质量缺席的后果。

把取舍公开讲清楚。 Dynamo 的影响力,不是来自它的代码——那代码从未发布——而是来自一篇明明白白讲清了放弃哪些保证、为什么放弃的论文。²³ 这个习惯,是让推理变得可读:给取舍命名,为你所选的那一侧辩护,并教会下一个工程师去对它进行推理,而不是照搬结果、奉若神明。对为什么的清晰,正是让一个设计活得比它的作者更久的东西——这与让 Perlman 和 Lamport 的论文在数十年后仍可教学的,是同一种解释的纪律。

影响链

谁塑造了他

Ken Birman 与康奈尔的可靠分布式系统传统。 Vogels 在康奈尔的那十年,身处 Birman 的研究组以及 Isis/可靠组通信的谱系之中,正是他奠基前提的源头。¹ 那个传统的核心问题——一群机器如何在其成员不断故障与恢复的同时保持正确与可用——恰恰就是”一切都会一直出故障”所回答的问题。他并没有发明一句口号;他是为一个行星级的受众,重新陈述了他这一领域的第一性原理。(塑造性影响)

Andrew Tanenbaum 与分布式系统学界。 他的自由大学博士学位,部分由 Tanenbaum 指导,后者是该领域操作系统与分布式系统的奠基性教师之一。¹ 这份根底显而易见:Dynamo 读起来像是分布式系统正典的一次可运行的综合——一致性哈希、向量时钟、法定人数、流言——由一个对文献了如指掌的人组装而成。(塑造性影响)

Eric Brewer 与 CAP 取舍。 Vogels 为最终一致性所做的论证,明确地建立在那个 CAP 观察之上:一个分区容错的系统必须在一致性与可用性之间做取舍。⁴⁷ Brewer 框定了那个不可能性;Vogels 在 Amazon 的规模上把这个选择落地为操作,并让”选可用、然后收敛”成了一个体面的默认选项。(直接影响)

他塑造了谁

整个 NoSQL 运动。 Dynamo 论文是 Cassandra、Riak 和 Voldemort 的直系祖先,也是 DynamoDB 的同名之源——那种无主、最终一致的设计范式,从2007年的一篇论文,传播进了一代系统的数据层。³

云原生架构与 DevOps 文化。 “you build it, you run it”成了现代 DevOps 的奠基思想之一——全程服务拥有、值班开发者,以及开发/运维之墙的消融,都可直接追溯到 Vogels 在2006年所描述的那个模式。⁵

一代云架构师。 通过 AWS 的设计原则以及他持续不断的布道,”为故障而设计”“把爆炸半径降到最小”“通过服务解耦”成了工程师们用来推理如何在云上构建可靠系统的默认词汇。⁶

贯穿始终的主线

Vogels 是本系列的运维规模拱顶石——那位把分布式系统理论拿来、在一整个行星的机器上跑起来的人物。Leslie Lamport 给了分布式系统它们的根基:如何精确地定义时间、定序与共识,以及当参与者出故障或行为任意时如何让系统保持正确。Vogels 则是那些根基在不得不去支撑一个黑色星期五购物车时的样子——同样是关于一致性与故障的问题,但回答的现场不是白板,而是真实负载之下,真金白银的营收押在”保持可用”上。⁴ 而 Radia Perlman 构建的网络,把故障情形当作设计的中心,无需人介入回路便能自我治愈;Vogels 则在更上一层、恰恰凭着那种本能构建了服务——复制、解耦、围控爆炸半径,并让系统自行收敛。Lamport 说定义正确性、并证明它能挺过故障,Perlman 说把它构建成能自我治愈,而 Vogels 说:一切都会一直出故障,所以别再试图防止它了——要这样设计,让系统径直穿过故障而保持可用,并让运维它的那些构建者感受到每一道裂缝。(系列桥接)

我从中汲取的

我从 Vogels 这里留下的教训,是把故障当作常态,而非例外。我的本能,和大多数构建者一样,是去写那条调用成功、依赖应答、磁盘就在那里的路径——然后等它跑通了,再栓上一个 try/catch。”一切都会一直出故障”是对此的反驳:在任何真实的规模下,故障都不是一桩稀罕的、发生在我系统身上的事件,而是我系统所身处其中生活的一个恒常条件。所以现在当我构建某样东西时——一个同步作业、一个 API 客户端、一个队列消费者——我会试着从”什么会死,而当它死去时其余部分还继续提供服务吗”出发,而不是最后才走到那一步。”它能跑”的诚实版本,不是那个一片绿的演示;而是在请求进行到一半时杀掉一个依赖,看着系统优雅降级而不是翻倒。一个只能挺过正常路径的系统,是一个我还没设计完的系统。

第二个教训是:可用性与一致性,是一桩我必须刻意去做的取舍。两个都想要是很诱人的——每次读取都看到每一次写入,而且系统永远不说不——而对一台单机,你确实可以两全。可一旦我复制了任何东西,那份安逸就没了,而 Vogels 的纪律,是为每个工作负载刻意去选择一侧,而不是出于习惯在所有地方都默认用最强的保证。我所构建的大多数东西,并不需要一次读取立即反映最新的写入;它需要的是永不拒绝客户。最终一致性为我把这件事重新框定了:从一个吓人的妥协,变成一件精确的工具——确切地说出一个读者能容忍多陈旧,用这份余量换来可用性,并停止为一个功能从不需要的保证付费。这门手艺不在于总是去够那个最强的承诺——而在于知道这项工作实际需要的是哪个承诺。

常见问题

“everything fails all the time”(一切都会一直出故障)是什么意思?

这是 Werner Vogels 对一个关于规模、来之不易的教训所做的压缩:当你运行着足够多的机器时,组件故障不再是一桩罕见的例外,而成为一个恒常的、统计上必然的条件。⁶ 一种在单台服务器上罕见到可以忽略的故障模式,在一个大机群的某处会持续不断地发生。其实际后果,是对常规工程的颠倒:不是去试图防止故障,而是假定每一块磁盘、每一台服务器、每一条链路、每一项依赖都会出故障,并设计出能在故障之中保持可用的系统——通过冗余、解耦,以及被围控的爆炸半径——使任何单一故障都能被挺过去,理想情况下还不可见。¹⁶

Dynamo 论文是什么?

《Dynamo: Amazon’s Highly Available Key-value Store》是一篇2007年的 SOSP 论文,由 Vogels 共同撰写,描述了 Amazon 为了让购物车这类服务即使在故障与网络分区期间也保持可写而构建的存储系统。²³ 它把这些技术结合在了一起:用于分区的一致性哈希、用于追踪并发写入的向量时钟、用于在故障下保持可用的宽松法定人数与提示移交、用于修复的基于默克尔树的反熵,以及用于去中心化成员管理的流言——全都服务于始终接受一次写入、稍后再调和。Amazon 从未发布代码,但这篇论文成了 NoSQL 运动的基石,直接影响了 Cassandra、Riak、Voldemort 以及 Amazon DynamoDB。³

什么是最终一致性?

最终一致性是 Vogels 所倡导、并在其文章《Eventually Consistent》中定义的一种宽松的一致性模型:”如果不再对该对象做新的更新,最终所有访问都将返回最后更新的那个值。”⁴ 在一个复制的系统里,一次写入可能先到达某些副本、再到达另一些,所以在一个短暂的窗口里,不同副本可以返回不同的答案——但谁都绝不拒绝一次请求。系统保持可用,在后台收敛,而不是阻塞到每个副本都达成一致为止。它是 CAP 取舍中偏可用性的那一侧:当网络发生分区时,系统可以是一致的(拒绝作答,直到所有人达成一致)或可用的(用手头已有的内容作答,稍后再调和),而最终一致性选择了可用。⁴⁷

“you build it, you run it”是什么意思?

“you build it, you run it”(谁构建,谁运维)是 Vogels 在2006年一次 ACM Queue 对话中,对 Amazon 全程服务拥有模式的描述:构建某个服务的团队”对该服务负完全责任——从界定功能范围,到对它做架构设计,再到构建它、运维它。”⁵ 开发与运维之间没有一堵墙——写下代码的工程师为它背上呼机。Vogels 主张,这”让开发者接触到自己软件的日常运维”,并”与客户产生日常接触”,而由此产生的反馈回路,正是驱动质量的东西。⁵ 这个理念成了现代 DevOps 文化的奠基原则之一。

Sources