写点什么

亚马逊的分布式计算宣言

  • 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:054342

评论

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

Uber系统架构设计

俞凡

架构 大厂实践 uber

模块五作业

Geek_e6f7f6

架构训练营

LabVIEW彩色图像分割(基础篇—14)

不脱发的程序猿

机器视觉 图像处理 LabVIEW 图像分割 阈值处理

Failed to load module "canberra-gtk-module"

Ayosh

【日拱一卒进击大厂系列】为什么单线程的Redis可以实现高并发访问

慕枫技术笔记

后端 1月月更

架构实战营 4 期第四模块作业

jialuooooo

架构实战营

跟一段工作说告别了

wood

300天创作

【Spring专场】「IOC容器」不看源码就带你认识核心流程以及运作原理

码界西柚

Spring Framework spring ioc 1月月更 框架原理

模块四作业 - 学生管理系统的考试试卷存储方案

曾竞超

「架构实战营」

全链路压测系列(四):全链路压测的价值是什么?

老张

性能测试 生产环境全链路压测

Rust 元宇宙 18 —— 多场所共存的世界

Miracle

rust 元宇宙

18款口碑爆棚手机浏览器,被一网打尽了

Jackpop

我最终选择VS Code

Jackpop

模块四作业

Geek_59dec2

试论架构师必备的基础能力

陈俊

架构 技术认知

Go编译原理系列4(语法分析)

书旅

Go 编译 计算机基础 编译原理

2022年推荐6个有意思的CSS tools!

CRMEB

被忽视的问题:测试环境稳定性治理

老张

测试环境 稳定性治理

某反序列化漏洞分析与复现工作

网络安全学海

黑客 网络安全 信息安全 渗透测试 安全漏洞

ReactNative进阶(八):connect

No Silver Bullet

React Native Redux 1月月更 connect

log4j bug

你?

拆分电商系统为微服务

ren

个人成长中,关于规划设计的思考

程序人生

工作方式发生了动荡?

Jackpop

在 Flutter 中发出 HTTP 请求的最佳库(2022 年)

坚果

flutter 1月月更

数据库设计三范式

Ayue、

MySQL 1月月更

C#使用原生方法将文字朗读出来

喵叔

1月月更

【网络安全】浅析跨域原理及如何实现跨域

H

网络安全 网络安全信息安全、

Postman如何做接口测试1:如何导入 swagger 接口文档

和牛

测试

一个cpp协程库的前世今生(十三)互斥量

SkyFire

c++ cocpp

办公专用!又一款开源免费”摸鱼“神器....

Jackpop

Python

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