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

亚马逊云开发者

已于 2023-03-02 16:35:36 修改

阅读量609

点赞数

文章标签：数据库物联网微服务亚马逊云科技 Powered by 金山文档

于 2023-02-26 08:44:54 首次发布

本文链接：https://blog.csdn.net/awschina/article/details/129221176

版权

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 以帮助客户优化自己的“独门绝技”，同时全面实现应用程序的现代化进程。在完成无服务器革新之后，企业能够将资源集中投入到产品创新等有助于建立市场优势的工作当中。