速来～与 Werner Vogels 博士一起探索敏捷性与创新速度一起提升的秘方

Amazon Web Services 的现代应用程序

创新一直是 Amazon 公司坚持追求的核心目标。约 20 年前，我们经历了一次彻底的转型，旨在建立起“发明、发布、再发明、再发布、重新开始、洗牌、再重复”的快速迭代流程。正是此番探索，彻底改变了我们构建应用程序乃至组织企业结构的根本方式。

那时候，Amazon 服务的群体在规模上远远不及当下。但我们很清楚，要想不断扩展 Amazon 的产品与服务，就必须改变应用程序架构的设计思路。

我们曾经为 Amazon.com 建立起庞大的单体式“bookstore”应用，但与之关联的笨拙数据库限制了我们的速度与敏捷性。每当我们打算为客户提供新的功能或产品（例如视频流），就被迫得在专门为 bookstore 设计的应用程序上编辑并重写大量代码。这个过程漫长且繁琐，需要复杂的协调沟通，因此严重拖累了我们快速推动大规模创新的能力。

为此，我们通过“分布式计算宣言”建立了变革蓝图。通过这份用以描述新架构的内部文档，我们决定将应用程序重组为更小的部分，即“服务”，并借此大幅提升 Amazon 的可扩展性。

但应用程序架构的变革还只是开始。从 1998 年时开始，各个 Amazon 开发团队就一直在同一款应用程序之上工作，因此这款应用的每个发行版本都必须在各团队间统一协调。

为了支持新的架构方法，我们对其功能层级进行分解，并将组织重新整合成多个小型自治团队。各团队的体量很小，只要订两块披萨就能解决一顿饭，这就是所谓“双披萨团队”。每支团队只关注特定的产品、服务或者功能集，这就让他们获得了对应用程序中特定部分的更高操作权限。如此一来，开发者们摇身一变成为产品所有者，能够迅速做出影响各自产品的具体决策。

此番重整组织与应用程序结构无疑是个大胆的计划，好在 Amazon 获得了良好的收效。我们能够更快为客户提供创新成果，并随着自身业务的发展而将每年部署的功能总量由数十项，快速发展为数百万项之巨。更值得一提的是，我们在构建高度可扩展基础设施领域的卓越成功，最终衍生出了新的核心业务能力，这就是 2006 年正式亮相的 Amazon Web Services。

如今，我们仍然在坚持双披萨团队的运作模式。我们的目标并不仅仅是追求快速创新。为了保持全面的市场竞争力，我们还需要提高敏捷性，以便不断发现新的机遇并创造更好的产品。秉持着相同的理念，越来越多客户与 Amazon 踏上了相同的发展旅程，全面转向现代应用程序开发道路。这种新方法要求组织由已经非常熟悉的单体式架构转向组件或微服务架构，而这一切影响到的不只有技术的设计与构建方式，更要求我们重新审视自己的管理思路。

亚马逊云科技开发者社区为开发者们提供全球的开发技术资源，这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！

为了让应用程序开发成为敏捷性与创新速度的重要驱动力，组织必须关注五大关键要素：微服务、专用数据库、自动化软件发布管道、无服务器运营模型、外加持续自动化安全体系。

架构模式：微服务

像 Amazon 这样的企业最初大多是从单体式应用程序起步，因为这是当时开发速度最快、复杂度最低的系统架构选项。但是，紧密组合的各个流程迫使我们必须将应用程序看成统一的整体，由此带来无数令人头痛的难题。如果应用程序中的某一进程遇到需求高峰，我们就得扩展整个架构才能消化掉该进程的相应负载。

此外，随着代码库体量的提升，新功能的添加与改进变得越来越复杂，导致我们难以尝试或实施新的方法。单体式架构也增加了应用程序的可用性风险，其中众多相互依赖且紧密耦合的进程会显著放大单一进程故障引发的影响。

正因为如此，微服务架构随着企业的发展而自然出现。使用微服务架构，应用程序将由无数独立组件构成，各个组件会将应用程序中的各独立进程视为单一服务。每项服务对应且仅对应一种业务功能，例如在线购物车。这种独立运行以及由专项团队负责的设计，让企业得以轻松更新、部署及扩展各项服务，借此满足应用程序提出的具体功能需求。例如，我们可以在销售旺季扩展购物车服务以支持更多用户。

