转载

亚马逊如何从单体中台转变到微服务? - All Things Distributed

像亚马逊这样的大多数公司都是以单体(中台)方式开展业务,因为它是最快,最容易开发的系统。但是,将进程紧密组合并将它们作为单个服务运行是存在问题的,如果一个中台应用进程遇到需求高峰,则必须扩展整个架构以处理该一个进程的负载。

此外,随着代码库的增长,添加和改进功能变得更加复杂,使得难以试验和实现新想法。单片中台架构也增加了应用程序可用性的风险,因为许多依赖和紧密耦合的进程会增加单个进程故障的影响。

这就是微服务随着公司发展而出现的原因。使用微服务架构,应用程序由独立组件组成,这些组件将每个应用程序的进程作为服务运行。服务是为业务功能而构建的。

例如在线购物车,每个服务都执行单一功能。它独立运行并由单个开发团队管理 ,因此可以独立更新,部署和扩展每个服务,以满足对应用程序特定功能的需求。例如,购物车可以在销售时支持更大量的用户。

随着组织从单块服务转向微服务,许多开发人员发现他们希望通过管道管理每个服务中的依赖关系 - 他们必须创建打包应用程序和运行代码的新方法。由于这些创新,实例不再是您唯一的计算选项。

容器是打包代码最受欢迎的选项,也是遗留应用程序现代化的绝佳工具,因为它们提供了出色的可移植性和应用程序设置的灵活性。使用Lambda,您可以获得最简单的功能。您编写的唯一代码是业务逻辑。

微服务的另一个考虑因素是它们需要一种相互通信的方式。许多应用程序继续使用API​​连接,但是还有其他几种用于在服务之间发送数据的选项。这些包括用于实时数据处理的流,用于触发对数据变化的响应的事件,以及用于应用级通信和可观察性的服务网格。您可以选择最符合您的应用程序需求的集成方法。

数据管理:专用数据库

现代应用程序使用分离的数据存储构建,其中存在数据库和微服务的一对一映射,而不是单个数据库。这是传统应用程序架构的一个重要转变,因为正如单个应用程序随着它的增长而出现扩展和容错挑战,数据库也是如此。此外,单个数据库是单点故障, 单个数据库很难满足一组不同微服务的特定需求 。通过将数据与微服务分离,您可以自由选择最适合您需求的数据库。

软件交付:自动发布管道当我们离开Amazon.com的整体架构并重组为两个披萨团队时,我们停止使用单一版本管道并开始让每个团队独立发布。

虽然这消除了制作和提供更新的协调挑战,但分散我们的开发和发布流程带来了一系列新挑战。维护所有团队的发布流程和质量一致性变得困难,特别是当发布流程的每个步骤都是手动的时候,这就产生了人为错误的可能性。

我们的解决方案是双管齐下的:标准化和自动化。首先,我们将软件交付流程定义为最佳实践模板,为在云环境中建模和配置所有基础架构资源提供标准。这些“基础架构作为代码”模板可以帮助我们的团队正确开始,因为模板通过代码为应用程序提供整个技术堆栈,而不是使用手动过程。在亚马逊,这可确保团队根据我们的要求配置其流程和部署。

其次,我们已开始使用自动化从软件交付工作流程中删除手动流程。借助自动发布管道,包括持续集成和持续部署(CI / CD),我们可以快速测试和发布大量代码,同时最大限度地减少错误。通过CI,我们的团队会定期将代码更改合并到一个中央存储库中。然后我们运行自动构建和测试,以便我们尽早发现问题。使用CD,我们的团队每天多次提交更改,无需任何人工操作即可投入生产。

起初,我们发现没有人为干预的部署是可怕的。但是在我们花时间编写正确的测试和故障保险后,我们发现它不仅大大提高了我们的速度和灵活性,还提高了代码的质量。

运维模式:尽可能无服务器

现代应用程序有很多活动部件。现代应用程序可以由数千个服务组成,而不仅仅是单个应用程序和数据库,每个服务都有一个专用数据库和一个不断发布新功能的团队。

这些运动部件可分为两类:

  • 作为公司“秘密酱”的一部分的活动,使其在市场上取得成功,例如创造独特的用户体验和开发创新产品。
  • 我们经常称之为“无差别的重举”的活动,这些活动必须完成,但不能提供竞争优势。对于大多数企业而言,这些任务包括服务器管理,负载平衡和应用安全补丁等。

我们在2014年推出了“无服务器”概念,推出了 AWS Lambda ,这是一种计算服务,可让您在不配置或管理服务器的情况下运行代码。这支持了我们的总体目标,即通过将无差别的任务卸载到AWS来帮助客户优化其秘密资源的资源,并已成为现代应用程序开发中的关键元素。无服务器使您可以专注于使您的公司与众不同的活动,例如产品创新。

当我们说“无服务器”时,我们指的是在不需要基础设施配置和扩展的情况下运行的服务,具有内置的可用性和安全性,并使用付费价值计费模型。无服务器不只是Lambda - 它是整个应用程序堆栈。

应用程序堆栈通常由三个组件组成:

  • 像AWS Fargate这样的计算服务来运行应用程序逻辑
  • 数据存储,如MySQL和PostgreSQL关系数据库,或Amazon Aurora,用于保存数据
  • 像事件总线Amazon EventBridge这样的集成层来移动数据

这些无服务器构建块使公司能够构建最大化无服务器模型优势的应用程序。

在亚马逊,我们自己并不是完全没有服务器,但我们正朝着这个方向前进。许多客户也是如此。实际上,我们预计很快就 会有一整代开发人员从未接触过服务器而只编写业务逻辑 。原因很简单。无论您是构建新的全新应用程序还是迁移旧版本,使用无服务器原语进行计算,数据和集成都可以使您从云提供的最大敏捷性中受益。

总结

构建现代应用程序的客户可以看到整个业务的优势,特别是他们如何分配时间和资源。他们将更多时间花在定义业务的逻辑上,扩展系统以轻松满足高峰客户需求,提高灵活性,并更快,更频繁地向市场提供新功能。

例如,向汽车购物者提供最新车辆信息的 Edmunds.com 将新网站功能的推出时间从六个月减少到一周。创业公司 Bynder 还将产品上市所需的时间从一年减少到一个月。通过改变他们接近技术的方式,公司可以改善他们开展业务的方式。

这是现代应用的力量。

原文  https://www.jdon.com/53071
正文到此结束
Loading...