对话亚马逊 CTO：分布式系统该如何设计？

亚马逊 CTO Werner Vogels 谈大型分布式系统的设计原则。

原文标题：《不要将自己锁定在自己的架构中》
撰文：tshi

早在 2006 年，事务处理的开山鼻祖，数据库领域图领奖得主 Jim Gray 与 Werner Vogels 进行了「第一次」对话。对话的主题是「向亚马逊技术平台学习」，而吊诡之处在于，Jim Gray 所开创的事务处理是亚马逊电子商务的技术基础。

最近，Akamai 董事 Tom Killalea 与亚马逊 CTO Werner Vogels 进行了一场「第二次」对话。对话的主题是大规模简单存储系统 S3 的进化设计。而吊诡之处在于，就在一个月前，一个可以对标 S3 的最大区块链存储项目 Filecoin 刚刚升空。

「我认为重要的是要首先意识到亚马逊是一家技术公司」，在「第一次」对话中，Werner Vogels 反复对 Jim Gray 解释称，亚马逊不应该仅仅被视为一家在线书店，而应该被视为一家科技公司。并且，就是在这次谈话中，亚马逊首次公开了 S3，一个简单存储服务。

「Amazon.Com Books」，这个名字并不能反映我们的雄心壮志。Tom Killalea 说到。当 Tom Killalea 在 1998 年加入亚马逊时（Tom Killalea 于 2018 年 3 月加入 Akamai，担任董事），该公司只是一个销售书籍的网站：一个简单 C 应用 Obidos，一个部署在 Berkeley DBs 上的键值存储，一个命名为「ACB」的关系数据库（代指「Amazon.Com Books」），这些应用部署在 5 台服务器上。

不断扩大的客户和订单，让亚马逊放弃了单体架构，走向去中心化的服务化架构。当 Jim Gray 问及亚马逊最大的经验教训时，Werner Vogels 说道：

• 第一个教训，也是最重要的教训，更是元教训：服务意识。严格的面向服务是实现隔离的优秀技术，你会达到一个前所未见的拥有和控制的水平。通过使用服务，不仅技术方面得到了改进，开发和业务进程也大大受益于它。服务模型是创建以客户为中心的快速创新团队的关键推动。每个服务都有一个与之关联的团队，该团队完全负责服务——从确定功能范围，到架构、构建和运维。

• 第二个教训是，通过禁止客户端直接访问数据库，可以在不涉及客户端的情况下对服务状态进行可伸缩性和可靠性改进。这些经验教训与如何访问服务有关：如果你希望能够轻松地聚合服务，如果你希望插入高级基础设施技术，如分布式请求路由或分布式请求跟踪，你需要一个统一的服务访问机制。

• 第三个教训：赋予开发人员运维职责大大提高了服务的质量，无论是从客户的角度还是从技术的角度。传统的模式是，将软件放在分隔开发和运维的墙上，然后将其抛诸脑后。在亚马逊不是这样，谁建立，谁运行。这使开发人员接触到软件的日常运维。这也让开发人员每天都与客户接触。这种客户反馈回路对提高服务质量至关重要。

「如果不把技术用于服务客户的更大利益上，技术就毫无用处。我们是一家强烈以客户为导向的公司，我们经常使用「从客户逆向工作」的方法。这意味着，在你的思考过程中，从客户开始，然后逆向工作，直到找到满足新客户需求所需的简单而最小的技术。重要的是，来到亚马逊工作的工程师要明白，我们不是为了技术而开发技术，而是为了支持客户。」

「面向服务的架构，我们的扩展方式，我们服务客户的方式——我认为我们最大的成功是亚马逊已经成为一个其他企业可以从中受益的平台。」

通过技术和业务的服务化，亚马逊与用户构建了一个快速反馈周期，进入一个飞速增长的飞轮之中。

2006 年 3 月启动 S3 时，S3 只有 8 项服务。到 2019 年，S3 已达到 262 种服务。在与 Tom Killalea 的谈话中，Werner Vogels 说道：「我完全同意这是空前的规模。即使在今天，即使现在的互联网服务已经达到了令人难以置信的规模，我认为 S3 仍然比它领先两到三代。」

