这是一篇名副其实的大软文，作者是亚马逊现任 CTO Werner Vogels 教师。但这篇大软文挺悦目的，因为 CTO 写的深入浅出，很轻易让人相识到，从手艺发展的维度看，为何是亚马逊先把云盘算鼓捣出来了。趁便也诠释了，亚马逊的“两个披萨”文明是怎样来的，以及亚马逊疾速立异的部份隐秘。假如你不体贴云盘算手艺，那末看到小题目之前就可以够了。假如你体贴云盘算手艺，也看到小题目之前就可以够了，因为后边的内容太手艺向了，我不敢保证能翻译正确。

原文来自民众号：西卅廿（ID：xisanian），作者： Werner Vogels（亚马逊 CTO），翻译：郝晓茹，封面来自视觉中国

立异一直是亚马逊公司 DNA 的一部份。或许 20 年前，为了让我们的立异迭代历程——“发明、宣布、再发明、再宣布、从新最先、大浪淘沙（rinse）、反复、一次又一次”——速率更快一些，我们阅历了一场完全的革新。这场革新不仅影响了我们怎样开辟产物，而且影响了我们怎样构造公司。

20 年前，亚马逊网站效劳的用户数量，只占本日我们所效劳用户的很小一部份。但那时刻，我们就晓得，假如想扩大亚马逊网站供应的产物和效劳项目，我们就必需转变悉数网站的应用架构。

当时驱动 Amazon.com 网站的是一个大型的、单体的“在线书店”顺序和对应的单体大型数据库。这类状况限定了我们的速率和迅速度。因为主顺序最初是专为我们的第一个产物——在线书店而开辟的，所以每当我们想要增添新的功用，或为主顾供应新产物，比方视频串流（video streaming）功用，就必需从新编写悉数顺序的代码。从新编写悉数顺序代码的历程，冗长而笨重，须要庞杂的营业和部门职员谐和历程，这类状况影响我们疾速立异和范围化立异的才能。

因而，我们撰写了《分布式盘算宣言》，将其作为公司寻求革新的蓝图。在这份内部文档中，我们形貌了新的体系应用架构。然后，遵照这份宣言，我们最先对悉数体系应用举办重构，将其分割为被称为“效劳”的模块，便于支撑亚马逊的范围扩大。

转变悉数体系的应用架构，只完成了亚马逊这场革新故事的一半（另一半是公司构造的调解）。回到 1998 年，一切的亚马逊开辟职员都在保护同一个顺序，这意味着每一次新版本的宣布，都须要谐和一切开辟团队。

为了支撑新的应用架构，我们突破了职能品级，将团队重组为小型的、自治的小组。每一个小组都小到只须要两个披萨就可以喂饱。我们让每一个小组都专注于一个详细的产物、效劳或功用组，从而让他们对悉数应用的某个详细模块具有更多权限。这么做以后，我们的产物开辟者就变成了产物的主人，他们可以更疾速地做出会影响到本身这部份产物的决议计划。

突破我们的构造构造和应用架构是一个斗胆勇敢的主张，幸亏这个主张终究胜利了。因而我们可以以更快的速率，为主顾带来立异：跟着亚马逊的生长，我们从每一年布置几十项新功用，到现在每一年能布置数百万项新特征。更戏剧性的是，我们在建立高扩大性基本设施方面获得的胜利，不仅终究变成了一项亚马逊新的中间才能，也为我们在 2006 年宣布 AWS 云效劳打下了基本。

直到现在，我们依旧对峙将团队分红“两个披萨就可以喂饱”小组举办事变。

在寻求疾速立异的道路上，我们并不孑立。为了坚持合作力，很多公司都想要增添迅速性，从而延续发明新的时机，开辟更好的产物。因而很多公司踏上跟亚马逊一样的路程，转向现代化的应用开辟形式。这类新的开辟形式，须要将传统应用的单体架构转向更小的组件集架构，或许叫微效劳（microservice）架构。关于现代化应用的最好实践而言，革新不仅触及转变设想和应用手艺的体式格局，也须要从新思索怎样举办职员治理。

