正确的提示信息

扫码打开虎嗅APP

从思考,到创造
GO!
搜索历史
热搜词
2020-02-18 11:18
亚马逊快速创新的秘密之一

这是一篇货真价实的大软文,作者是亚马逊现任 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

本内容为作者独立观点,不代表虎嗅立场。未经允许不得转载,授权事宜请联系 hezuo@buywinonLine.com
打开虎嗅APP,查看全文

支持一下

赞赏

1人已赞赏

热 文 推 荐

好的内容,值得赞赏

您的赞赏金额会直接进入作者的虎嗅账户

    自定义
    支付: