亚马逊 CTO 的“中台论”

做者 Werner Vogels 是 Amazon.com 的 CTO，他撰写了一篇文章，总结 AWS 这二十多年来，如何经过变革应用程序架构、调整企业组织架构等方式，让构建现代应用程序的客户“将更多时间花在定义业务逻辑上，扩展系统以轻松知足高峰期客户需求，提升敏捷性，同时更快、更频繁地向市场发布新功能”。在文中他提到亚马逊“庞大的总体式‘书店’应用程序以及臃肿的数据库极大限制了咱们的速度与敏捷性。每当咱们打算为客户提供新的功能或者产品，咱们就必须在专为书店设计的应用程序当中编辑甚至重写大量代码”，将组织架构调整为小团队并“赋予他们对应用程序内特定部分的更多操做权限”，经过改变对技术的运用方式，业务交付速度提高很是明显，好比某汽车领域客户将将新功能的推出时间由六个月缩短至一周。这篇文章体现的，对比咱们如今倡导的“中台论”，不少地方都不谋而合了。也可谓是亚马逊的“中台论”，虽然他们并无使用这个词。

创新一直是亚马逊公司 DNA 中的重要组成部分，但大约 20 年以前，咱们迎来了一场完全的转型。当时的目标，是让咱们的迭代过程——发明、启动、从新发明、从新启动、淘汰陈旧事物、再次重复——在速度上进一步提高。而咱们作出的变革，则深深影响到咱们构建应用程序甚至组织企业结构的具体方式。

那个时候，亚马逊所服务的客户数量远不及当下。尽管如此，咱们很清楚若是想要对自身提供的产品与服务加以扩展，首先必须改变咱们的应用程序架构。

庞大的总体式“书店”应用程序以及臃肿的数据库虽然为 Amazon.com 提供了充沛的动力，但同时也极大限制了咱们的速度与敏捷性。每当咱们打算为客户提供新的功能或者产品——例如视频流——时，咱们就必须在专为书店设计的应用程序当中编辑甚至重写大量代码。这是一个漫长并且繁琐的过程，须要复杂的协调努力，并且极大限制着咱们快速推动大规模创新的能力。

为了从根本上解决这一难题，咱们经过《分布式计算宣言》创建起新的变革蓝图。这是一份描述新架构的内部文档。经过这份宣言，咱们开始将自身应用程序经过众多被称为“服务”的小型基本单元加以重组，从而大幅提高对亚马逊总体业务的扩展能力。

可是，变革应用程序架构只是故事的前一半。至于后一半……当时是 1998 年，亚马逊内部的各个开发团队都在使用相同的应用程序，所以每位员工都必须针对其当前版本进行跨团队协调。

为了支持这种新型架构，咱们分解了功能层级结构，并将企业组织从新编排为小型自治团队——小到每次点餐只须要两份披萨。咱们将这些“双披萨团队”委派到不一样的特定产品、服务或者功能集上，赋予他们对应用程序内特定部分的更多操做权限。这使得咱们的开发人员成为产品全部者，并可以根据本身的决策迅速对个别产品产生影响。

拆分咱们的组织与应用程序结构无疑是个大胆的想法，但同时也是个行之有效的好主意。咱们得以更快地为客户提供创新成果，并且随着亚马逊的快速发展，咱们已经从每一年部署数十项功能发展为现在部署数百万项。更使人始料未及的是，咱们在构建这种高度可扩展基础设施方面得到的成功，最终促成了另外一大核心竞争力的发展与壮大——这就是 2006 年诞生的 AWS。

而咱们，现在仍在坚持双披萨团队这一基本建制。

固然，咱们毫不是惟一一家强调创新的公司。为了保持竞争力，亚马逊必须不断提升敏捷性，从而持续发现新的机遇并创造出更好的产品。也正由于如此，才会有愈来愈多的客户踏上与亚马逊当年相同的旅程，并转向现代应用程序开发。这种新方法须要从总体式架构迁移至更小的基本单元——或者说“微服务”，并且除此以外，现代应用程序的最佳实践还要求在改变设计与构建技术之余，从新考虑其管理方式。

为了成功提高应用程序开发当中的敏捷性与创新速度，组织必须根据适合自身的顺序采用如下五大元素：微服务、专用数据库、自动软件发布流水线、无服务器运营模式以及持续自动化安全保障。

1架构模式：微服务

像亚马逊这样的大多数企业最初都是以总体式应用程序做为业务基础，由于这是一类开发速度最快、难度最低的系统。可是，这种将各个进程紧密组合并做为单一总体服务的做法，每每会带来一系列严重问题。若是应用程序中的某个进程遭遇需求高峰，咱们只能扩展总体架构才能实现单个进程的扩容。

另外，随着代码库规模的增加，功能的添加与改进也开始变得很是复杂，这让企业很难试验以及实现新的想法。总体式架构还增长了应用程序的可用性风险，由于大量相互依赖且紧密耦合的进程会增长单一进程因故障受到的影响。

