共计 5133 个字符，预计需要花费 13 分钟才能阅读完成。
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/co…
