住房城乡建设部门户网站烟气脱硫,河北网站建设推广公司,常州城乡和住房建设厅网站,二级域名格式Amazon Web Services 的现代应用程序创新一直是 Amazon 公司坚持追求的核心目标。约20年前#xff0c;我们经历了一次彻底的转型#xff0c;旨在建立起“发明、发布、再发明、再发布、重新开始、洗牌、再重复”的快速迭代流程。正是此番探索#xff0c;彻底改变了我们构建应…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/column/article/62b452ad849b456b98432b50?sc_channelCSDN
