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

Werner Vogels 博士

亚马逊全球 CTO 兼副总裁

关键词：便捷性、敏捷性、无服务器

Amazon Web Services的现代应用程序

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

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

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

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

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

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

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

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

架构模式：

微服务

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

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

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

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

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

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

数据管理：专用数据库

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

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

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

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

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

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

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

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

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

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

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

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

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