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 则将产品上市时刻由一年缩短至一个月。在这个以技能为主导的新年代，对技能运用的才能将直接影响事务的运作办法。
而这全部，正是现代化运用程序的力量所在。
文章来源：dev.amazoncloud.cn/column/arti…
