把握行业变革关键节点,12 月 19 日 - 20 日,AICon北京站即将重磅启幕! 了解详情
写点什么

亚马逊的分布式计算宣言

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

评论

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

你竟不劝我坚持

QualityFocus

职业规划 职业生涯规划

Selenium自动化应该避免的测试场景

FunTester

多方系统集成的启示

QualityFocus

集成测试 系统集成

在线Excel转SQL工具

入门小站

工具

细数云上综合治理始末,华为云联创营解码企业运维之道

极客天地

我们在讲的 Database Plus,到底能解决什么样的问题?

SphereEx

Apache 数据库 开源 ShardingSphere SphereEx

云原生时代的搜索服务算力管理

百度Geek说

架构 云原生 后端

清华校友走进百度 用科技赋能产业智能化转型

百度大脑

DaaS服务之分布式日志/缓存/对象存储

穿过生命散发芬芳

4月月更

资源画像,让容器资源规格的填写不再纠结

阿里巴巴云原生

阿里云 容器 云原生

R 编程语言 - 简介

海拥(haiyong.site)

R语言 4月月更

[Day29]-[数组]将一维数组转变成二维数组

方勇(gopher)

LeetCode 数据结构算法

从概念、部署到优化,Kubernetes Ingress 网关的落地实践

阿里巴巴云原生

阿里云 Kubernetes 云原生 网关

参加 KubeVela 开源之夏,给你的云计算编程能力加个 Buff

阿里巴巴云原生

阿里云 云原生 开源之夏

2022语言与智能技术竞赛再升级,推出NLP四大前沿任务

百度大脑

制造蝴蝶飓风,微众区块链的蝶变和ESG新使命

脑极体

[Day28]-[二叉树]左叶子之和

方勇(gopher)

LeetCode 数据结构与算法

重学架构之电商秒杀系统

陈华英

架构实战营

百度天工AIoT打造农业种植方案,用数字经济助力建设农业新模式

百度大脑

Apache ShardingSphere 代码格式化实战 —— Spotless

SphereEx

Apache 数据库 开源 ShardingSphere SphereEx

linux之软连接和硬连接的区别

入门小站

Linux

浮点数-Float-Double转二进制

入门小站

工具

虎符Hoo即将上线现货网格交易功能

区块链前沿News

虎符交易所

关于K8s中Service Account的一些笔记:Pod内部如何访问K8s集群

山河已无恙

k8s 4月月更

linux之软连接和硬连接的区别

入门小站

Linux

RTC 科普视频丨聊聊空间音频的原理与其背后的声学原理

RTE开发者社区

RTE技术详解 空间音频

ECA 认证备考指南

Se7en

赛事解析|乒乓球时序动作定位大赛亚军方案分享

百度大脑

参赛必看,2022语言与智能技术竞赛赛题任务解读直播!

百度大脑

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