应用架构的演进:亚马逊的微服务实践

当你在亚马逊上购物时,或许不会想到,你看到的这个购物网站,其背后技术架构经历了什么样的变迁与升级。

还记得上世纪 90 年代,那个只卖书的网上书店吗?那时的亚马逊,不过是一个架构简单的网站,所有的功能都堆积在一个庞大的软件堡垒里。随着更多业务的增加、更新和迭代,这个软件堡垒愈发臃肿,扩展和维护变得非常困难。亚马逊意识到,单体架构已经严重影响到业务的发展。于是,决定将这个大堡垒拆分成小城堡,每个城堡通过通信接口互联,各自负责一个业务功能。

亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术,观点,和项目,并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏,看到这里请一定不要匆匆划过,点这里让它成为你的技术宝库!

这就是微服务架构的雏形。小城堡比大堡垒更容易扩展和维护,但运营成本也提高了。

于是亚马逊又有了新的想法:既然 cloud 可以提供无限的计算资源,为什么我们还要自己搭建并运营这些小城堡呢?无服务器架构应运而生,开发者只需要编写并上传代码,剩下的服务器运维完全交给云平台。

从单体、到微服务、再到无服务器,亚马逊架构的演变可谓曲折,但每一次转变都让业务更加灵活。本文将通过一个具体的案例分享从单体,到微服务,再到无服务器,应用架构的演进都经历了哪些技术模式。之后,我们将一起深入探讨微服务和五服务器这两种新型架构,借助亚马逊的实践分析如何帮助企业应对数字化浪潮,从根本上构筑起业务的弹性。

单体构架应用系统的痛

应用架构的演进:亚马逊的微服务实践_第1张图片

这是一个在线点单系统,我们称他为 FTGO。FTGO 是一个典型的企业级 Java 应用程序,此时 FTGO 是一个单体应用架构,它由多个业务模块所组成:餐厅管理,订单管理,交付管理,账单管理,付款管理,以及消息管理。所有的服务集成在一起,共用一个数据库。围绕业务模块的是各种适配器。前端通过 REST API,WEB UI 适配用户各种终端的处理请求。后端的适配器,如用于支付、消息、邮件系统提供接口,与外部的系统集成。 在 FTGO 初期,当应用程序相对较小的时候,单体架构体现了一些优势:

  • 开发简单—IDE 和其他开发工具都专注于构建一个单独的应用程序;
  • 运维简单—开发人员可编写端到端的测试, 用于启动测试程序, 调用 REST API 并使用 selenium 进行 UI 测试
  • 部署简单—开发人员需需要将 WAR 文件复制到安装了 Tomcat 的服务器上即可。

但是很快,开发人员就发现了这个单体架构的应用有着巨大的局限性。业务的增长,需要 FTGO 不停的更新和迭代新的功能,于是研发团队不断扩充,代码库日趋庞大,应用架构变得越来越复杂。这个给运维管理带来了新的难题:
应用架构的演进:亚马逊的微服务实践_第2张图片

开发团队因为系统的复杂性受到了限制。在这样一个单体应用架构中,对于开发者来说 FTGO 的架构显得非常复杂和笨重,很难全部搞明白。于是无论是修复 bug,还是部署新功能都显得异常困难。应用的复杂性还表现在单一的代码库也变得越来越巨大。每一次变更都会让这个单一的代码库变得更加复杂,这给开发者全面理解代码带来困难,不能很好的理解代码,就无法保证每次变更的正确性。

生产效率降低。任何变更的部署都需要重新构建整个应用程序,运行所有测试套件以确保没有任何回归,并重新部署整个应用程序。即使只是对自己拥有的一小段代码进行单行更改,你仍然需要通过这个重量级流程。在单体应用架构时代,亚马逊有一个中央团队,其唯一的工作就是将这个单体应用程序部署到生产中。

沟通和协作成本高。开发人员通过共享的发布管道推动变更,这就会在生命周期的许多环节产生摩擦。任何一个变更,开发人员都需要大量的团队协调工作,来确保他们所做的变更不会影响别人的代码。 如果你想升级共享代码库以利用新功能,你需要说服其他人同时升级--祝你好运!如果你想为自己的功能快速推送一个重要的修复,你仍然需要将它与其他人正在进行的修改合并。经历过单体架构的工程师们都知道 "合并周五"吧?或者更糟糕的 "合并周"。当你通过交付管道推送变更时,变更需要在队列中等待手工测试的完成。对于一家努力创新和竞争的快速成长型公司来说,这种开销和迟缓是不可接受的