这就是微服务架构随企业发展而出现的缘由所在。利用微服务架构，应用程序将由众多独立组件构成，这些组件将各个应用程序的进程以单一服务形式运行。服务将专为业务功能而构建，例如在线购物车，并且每项服务只负责本身的一项功能。这些进程独立运行并由对应的一支开发团队负责管理，所以咱们能够对各服务进行独立更新、部署与扩展，最终知足对应用程序特定功能的需求。举例来讲，当出现用户购买峰值时，咱们能够单纯扩容购物车服务以强化承载能力。

随着组织由总体式架构逐步转向微服务架构，不少开发人员也但愿经过流水线管理各项服务中的依赖关系——这就要求咱们创造出新的方法以实现应用程序打包与代码运行。好消息是，凭借着强大的创新成果储备，现在实例已经再也不是咱们的惟一计算选项。

你们也可使用容器或者 AWS Lambda 函数。容器是目前最受欢迎的代码打包选项，同时也是实现遗留应用程序现代化的最佳工具之一。容器技术，为咱们带来出色的应用程序可移植性与设置灵活性。而利用 Lambda，你们则可以更轻松地获取所需功能——利用代码编写出业务逻辑便可。

微服务架构的另外一大需求，在于咱们必须为之创建一种服务间的相互通讯方式。目前大部分应用程序都继续沿用 API 链接，但也有一些选择在不一样服务之间发送数据。具体包括用于实时数据处理的流、用于根据数据变化触发响应的事件，以及用于应用级通讯及可见性的服务网格等等。你们能够根据自身需求选择最适合本身应用程序的集成方法。

2数据管理：专用数据库

现代应用程序采用解耦式数据存储机制，其中微服务与数据库一一映射，意味着咱们再也不须要维持一套庞大的总体数据库。这也是对传统应用程序的一大重要革新，旨在解决总体式应用程序随规模增加而遭遇的扩展性与容错性难题。此外，单一数据库同时也表明着单点故障源，并且很难知足一组不一样微服务提出的特定需求。经过将数据与微服务剥离，咱们能够自由选择最适合自身需求的不一样数据库类型。

对于大部分应用程序，最佳选项仍然是关系数据库；但也有其它一些应用程序有着不一样的数据需求。例如，若是咱们运行的是使用高度链接型数据集的应用程序（例如推荐引擎），则能够选择具有存储与导航关系的图数据库，例如 Amazon Neptune。

或者，若是您的应用程序须要实时访问数据，也能够选择 Amazon ElastiCache 等内存内数据库，其经常使用于游戏以及物联网应用场景。通常来讲，可以充分知足您微服务需求的数据库，就是最理想的数据库选项。

3软件交付：自动发布流水线

咱们当初告别总体式架构并重组为双披萨团队时，自动发布流水线也就应运而生。这是为了摆脱本来的单一版本发布通道，容许各个团队独立交付本身的开发成果。

虽然这种新方式消除了更新的开发与交付等协调性挑战，但同时也给咱们带来了很多新的难题。首先，维持所有团队的发布流程与质量一致性变得很是困难。特别是考虑到发布流程中的每一个步骤都在以手动方式完成，这无疑会大大增长产生人为错误的可能性。

咱们的解决方案采起左右开弓的方式：标准化加上自动化。首先，咱们将软件交付流程定义成最佳实践模板，旨在为云环境下的一切基础设施资源的建模与配置提供标准。这些“基础设施即代码”模板可以帮助咱们的团队从正确之处起步，由模板经过代码为应用程序提供总体技术堆栈，而再也不依赖于手动过程。在亚马逊，这种做法确保了各个团队都可以根据咱们的要求实现对流程与部署的配置。

第二点，咱们开始利用自动化技术将手动流程从软件交付流水线中剔除出去。在自动化发布流水线的帮助下（包括持续集成与持续部署，简称 CI/CD），咱们得以快速测试并发布大量代码，同时最大限度减小错误机率。经过 CI，咱们的团队会按期将代码变动整合至同一套中央库内。然后，咱们会对其运行自动构建与测试，以确保可以尽早发现问题。而利用 CD，咱们的团队天天能够屡次提交变动，且无需任何人为干预便可将成果投入生产。

起初，咱们发现去掉人为干预只会带来至关糟糕的部署后果。可是，咱们投入了大量时间编写正确的测试与故障解决方案，并最终发现新体系大大提升了咱们的速度与敏捷性，同时也显著加强了代码质量。

4运营模式：尽量采用无服务器模式

现代应用程序当中包含大量活动部件。现在的现代应用程序每每由数千项服务组成，这远远超出了以往单一应用程序与数据库的范畴，并且每一项服务背后都对应着一套专用数据库外加一支负责不断发布新功能的团队。

这些活动部件能够分为如下两类：

• 做为企业“独门绝技”的活动组件，负责保障业务成功，例如可以创造独特用户体验与开发创新产品的部分。