任何公司，若想在新的顺序开辟形式下获得胜利，增添公司的迅速性和立异速率，都应采纳以下五项基本手艺：微效劳、专用数据库（purpose-built databases）、自动化软件宣布管道、无效劳器（serverless）操纵形式、自动化且贯串一直的平安性。

架构形式：微效劳（Microservices）

跟亚马逊一样，大部份公司刚最先的时刻都是以单体顺序（monolithic application）开展营业，因为如许速率最快，也最轻易开辟。然则，这类将一切历程绑定在一起，作为团体效劳供应的体式格局，存在一个题目：假如个中一个模块碰到需求岑岭，那末为了应对这个模块的高负载，悉数架构都须要扩大盘算容量。

另外，跟着代码库的增进，顺序功用的增加和革新都变得越发庞杂。因而，实验和完成新主意也越发困难。这类单体顺序的架构还增添了悉数体系的可用性风险，因为一切历程都相互依靠、严密耦合（coupled），假如个中一个历程发作毛病，就会影响悉数体系。

这就是为何，跟着公司生长，人人就会最先斟酌“微效劳”架构。公司采纳微效劳架构以后，软件体系由自力的组件组成，每一个历程都作为一项效劳存在。而每项效劳都代表一项营业才能，比方购物车。因为每项效劳自力运作，由零丁的开辟小组担任，所以开辟小组可以自立晋级、布置和扩大这项效劳，以满足悉数体系对特定效劳模块的需求。以购物车的例子来讲，举办促销的时刻，就可以够零丁为购物车扩容，以满足更大范围用户的暂时需求。

很多开辟者发明，跟着公司顺序架构从大型单体顺序形式转到微效劳形式，他们愿望经由过程管道（pipeline），来治理每项效劳之间的依靠关联（dependencies）。因而，开辟者不能不采纳新的解决计划，来打包顺序和运转代码。有了新的解决计划，过去那种建立虚拟机实例（instances）的体式格局，不再是唯一的选项。

开辟者可以运用软件容器（container）或 AWS “Lambda 函数”。软件容器是最受迎接的代码打包选项，也是把传统应用推向现代化的主要东西，因为软件容器在设置上供应了精彩的便携性和灵活性。经由过程 AWS Lambda，操纵变得越发简朴，开辟者只须要写贸易逻辑的代码就行。

末了，微效劳之间怎样“沟通”是另一个须要斟酌的事变。很多应用顺序继承运用 API 举办衔接，然则微效劳之间另有多种通报数据的要领。比方及时数据处置惩罚须要的串流形式。比方数据变化以后触发相应的事宜形式。再比方，掌握应用顺序之间通讯，完成可视察性（Observability）的 App Mesh 效劳网格。开辟者可依据公司营业需求，挑选最合适的集成体式格局。

数据治理：专用数据库

现代化应用基于“盘算和存储解耦架构”开辟，解耦（decoupled）以后，将专用数据库与微效劳一对一映照，而不是采纳一个大型单体的数据库。相对传统顺序架构而言，盘算和存储解耦是非常主要的变化。因为就像传统的大型单体顺序，跟着营业扩大会碰到扩容和容错的应战，数据库也是如许：单一数据库意味着一点失足全盘皆输，而且很难让单一数据库来满足多种差别范例微效劳的特地需求。经由过程存储-盘算解耦，开辟者就可以够依据本身的需求，挑选最合适的数据库。

关于大部份顺序来讲，最好挑选或许仍然是关联型数据库，然则也有很多顺序有差别的数据需求。比方，假如你须要处置惩罚高度关联的数据集，比方你在开辟引荐引擎，那末可以挑选图形化数据库（graph database），如 Amazon Neptune，合适存储和查找数据间的联络。

或许，假如你的顺序须要及时接入数据，那末你可以挑选内存数据库（in-memory database），如 Amazon ElastiCache，这类数据库常常被用于游戏和IoT（物联网）范畴。一般，能充足满足微效劳需求的数据库，才是最好的数据库。

