亚马逊的分布式计算宣言

1998 年的西雅图，亚马逊公司的人已经开始重新审视他们的架构。亚马逊 1997 年的销售额为 1.47 亿美元，到了 1998 年就超过了 6 亿美元，这样的增长速度令他们感到措手不及。1998 年，亚马逊的人写了一份分布式计算宣言，描述了他们看到的问题以及他们为这些问题给出的解决方案。Werner Vogels 最近在他的文章（https://www.allthingsdistributed.com/2022/11/amazon-1998-distributed-computing-manifesto.html）中公布了这份宣言。

这篇文章以时间胶囊的方式概述了亚马逊架构的演变，与今天许多关于系统架构的争论以及几乎所有正在演变中的架构都不可避免会面临的挑战紧密相关。

宣言中写道：

业务应用程序直接访问数据库，并了解其中的数据模型。这意味着应用程序和数据模型之间存在非常紧密的耦合，即使功能保持不变，修改了数据模型也必须修改应用程序。

尽管分布式计算宣言是在 1998 年写的，但不管从哪一方面来看，1997 年的亚马逊已经是一个分布式系统了。问题出在接口上——数据存储充当组件和关注点之间的接口，导致存储和业务逻辑之间存在紧密耦合。这种架构很难扩展，问题不在于无法提高每秒处理的请求量，而在于很难跟上新的业务线和整体变化的速度。

由于应用程序对数据元素之间的依赖关系非常敏感，因此这种架构不能很好地扩展，基于数据位置的分布和隔离处理也变得很困难。

他们建议的解决方案是进行服务化。这份宣言起草于“微服务”出现之前，但讨论的也差不多就是微服务——将数据移到封装了业务逻辑的接口后面，减少系统不同部分之间的耦合。

我们建议转向三层架构，其中表示层（客户端）、业务逻辑和数据是分离的。这也被称为基于服务的架构。应用程序（客户端）不能够直接访问数据库，只能通过定义良好的接口来访问数据，这些接口封装了执行对应功能所需的业务逻辑。

对于我来说，宣言中最有趣的部分是对文化需要随架构的变化而变化的描述。只是改改架构图根本不足以达到作者想要的结果。

在转向基于服务的架构时，我们必须注意到几个重要的含义……第二个含义（与第一个相关）是所有软件开发人员都需要进行重大的思维转变。我们当前的思维模式是以数据为中心，在为业务需求建模时，我们总是采用以数据为中心的方法。我们的解决方案通常是修改数据库的表或列，并将数据模型嵌入到应用程序中。基于服务的方法要求我们将解决方案至少分解为两个部分。第一部分是数据元素关系的建模，这跟之前的一样，包括数据模型和服务访问数据需要遵循的业务规则。第二部分是我们以前从未做过的，即设计客户端和服务之间的接口，不向客户端公开或不让客户端依赖底层的数据模型。

这种思维模式的转变——从数据库到 API——是面向服务架构和微服务在过去二十年中崛起的基础。现在，到了 2022 年，随着嵌入式数据库和两层架构重新流行起来，我们看到了以数据为中心的思维在某种程度上与以 API 为中心的思维出现了融合。架构呈现多样性是一件好事，但我们希望新一代两层系统的架构师们能够吸取旧单体系统给我们留下的经验教训。

宣言的另一个突破是谈到了工作流在分布式架构中的作用。他们发现，尽管订单流在后端是紧密耦合的，但它们已经是工作流了：

我们已经有了一个“订单管道”，从客户下单到发货，各种业务流程都会操作这个管道。我们的大部分处理过程已经是面向工作流的，尽管工作流“元素”是静态的，并且主要驻留在单个数据库中。

这种架构的伸缩性挑战在于：

……数据库工作流模型不能进行很好的伸缩，因为处理过程是针对一个中心实例进行的。随着工作负载的增加……，中心实例的处理负载量将增加到不可持续的极限。对此的一个解决方案是分发工作流，将其从中心实例中卸载。

解决方案：

不是让处理流程来主动接触数据，而是让数据流经处理流程。

大约十年后，我开始在亚马逊工作，我发现这种思维方式很具有启发性。在加入亚马逊之前，我花了一些时间思考雷达仿真分布模型，这是一个有趣的计算和数据密集型工作流问题。谷歌在 2004 年发布了 MapReduce 白皮书，并已成为具有普适性的以数据为中心的分布式通信模型。我们尝试用 MapReduce 来解决我们的问题，但没有成功。我不禁想，如果我当时看到了亚马逊这篇关于工作流的文章，是否会用这种模式取得更大的成功。

这份宣言浓缩了一段迷人的历史，涵盖了亚马逊的技术演变，以及 Web 发展对分布式系统架构的影响。从那以后，行业发生了巨大的变化，亚马逊的技术也有了显著的演变，并为我们留下了宝贵的经验教训。

原文链接：

https://brooker.co.za/blog/2022/11/22/manifesto.html

声明：本文为 InfoQ 翻译，未经许可禁止转载。