• 一般被咱们称为“无差异承载性”活动组件，这些活动必须完成，但自己没法提供任何竞争优点。对于大多数企业来说，此类任务包括服务器管理、负载均衡以及安全补丁应用等等。

咱们在 2014 年提出了“无服务器”概念，并同时发布了 AWS Lambda。AWS Lambda 是一种计算服务，可以帮助你们在无需配置或者管理服务器的前提下运行代码。这种能力支撑起咱们的整体目标，即经过将无差异任务交给 AWS 负责以帮助客户专一于优化本身的“独门绝技”。事实上，这一切已经成为现代应用程序开发中的关键性元素。无服务器模式使你们解放精力，将更多时间投入到真正让您的业务不同凡响的方面——例如产品创新。

当咱们提及“无服务器”时，咱们指的是在无需分神于基础设施配置或者扩展的状况下运行的服务，其具备内置的可用性与安全性保障，且采用按使用量计费的方式。无服务器不仅有 Lambda，它是一套完整的应用程序堆栈。

应用程序堆栈一般由如下三大要素组成：

• 像 AWS Fargate 这样的计算服务，用于运行应用程序逻辑

• 像 MySQL 以及 PostgreSQL 关系数据库这样的数据存储方案，也可使用 Amazon Aurora 等实现数据的持久驻留

• 相似于事件总线 Amazon EventBridge 这样的集成层，用于实现数据移动

这些无服务器构建单元使企业可以打造出充分发挥无服务器模式优点的应用程序。

在亚马逊，咱们本身也尚未彻底实现无服务器化，但咱们正在朝着这个方向努力。实际上，咱们认为很快就会出现一整代只负责编写业务逻辑、而从未接触过服务器的开发人员。这里的缘由很简单，不管您是在构建全新应用程序仍是迁移旧有应用程序版本，使用无服务器原语进行计算、数据处理以及集成，都能确保你们从云环境提供的敏捷性优点中获取最佳收益。

5安全性：每一个人都有责任

过去，不少企业都把安全视为一种神奇的“调味料”——在应用程序准备好发布以后，再匆匆撒上一把。但这种方式在持续发布周期中显然会水土不服，所以组织必须采起新的安全方法，围绕整个应用程序构建起防火墙。但这一样带来新的挑战：以往咱们只须要为总体式应用程序创建一种安全设置；但面对微服务架构中成千上万的独立进程，以往的安全思路根本解决不了问题。

有鉴于此，在现代应用程序当中，咱们将安全功能内置于应用程序的各个组件以内，并随着每一个版本进行自动测试与部署。这意味着安全性再也不是安全团队本身的责任——相反，安全深深融入到开发生命周期的每一个阶段，而工程、运营以及合规团队都将在其中发挥本身的做用。

安全性将被整合至代码库、build 管理程序乃至部署工具当中。这既适用于发布流水线自己，也一样适用于经过该流水线发布的软件。并且在使用无服务器服务的状况下，安全状态的维护难度更低，这是由于底层基础设施的安全运营工做——包括系统版本更新、软件修复与监控等——都之内置形式存在于各项服务当中。

6现代化之旅

那么，众多客户是如何实施这些变动，从而推进应用程序现代化的？必须认可，其中不存在统一的路径，但却有着很多常见的模式，也包括咱们在亚马逊采起的方法。

当咱们决定专一于创新并大幅扩展 Amazon.com 时，咱们重构了总体式应用程序，对组织结构进行从新编排，然后利用自动化与抽象化两大手段推进云资源优化。Yelp 等客户也采起了相似的现代化转型方式。

对于之内部托管应用程序做为起点的客户，最多见的方法天然是从新托管，即“将应用程序直接迁移至云端”。在此以后，不少客户开始进一步探索云环境中的托管服务，尝试将数据库与 API 管理等任务迁移至 AWS，从而保证将本身的工做重心放在业务逻辑身上。

现在，愈来愈多的客户踏上了从新发明的道路，将新的应用程序构建为无服务器微服务形式，旨在充分发挥云服务优点。现代化没有统一的正确方法，由于在 AWS 平台上，各类各样的应用程序都可以以不一样的状态共存，并经过任意路径实现成功交互。

但咱们也在其中看到了重要的共通点，即构建现代应用程序的客户可以审视自身总体业务优点，特别是对时间与资源的优化分配。他们将更多时间花在定义业务逻辑上，扩展系统以轻松知足高峰期客户需求，提升敏捷性，同时更快、更频繁地向市场发布新功能。

以向汽车买家提供最新车辆信息的 Edmunds.com 网站为例，他们将新功能的推出时间由六个月缩短至一周。初创企业 Bynder 公司也将产品上市周期由本来的一年减小至一个月。经过改变对技术的运用方式，企业可以显著改善本身的业务交付途径以及相关体验。

而这，正是现代应用程序的力量所在。

 

原文连接：https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html