软件分发：自动化软件宣布管道

我们拆除了 Amazon.com 网站所采纳的单体顺序架构，将职员重组为“两个披萨”小组。同时，我们也不再运用单一软件宣布管道，而是最先许可各小组自力宣布本身的效劳。

许可各小组自力宣布效劳以后，我们消除了开辟和宣布软件晋级包时，所碰到的职员和营业谐和困难。然则，这类将开辟和宣布历程权力下放的体式格局，也带来一系列新应战：让一切团队都保证宣布流程和质量的稳定性，变得越发困难。尤其是，假如宣布流程的每一步都是手动的，那末就增添了工资失足的能够性。

我们的解决计划是左右开弓：规范化和自动化。起首，我们把软件托付流程定义为最好实践模板，该模板供应在云环境中建模和设置基本架构资本的规范。这类模板利用了“基本架构即代码”（infrastructure as code）效劳，也就是说，模板经由过程代码为顺序供应悉数手艺栈，而无需手动流程，因而团队成员可以更快上手。在亚马逊，最好实践模板确保了各个团队可以根据我们的请求，自行设置和布置他们本身的营业流程。

其次，我们消除了软件托付流程中的手动操纵步骤，运用自动化的体式格局取而代之。经由过程自动化软件宣布管道，我们完成了延续集成（Continuous Integration，CI）和延续布置（Continuous Deployment，CD），如许不仅能疾速宣布测试版本，而且能将失足的能够性最小化。经由过程延续集成（CI），我们的团队可以随时将代码合并到中间代码库，然后实行自动化地建立和测试，从而尽早发明题目所在。经由过程延续布置（CD），我们的团队在不经由任何工资操纵的状况下，天天都可以屡次提交代码变动，而且自动布置上线。

最初，我们以为缺乏工资介入的产物布置会很轻易出题目。然则，在我们花了很多时候举办测试，并布置了失效平安（fail-safe）计划以后，终究我们发明，自动化宣布不仅极大地提升了我们的速率和迅速度，而且还提升了代码的质量。

操纵形式：尽量多采纳“无效劳器”架构（serverless）

现代化的应用有很多运动部件（moving parts），而不单单议只要单个顺序和数据库，它还能够包含几千项效劳，每一个效劳都有专用数据库，以及一个配套的延续宣布新功用的团队。

这些运动部件，可分为两个种别：

• 一类是公司的中间合作力（secret sause），是公司在市场上获得胜利的缘由，比方建立奇特的用户体验，或许开辟立异的产物。

  
  

• 一类我们一般称之为无差别的一样平常事件，这些使命是必需要做的，然则并不会带来合作上风。关于大部份公司来讲，这些使命包含效劳器治理、负载平衡，以及给体系打平安补丁。

2014 年，经由过程宣布 AWS Lambda，我们引见了无效劳器（serverless）的观点。AWS Lambda 是一项盘算效劳，让你可以运转代码，但不须要预先预备或治理效劳器。这么做相符我们的终究目标：协助客户公司缭绕中间合作力的优化资本，而将一样平常事件交给 AWS。这类理念已成为现代化应用开辟中的症结道理。你的公司假如转用无效劳器形式，就可以够专注于那些让本身的公司越发出众的事变，比方产物立异。

当我们说“无效劳器”的时刻，我们指的是如许的效劳形式：不须要关注基本设施的运用和扩大，效劳已内建可用性和平安性，这类形式采纳只为代价付费（pay-for-valuebilling）的计价形式。最终的“无效劳器”架构，不仅盘算这部份是无效劳器，而且悉数应用的手艺栈都是无效劳器架构。

一个应用的手艺栈，一般包含以下三个差别的组件：

• 盘算效劳，比方 AWS Fargate，用来运转顺序逻辑。

  
  

• 数据库，比方 MySQL 和 PostgreSQL 关联型数据库，或许 Amazon Aurora，用来存储数据

  
  