随着组织由单体式服务转向微服务，不少开发人员希望通过管道来管理不同服务中的依赖项，同时寻求新的应用程序打包与代码运行方法。面对这些硬性需求，计算实例长期以来的统治地位开始有所动摇。

如今，我们可以使用容器或者 Amazon Lambda 函数。容器已经成为目前最具人气的代码打包选项，也凭借着出色的应用程序可移植性与运行灵活性成为管理遗留应用程序的最佳工具。而使用 Lambda，您将获得出色的便捷性——除了核心业务逻辑之外，大家再不必编写任何其他代码。

另外需要强调的是，微服务架构包含的大量微服务，给服务间通信带来了新的挑战。一部分应用程序继续沿用 API 连接，但除此之外还有更多用于服务间数据交换的选项，例如用于实时数据处理的流传输、用于根据数据变更触发响应的事件，以及用于应用级通信与可观察性的服务网格等等。不同的选项各有优劣，大家需要根据应用程序的实际需求做出取舍。

数据管理：专用数据库

现代应用程序以解耦数据存储构建而成，不同于以往全面依赖同一套大型数据库的方式，微服务架构中的数据库与微服务保持着一一映射的关系。以往单体式应用程序的整体增长，必然带来扩展与容错层面的严峻挑战。此外，单体数据库必然引发单点故障，而且同一数据库很难满足一组不同微服务的需求。而随着数据与微服务间的脱钩，大家可以更自由地选择最适合自己的具体数据库方案。

对于大部分应用程序，最好的选项仍然是经典的关系数据库。但也有不少应用程序会提出自己的数据需求。例如，假定您所运行的应用程序需要处理高度关注的数据集——例如推荐引擎——那么不妨选择图数据库（例如 Amazon Neptune）用以存储并导航关系数据。

或者，如果您的应用程序要求实时访问数据，则最好选择内存内数据库，例如 Amazon ElastiCache。这种数据库特别适用于游戏及物联网应用程序。总之，哪种数据库能够全面满足您的微服务需求，哪种就是最好的选择。

软件交付：自动发布管道

在由 Amazon.com 单体式架构转向双披萨团队的过程中，我们关停了单一发布通道，转而允许各个团队独立发布自己的功能与产品。

虽然这种方式消除了交付与更新流程中的协调难题，但也让新的流程变得极度分解、难以掌控。很明显，在全部团队的发布流程与质量水平方面保持统一变得无比艰难，而发布流程中大量的手动操作也让发生人为错误的几率显著提高。

我们的解决方案包含两大基本元素：标准化与自动化。

首先，我们定义一套关于软件交付流程的最佳实践模板，用于为云环境下基础设施资源的建模与配置设定标准。这些“基础设施即代码”模板为各个团队提供良好的起点，以代码取代手动流程的方式为应用程序提供技术堆栈。在 Amazon，这种方式将保证各个团队都根据统一的要求规划流程与部署工作。

其次，我们使用自动化技术消除软件交付流程中的手动操作环节。凭借包括持续集成与持续部署（CI/CD）在内的自动化发布管道，我们得以快速测试并发布大量代码，同时尽可能减少错误几率。借助持续集成，我们的团队地定期将代码变更合并至中央 repo 当中，而后运行自动化构建与测试以尽早发现问题。借助持续部署，我们的团队每天可以完成多轮变更，并在保证变更有效后将其自动添加至生产环境当中。

最初，我们发现在不加人为干预的前提下推进部署相当“恐怖”。但在投入时间建立起正确的测试与故障处理机制后，最终成果不仅大大提升了 Amazon 的运作速度与敏捷性，同时也显著增强了代码质量。

运营模型：尽可能推广无服务器模式

现代应用程序中包含大量活动部件，不同于传统的单体式应用程序与数据库，其中还存在成千上万项服务。每一项服务都有自己的专用数据库，外加一支持续发布新功能的自主团队。

我们可以将这些活动部件分为以下两类：

• 企业自己的独门绝技，例如创造出独特的用户体验或开发出前所未有的创新产品。

• “无差别繁重工作”，即必须完成但却无法提供任何竞争优势的任务。对大多数企业而言，这类任务可能涵盖服务器管理、负载均衡与应用安全补丁等内容。