在 2006 年的 S3 发布公告中，亚马逊采用了以下分布式系统设计十大原则来满足 Amazon S3 的需求 :

• 去中心化：使用完全去中心化的技术来消除伸缩瓶颈和单点故障。

• 异步：系统在任何情况下都能继续工作。

• 自治：单个组件根据本地信息可以做出决策。

• 局部责任：每个组件负责实现其自身的一致性，这绝不是其他对等节点的责任。

• 受控并发：操作被设计成不需要或有限的并发性控制。

• 容错：组件故障被视为正常运行模式，并且在没有中断或最小中断的情况下继续运行。

• 受控并行：系统抽象具有这样的粒度：使用并行来提高性能、恢复健壮性，或者引入新节点。

• 分解成小的、易于理解的构建块：不要试图提供做所有事情的单一服务，而是构建可以用作其他服务构建块的小组件。

• 对称性：系统中的节点在功能方面是相同的，并且不需要或最少需要特定配置才能运行。

• 简单性：系统应该尽可能地简单，而不是更简单。

上面的十个原则，是亚马逊构建大规模分布式系统的方式。S3 只是这些设计原则的例子。

原则是灰色的，而客户的需求常青。在上面的原则基础之上，Werner Vogels 提出了演化架构。

当时，大多数科技公司提供所有东西和「平台」，他们会提供一本很厚的书和 10 个不同的合作伙伴，然后告诉客户如何使用技术。而亚马逊没有将自己锁定在自己的技术中，走上了另外一条道路。杰夫 . 贝佐斯多年前曾说过，那就是构建工具，而不是构建平台，平台是大型软件平台公司提供技术服务的老方式。

「在我们开始 S3 之前，我们开始意识到我们所做的可能会从根本上改变软件构建和服务使用的方式。但我们不知道这将如何发展，所以更重要的是构建小型、灵活的工具，让客户可以在其上构建（或者我们可以在自己的基础上构建），而不是在某个特定时刻准备好所有东西和「平台」。这不是时间问题，更重要的是，我们坚信，无论我们向 S3 的接口添加什么，向 S3 的功能添加什么，都应该由我们的客户驱动——以及下一代客户将如何开始构建他们的系统。」

「在过去的五到十年里，软件发生了根本性的变化。我们需要构建正确的工具，以支持发生根本性变化的速度。这样，你就无法预测，你必须与你的客户一起工作，等待他们如何使用你的工具——特别是如果这些工具是以前从未构建过的——并观察他们做了什么。然后我们坐下来问自己，最小集合是什么。」

「你必须有意识地小心设计 API。API 是长远的。一旦你把 API 放在那里，也许你可以提供新版本，但你不能把它从你的客户那里拿走。在 API 设计中保持保守和最小化可以帮助你构建基本工具，你可以在这些工具上添加更多的功能，或者合作伙伴可以在其之上构建新的层次，或者你可以将不同的构建块组合在一起。这就是我们从一开始的理念：做到极简主义，这样我们就可以让我们的客户来推动将要发生的事情，而不是我们坐在后面的房间里思考：这个世界应该是什么样子。」

这些设计决策在亚马逊的数据湖中得到了体现。基于构建块和工具，S3 的作用远远超过了数据湖：围绕着数据库，S3 提供了庞大的工具箱（175 种不同的服务）。

在访谈中，S3 的设计决策还包括：

• 持久性大于可用性

• 不变性大于分布式锁

• 计算和存储分离

不要将自己锁定在自己的架构中。Werner Vogels 在回顾 S3 的设计原则时候，这样说道。一个有效的复杂系统总是从一个有效的简单系统演化而来。一个从零开始设计的复杂系统永远不会工作，也不能通过修补使其工作。你必须从一个简单可行的系统开始。

也许读者不需要去阅读两篇访谈的原文，但需要记住和思考的是本文总结的几点：服务意识、分布式系统设计十大原则、构建工具而不是平台、不要将自己锁定在自己的架构中。

来源链接：mp.weixin.qq.com