应用的微服务架构

当单体变得过大而无法有效扩展时,我们就需要做些改变。比如拆分成微服务。

应用架构的演进:亚马逊的微服务实践_第3张图片

这是一个典型的微服务应用架构。我们可以看到:

  • 微服务架构隐藏了内部实现细节,在不改变整体应用架构的前提下,我们可以独立变更和部署每个微服务,来提高灵活性和速度。单个服务的变更,不会对用户产生影响。这解决了服务升级带来的业务影响和服务体验,同时也避免破坏性变更,提高了可靠性。
  • 微服务相互协作通过 API 暴露和网络通信,每个服务都可以独立扩展,你不需要一台大机器(或几台),多个虚拟机或容器就可以完成工作,每个微服务只负责自己的领域(减少代码中的耦合),每个微服务都有自己专用的数据库(没有数据耦合)。API 和网络通信实现了服务的解耦,并支持自动化。
  • 作为开发人员,理解微服务比理解整个单体服务容易的多,这促进了新技术的产生,提高了业务的敏捷性。

微服务之间的集成非常重要,有3种关键模式:

  • API 驱动模式
  • 事件驱动模式
  • 数据流模式

如果集成做好了, 微服务可以保持自治性。应用的向微服务架构改变,同时带来开发组织的改变:

  • 团队解耦,更小的团队独立架构、开发、部署和维护每个微服务,他们可灵活的选择工具来高效地自行发布。
  • 所有权是关键--每个团队服务都有一个所有者。所有者负责架构,所有者负责实施,所有者负责在生产中提供支持,所有者负责修复问题,所有者负责维护。
  • DevOps 原则--自动设置, 开发人员拥有生产支持.

应用架构的演进:亚马逊的微服务实践_第4张图片

微服务带来开发组织架构调整的前行者是亚马逊。

为了进一步提高业务的敏捷性,亚马逊将研发团队拆分成若干个“两个 pizza 可以喂饱的”小团队,每个“双 pizza 团队”都对其服务拥有完整的所有权和全部的责任。这意味着赋予团队自主决策的权力,然后信任他们对决策结果负责。如今,很多人将这种方法称为 DevOps,意思是让同一个团队同时负责服务的开发和运维。通过构建这种高度自治和负责任的小型团队,企业可以实现产品和技术的快速迭代。

微服务架构应用的构建,我们建议从应用设计入手。开发者可以借助 Domain Driven Design 来从业务角度进行规划和设计。

Domain Driven Design,简称 DDD, 它是一种软件开发的设计方法论,核心思想是通过领域建模对业务领域进行抽象和概念化,以此驱动软件设计。

应用架构的演进:亚马逊的微服务实践_第5张图片

这里有两个概念需要说明:
领域(Domain):是指软件要解决的主要问题领域。
领域模型(Domain Model):对领域进行抽象化建模的结果,反映业务领域的概念及业务规则。

DDD 提倡多层架构和明确定义的领域接口,来实现松耦合和高内聚的设计。DDD 也提倡语言统一,域专用语言、模型语言、代码语言保持一致。消除开发人员和领域专家在语言、理解等方面的鸿沟,实现软件系统和业务需求的高度契合。
应用架构的演进:亚马逊的微服务实践_第6张图片
当我们按照业务能力将业务拆成多个业务能力域,并构建每个域的业务模型,我们就可以通过微服务来设计这些各自独立且彼此依赖的业务模型。由于微服务是最小功能服务,可单独部署,用API交互,因此实现更广泛的用例。每个微服务都有自己的数据存储 ,围绕业务能力进行组织 。他们的状态是外部化 ,且每个微服务可选择适合他们的技术 。

小结

亚马逊在过去几年中已经大规模地将其基础设施转向微服务架构,目前采用亚马逊云上的多个服务来实现微服务,如使用 Amazon ECS、Amazon Lambda 来运行服务,Amazon API Gateway 提供 API 访问,Amazon SQS、Amazon SNS 用于服务间异步通信….这些服务充分利用云计算的优势,帮助亚马逊构建灵活、可靠、易于维护的分布式系统。

文章来源:
https://dev.amazoncloud.cn/column/article/65139d20659184378dd...

你可能感兴趣的:(应用架构的演进:亚马逊的微服务实践)