2014 年，随着 Amazon Lambda 的推出，我们提出了“无服务器”这一概念。Amazon Lambda 是一种计算服务，可帮助客户在运行代码的同时，无需置备或管理任何服务器。这也极大支持了我们的总体目标，即通过将未经区分的任务移交给 Amazon Web Services 以帮助客户优化自己的“独门绝技”，同时全面实现应用程序的现代化进程。在完成无服务器革新之后，企业能够将资源集中投入到产品创新等有助于建立市场优势的工作当中。

这里所说的“无服务器”，是指无需配置及扩展基础设施即可运行的服务。无服务器架构具备内置可用性与安全性保障，并采用按实际使用量付费的模式。无服务器不仅限于 Lambda，而是涵盖整个应用程序堆栈。

应用程序堆栈通常包含以下三个部分：

• Amazon Fargate 等计算服务，用于运行应用程序逻辑。

• MySQL 与 PostgreSQL 等关系数据库提供的数据存储方案，或者 Amazon Aurora 等数据持久存储服务。

• 集成层，例如用于管理数据移动的 Amazon EventBridge 等事件总线。

这些无服务器构建单元，将帮助企业在应用程序中实现无服务器模式的最大化收益。

在 Amazon，我们还没有全面普及无服务器模式，但已经在朝着这个方向努力。我们的很多客户也走在同样的探索道路之上。也许在不久的未来，下一代开发人员再也不必接触服务器，而仅仅需要编写业务逻辑。

到那个时代，无论是构建新型 Web 应用还是迁移旧有应用，我们都可以使用无服务器原语实现计算、数据与集成，由此保证企业充分发挥云计算的敏捷性优势。

安全性：人人有责

以往，很多企业将安全性视为一种“魔术”——在即将发布的应用上修修补补，然后听天由命。但在持续发布周期中，这种原始的方法显然无法奏效，组织必须采用新的安全方法以围绕应用程序构建起完善的防火墙。但这同样带来新的挑战，毕竟各项微服务往往有着天差地别的特性与需求，为其分别设定安全配置将带来巨大的工作压力。

为此，在现代应用程序当中，安全功能被内置在应用的各个组件之内，并随着每个发行版本完成自动测试与部署。如此一来，安全不再是安全团队的专属责任；相反，安全保障深入集成到开发生命周期的各个阶段，并要求工程、运营与合规团队参与贡献自己的力量。

具体来讲，安全保障将被集成在代码 repo、构建管理程序以及部署工具之内，同时服务于发布管道本身与通过该管道发布的软件成果。

借助无服务器模式，由于每项服务都内置有基础设施安全要素（例如操作系统版本更新、软件修复与监控等），因此极大降低了安全状态的维护难度。

探索之旅

那么，客户是如何实际推进这种架构变革，最终实现应用程序现代化的？这个问题没有统一的答案，但我们可以在这里分享一点 Amazon 亲身总结出的共通性经验。

当初决定专注创新并大幅扩展 Amazon.com 的时候，我们一步步完成了应用程序重构、组织结构重组、外加针对云环境的自动化与抽象优化等工作。以 Yelp 为代表的不少 Amazon Web Serviecs 用户也采取了类似的过渡方式。

如果您以往是在本地设施内托管应用程序，那么最常规的方法应该是选择“直接迁移”的方式将应用程序重新托管至云端。以此为基础，客户们开始逐渐熟悉云端的托管服务，尝试将数据库与 API 管理等工作迁移至 Amazon Web Services，并将解放出的资源与人力集中在开发业务逻辑身上。

如今，越来越多的客户开始重塑自己的发展道路，包括将新应用构建为无服务器微服务形式，借此提升对云优势的使用能力。必须承认，并不存在侱正确的现代化方法；您应该结合自身实际情况，稳扎稳打地探索 Amazon Web Services 上的成功之路。

但至少有一点可以肯定：通过构建现代化应用程序，客户的整个业务体系都将获得收益，特别是改善时间与资源的分配能力。他们能够把更多精力投入到定义业务逻辑当中、扩展系统以轻松满足峰值客户需求、提高业务敏捷性，并更快更频繁地发布更多新功能。

例如，专注于发布车辆信息的 Edmunds.com 网站就将新功能的发布周期由以往的六个月缩短至一个星期 。初创企业 Bynder 则将产品上市时间由一年缩短至一个月。在这个以技术为主导的新时代，对技术运用的能力将直接影响业务的运作方式。

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

文章来源：https://dev.amazoncloud.cn/column/article/62b452ad849b456b98432b50?sc_channel=InfoQ