1998 年的西雅图，亚马逊公司的人已经开始重新审视他们的架构。亚马逊 1997 年的销售额为 1.47 亿美元，到了 1998 年就超过了 6 亿美元，这样的增长速度令他们感到措手不及。1998 年，亚马逊的人写了一份分布式计算宣言，描述了他们看到的问题以及他们为这些问题给出的解决方案。Werner Vogels 最近在他的文章（）中公布了这份宣言。
这篇文章以时间胶囊的方式概述了亚马逊架构的演变，与今天许多关于系统架构的争论以及几乎所有正在演变中的架构都不可避免会面临的挑战紧密相关。
宣言中写道：
尽管分布式计算宣言是在 1998 年写的，但不管从哪一方面来看，1997 年的亚马逊已经是一个分布式系统了。问题出在接口上——数据存储充当组件和关注点之间的接口，导致存储和业务逻辑之间存在紧密耦合。这种架构很难扩展，问题不在于无法提高每秒处理的请求量，而在于很难跟上新的业务线和整体变化的速度。
他们建议的解决方案是进行服务化。这份宣言起草于“微服务”出现之前，但讨论的也差不多就是微服务——将数据移到封装了业务逻辑的接口后面，减少系统不同部分之间的耦合。
对于我来说，宣言中最有趣的部分是对文化需要随架构的变化而变化的描述。只是改改架构图根本不足以达到作者想要的结果。
这种思维模式的转变——从数据库到 API——是面向服务架构和微服务在过去二十年中崛起的基础。现在，到了 2022 年，随着嵌入式数据库和两层架构重新流行起来，我们看到了以数据为中心的思维在某种程度上与以 API 为中心的思维出现了融合。架构呈现多样性是一件好事，但我们希望新一代两层系统的架构师们能够吸取旧单体系统给我们留下的经验教训。
宣言的另一个突破是谈到了工作流在分布式架构中的作用。他们发现，尽管订单流在后端是紧密耦合的，但它们已经是工作流了：
这种架构的伸缩性挑战在于：
解决方案：
大约十年后，我开始在亚马逊工作，我发现这种思维方式很具有启发性。在加入亚马逊之前，我花了一些时间思考雷达仿真分布模型，这是一个有趣的计算和数据密集型工作流问题。谷歌在 2004 年发布了 MapReduce 白皮书，并已成为具有普适性的以数据为中心的分布式通信模型。我们尝试用 MapReduce 来解决我们的问题，但没有成功。我不禁想，如果我当时看到了亚马逊这篇关于工作流的文章，是否会用这种模式取得更大的成功。
这份宣言浓缩了一段迷人的历史，涵盖了亚马逊的技术演变，以及 Web 发展对分布式系统架构的影响。从那以后，行业发生了巨大的变化，亚马逊的技术也有了显著的演变，并为我们留下了宝贵的经验教训。
原文链接：
今日好文推荐
写“毁灭人类计划书”、错误太多被Stack Overflow封禁，好玩的 ChatGPT 还不能替代程序员
Vue 3是最佳选择吗? 耗时两周从Vue 2迁移到Svelte后：代码执行更快、体验更佳
当 Rust 成为“巨坑”：拖慢开发速度、员工被折磨数月信心全无，无奈还得硬着头皮继续
台积电分红曝光：入职 8 个月狂领 44 个月薪水；Elastic 将裁员 13%，付至少 14 周补偿；马斯克和苹果解除“误会”｜Q 资讯