• 一个集成层（integration layer）担任在两者之间传输数据，比方 Amazon EventBridge

人人可以在三个组件上都采纳“无效劳器”架构，如许开辟的顺序可以最大化无效劳器架构的上风。

在亚马逊，我们现在还没有在一切组件里都采纳“无效劳器”架构。然则，我们正朝着这个方向勤奋。亚马逊的很多客户公司也是云云。事实上，我们展望很快就会有如许一代开辟者：他们从来没有打仗过效劳器，只须要写营业逻辑代码就行。缘由很简朴，不论你是开辟全新的顺序，照样移植旧的顺序，在盘算、数据存储和集成层从一最先就运用无效劳器形式，你的迅速度就可以最大化。这是原生云盘算的上风。

平安：每一个人的义务

过去，很多公司将平安视为魔法粉尘——比及产物宣布以后，再往产物上撒一点就行。然则在延续宣布的轮回周期里，这类状况行不通了。所以，很多公司布置了新的平安策略，为悉数顺序建立防火墙。然则，如许也会存在应战：假如悉数顺序的每一个模块都采纳一样级别的平安设置，那末当个中某个模块须要差别的平安品级设置，就会出现题目。

正因为云云，在现代化的应用中，平安特征被内置于每一个模块中。而且这些平安特征可以跟着每一次的效劳宣布，举办自动化测试和布置。这意味着，平安不再是平安团队的独占义务，而是深度集成到产物开辟周期的每一个阶段。工程、运营以及合规团队都须要介入个中。

就像代码库、构建治理顺序（build management）和布置东西一样，平安性也被集成到东西中。平安东西既适用于软件宣布管道本省，也适用于经由过程该管道宣布的软件。经由过程“无效劳器”效劳，平安状况更易于保持，因为底层的基本设施平安操纵——比方操纵体系版本更新、软件打补丁以及看管，已被内置于每一项效劳中。

转型之旅

我们的客户公司，究竟是怎样举办转型，怎样最先布置现代化应用的？只管因为每一个公司都差别，并没有单一的胜利途径，然则我们照样看到有几种罕见的转型形式，也包含我们在亚马逊的转型形式。

在亚马逊，当我们决议专注于立异，对 Amazon.com 举办大范围扩大的时刻，我们重构了单体式的体系顺序架构，重组了公司构造构造，然后经由过程自动化和抽象化来优化云端顺序架构。一些我们的公司客户，比方 Yelp，也采纳了相似的转型途径。

有的客户公司，之前已布置了当地托管效劳器（on premise），因而他们挑选从新托管，将悉数顺序“平移”（lifting and shifting）到云端。转移到云端以后，很多客户公司就可以够将诸如数据库和 API 治理如许的事变，交给 AWS 云效劳，从而让本身专注于公司的中间营业逻辑。

现在，越来越多客户公司踏上“再生”之路，他们采纳无效劳器的微效劳架构开辟新的顺序，让公司可以充足利用云端的上风。

只管在 AWS 平台上，每一个公司都能找到最合适本身状况的实行体式格局，差别架构的应用可以共存，经由过程多种途径完成交互。然则我们常常可以看到，客户公司布置了现代化应用以后，很快发明了新架构为悉数营业带来的优点，尤其是在怎样分派时候和资本方面。他们可以花更多时候在营业逻辑的定义上，可以轻松扩大以满足用户的峰值需求，也可以增添迅速性，更快更频仍地将新功用宣布到市场上。

举个例子，Edmunds.com 为买车人供应最新的车辆信息，他们的网站上线新功用的时候，已从过去的六个月降低到一周时候。一样，创业公司 Bynder 的新产物推向市场的时候，也从一年降低到一个月。经由过程转变运用手艺的体式格局，这些公司提升了营业才能。

这就是现代化应用的气力。

原文来自公众号：西卅廿（ID：xisanian），作者： Werner Vogels（亚马逊 CTO），翻译：郝晓茹，原题目：《Modern applications at AWS》，原文链接：www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html