写点什么

亚马逊的分布式计算宣言

  • 2022-12-15
    北京
  • 本文字数:2026 字

    阅读完需:约 7 分钟

亚马逊的分布式计算宣言

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 翻译,未经许可禁止转载。


今日好文推荐


写“毁灭人类计划书”、错误太多被Stack Overflow封禁,好玩的 ChatGPT 还不能替代程序员


Vue 3是最佳选择吗? 耗时两周从Vue 2迁移到Svelte后:代码执行更快、体验更佳


当 Rust 成为“巨坑”:拖慢开发速度、员工被折磨数月信心全无,无奈还得硬着头皮继续


台积电分红曝光:入职 8 个月狂领 44 个月薪水;Elastic 将裁员 13%,付至少 14 周补偿;马斯克和苹果解除“误会”|Q 资讯


2022-12-15 11:054099

评论

发布
暂无评论
发现更多内容

主流分布式文件系统总结

跳蚤

产品经理面试常见问题总结2

lenka

3月日更

在你所在的公司(行业、领域),正在用大数据处理哪些业务?可以用大数据实现哪些价值?

跳蚤

Wireshark数据包分析学习笔记Day18

穿过生命散发芬芳

Wireshark 数据包分析 3月日更

开源与商业产品

ES_her0

3月日更

Gradle无法访问Nexus私服仓库-offline

wjchenge

How to Connect 2 Cisco Switches Together

心在飞

《青春有你3》的子弹时间舞台,凝筑了自由视角技术进化史

脑极体

第11周课后练习-安全稳定

潘涛

架构师训练营 4 期

产品训练营第八周作业——用户路径地图

innovator琳

用户研究 用户地图 用户数据 用户模型

一文搞定Diff算法

执鸢者

Vue 大前端 Diff

找到适合自己的睡眠方案

石云升

生活方式 28天写作 睡眠 3月日更

央行数字人民币“可控匿名”会侵犯隐私吗?最新解读来了

CECBC

数字货币

登陆用户身份获取

程序员架构进阶

架构设计 认证授权 28天写作 3月日更

mybatis 添加日志功能

xiezhr

mybatis 日志

hive数据倾斜解决办法

五分钟学大数据

大数据 hive 28天写作 3月日更

IO 模型

无心

Netty

谈兼职创业

Ryan Zheng

产品0期-第九周

Jxin

思呓(2)

型火🔥

学习 架构 分布式 解耦

uni-app跨端开发H5、小程序、IOS、Android(五):uni-app数据绑定

黑马腾云

html5 微信小程序 uni-app iOS Developer 3月日更

数据仓库设计

大数据技术指南

大数据 28天写作 3月日更

从Nacos客户端视角来分析配置中心原理

麦洛

nacos SpringCloud Alibaba 动态配置

传统IT部门为什么越来越不受欢迎?

boshi

数字化转型 IT职场 七日更

线上问题的一点反思

风翱

复盘 3月日更 线上问题

树集合总结

我是程序员小贱

3月日更

《Redis 核心技术与实战》学习笔记 06

escray

redis 学习 28天写作 3月日更 Redis 核心技术与实战

用户故事拆分速查手册(译)

Bruce Talk

敏捷 译文 Agile User Story

javax.imageio.IIOException: Unsupported Image Type

wjchenge

深入剖析 | Java16语法特性

九叔(高翔龙)

Java 架构

寻找被遗忘的勇气(二十一)

Changing Lin

3月日更

亚马逊的分布式计算宣言_文化 & 方法_Marc Brooker_InfoQ精选文章