写点什么

亚马逊的分布式计算宣言

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

评论

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

架构实战营模块一作业

哈啰–J

[Day33-03]-[二叉树] 二叉树展开为链表

方勇(gopher)

LeetCode 二叉树 数据结构和算法

Kotlin 入门笔记(一)

如浴春风

5月月更

抽象类——加油站加油

程序员猪小哼

Nacos 源码简析之 Nacos Client 自动注册原理

道嗔

源码 nacos

Continuous Integration 对 ABAP 技术栈来说意味着什么

汪子熙

持续集成 SAP abap 5月月更 持续优化

DevOps系列之 —— DevOps概览(一)软件产业和交付模式发展趋势

若尘

DevOps 5月月更

【51单片机】矩阵键盘

謓泽

5月月更 51单片机

极简Java数据结构-环形队列突破上限

芝士味的椒盐

Java 数据结构 5月月更

安装Maven到Idea配置Maven竟如此简单

芝士味的椒盐

Java maven 5月月更

【建议收藏】Redis知识干货汇总

利志分享

redis 面试

maven构建docker镜像三部曲之二:编码和构建镜像

程序员欣宸

Docker maven java 5月月更

全链路压测(十):测试要做的准备工作

老张

性能测试 全链路压测 稳定性保障

公众号运营推广方式

源字节1号

软件开发

LeetCode 242:有效的字母异位词

武师叔

5月月更

[Day33-02]-[二叉树] 恢复二叉搜索树

方勇(gopher)

LeetCode 二叉树 数据结构和算法

C语言总结_字符串函数封装练习

DS小龙哥

5月月更

SpringSecurity 表单登录

急需上岸的小谢

5月月更

[Day33-01]-[二叉树] 路径总和

方勇(gopher)

LeetCode 二叉树 数据结构和算法

Nation3云上国家--一场基于Web3的社会实验(32/100)

hackstoic

DAO web3 nation3

洞见科技李博:科技向实,隐私计算规模化应用吹响号角

洞见科技

金融科技 隐私计算

电商秒杀系统设计

Geek_36cc7c

Git进阶系列 | 2. Git中的分支策略

俞凡

git 最佳实践

Git进阶系列 | 1. 创建完美的提交

俞凡

git 最佳实践

redis性能调优--内存使用率过高

en

redis 内存

网站开发进阶(四)Tomcat Server处理http请求过程详解

No Silver Bullet

tomcat HTTP 网站开发 5月月更

从源码深入了解Dio 的 CancelToken

岛上码农

flutter 安卓开发 跨平台开发 ios 开发 5月月更

阿里巴巴Java性能调优实战

Joseph295

Netty篇之内存管理器

邱学喆

内存管理器 netty内存管理 jemalloc管理器

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