亚马逊AWS官方博客

新增功能 – AWS Migration Hub Refactor Spaces 帮助以增量方式重构您的应用程序

我很高兴地宣布推出 AWS Migration Hub Refactor Spaces 预览版,这是 AWS Migration Hub 的一项新功能,可让您将现有应用程序重构为分布式应用程序,通常基于微服务。

重构现有应用程序的原因有很多。您可能想让您的代码更加模块化,使用更现代的框架,使用不同的数据存储等。一般来说,重构时,您的目标是使您的应用程序更易于维护和随着时间的推移发生演变。其他益处可能包括处理更大的工作负载、提高弹性或降低成本。但是我们要面对现实,因为重构很难。我常常把重构与在飞机保持飞行、满载乘客的情况下更换飞机的引擎、机舱座椅和娱乐系统而不让乘客察觉到任何变化进行比较。

在与成功完成这些重构项目的客户交谈时,我们注意到了一种常见的模式:Strangler Fig 设计模式

strangler fig

绞杀榕是一类植物,它们的根从宿主树的顶部长出来,最终覆盖或取代宿主。作者 Martin Fowler 首次创造了这个术语来描述迁移模式。其理念是“在旧系统的边缘逐步创建一个新系统,让它在几年内缓慢增长,直到旧系统被扼杀为止”。

如何将这种植物行为应用于我的应用程序迁移?
受这类植物的启发,我可能想从整体式应用程序中提取功能,然后将其重写为微服务。然后,我逐步将流量从旧系统路由到新系统。随着时间的推移,所有请求都会路由到微服务,现有应用程序将停用。

这种应用程序转型方法虽然有效,但会带来障碍。我必须创建所需的基础设施来分离现有的应用程序和微服务。在 AWS 云中,这通常涉及到创建多个 AWS 账户,因此团队或服务可以更轻松地独立运营。拥有多个账户是跨团队分离关注点和计费的最有效方法。在处理多个 AWS 账户时,需要维护网络基础设施才能将我的现有应用程序和新服务连接在一起。此外,我必须创建一个路由控制系统,以便将流量从旧应用程序逐渐路由到不同账户中的新服务。大规模创建和管理该基础设施非常复杂。它给重构项目带来了额外的风险和成本。

Refactor Spaces 如何提供帮助
AWS Migration Hub Refactor Spaces 为我处理繁重的工作。首先,它建立了网络基础设施,以实现多个 AWS 账户之间的连接。其次,它创建并管理一种机制,以将 API 调用从我的旧式应用程序中路由出去。

假设我有一个想要重构的整体式应用程序。该应用程序由使用 ReactJS 的一个基于 Web 的前端组成。该前端应用程序托管在 Amazon Simple Storage Service (Amazon S3) 上并通过 Amazon CloudFront 分发。前端对在 NodeJS 或 Python 中开发并在多个 EC2 实例上部署的整体式应用程序进行 API 调用。API 使用关系数据库,因为自公司成立以来,我们一直在用这种方式存储数据。

下图展示了此应用程序的架构。

refactor spaces - monolith

每个 API 都有一个不同的 URI。例如,/cart API 负责处理购物篮,/order API 负责处理订购系统,等等。我应用了 strangler fig 模式并决定将 /cart 功能提取到一组新的微服务中。我为这些微服务创建了一个 AWS 账户。我开发并部署了一组 AWS Lambda 函数来实现购物车管理功能。我之所以选择使用 Amazon DynamoDB 进行购物篮数据存储,是因为它的大规模低延迟。

我的新架构的 schema 如下图所示:

Refactor Space - 目标架构但现在我面临两个挑战。首先,我必须设计、编写路由机制的代码并对其进行部署,以便将前端应用程序发出的 API 调用路由到正确的后端:整体式服务或新的微服务。此服务可能会部署到不同的 AWS 账户中。然后,我必须配置这些 AWS 账户之间的网络连接。

这就是 Refactor Spaces 出现的原因。

AWS Migration Hub Refactor Spaces 介绍
通过解决我刚才描述的两项挑战,Refactor Spaces 使管理应用程序重构变得容易:API 调用的路由和 AWS 账户之间的网络连接。它由环境、服务和应用程序代理组成。我们来看看它的实际操作。

我打开 AWS 管理控制台,导航到 AWS Migration Hub,然后选择 Refactor Spaces

我首先创建一个 Refactor Spaces 环境。环境是由对等 VPC 组成的多账户网络结构。这样,添加到环境中的服务 VPC 中的 AWS 资源就可以直接跨 AWS 账户进行通信。它还提供了跨账户的网络和服务的统一视图。

在 Create environment(创建环境)中,我为环境指定了一个名称和一个描述,然后选择 Next(下一步)。

Refactor Spaces - 创建环境

然后,我定义我的应用程序。我给应用程序指定一个名称,然后选择部署代理所在的 VPC

应用程序是服务容器。它有一个定义路由的代理。该代理允许您的前端应用程序使用单个端点来联系多个服务。所有的流量都到达单个代理端点,然后根据您的规则被发送到多个服务。

Refactor Space - 创建应用程序

如前所述,您可能需要使用多个 AWS 账户。通常,应用程序由一个托管 Refactor Spaces 应用程序代理的 AWS 账户、托管旧式应用程序的一个或多个 AWS 账户以及用于第一个微服务的一个 AWS 账户组成。因此,我邀请其他 AWS 账户所有者加入此 Refactor Spaces 环境。我为每个 AWS 账户添加一个主体。Refactor Spaces 不会另起炉灶,但它会利用 AWS Resource Access Manager (RAM) 进行此操作。

此步骤是可选的。Refactor Spaces 可以在一个 AWS 账户内工作。稍后可以与其他 AWS 账户共享环境。

我以主体的身份输入 AWS 账户 ID,然后选择 Next(下一步)。

Refactor Space - 共享账户

最后,我查看我的选择,然后选择 Create & share environment (创建和共享环境)(未显示在此处)。

假设微服务已准备就绪,下一步是将它们注册为 Refactor Spaces 服务。Refactor Spaces 服务是提供业务功能的实体,通常是微服务。这些服务可通过唯一的端点访问,并且它们可以在 Refactor Spaces 环境中跨账户进行互操作。此示例中存在四种服务:

  • 整体式应用程序。这是默认服务,Refactor Spaces 可在其中路由由前端发起的所有 API 调用。
  • 用于实施 /cart 功能的三项微服务。我决定使用三种不同的服务来重构此功能:AddItemRemoveItemListItems

Refactor Spaces 服务可以针对任何计算类型:部署在 AWS Fargate 上的容器 EC2、Application Load BalancerAWS Lambda 函数等。

我从左侧菜单中选择 Create service(创建服务)。服务配置分为三个步骤。首先,我选择要在其中定义此服务的 Refactor Spaces 环境应用程序。其次,我给服务指定一个名称和一个描述。第三,我选择服务端点VPC 中的 HTTP/HTTPS URL 或 Lambda 函数

除非另有说明,否则整体式应用程序是默认路由,Refactor Spaces 应用程序代理可在其中路由所有 API 调用。我输入 / 作为源路径并选择 Include child paths(包含子路径)。 然后,我确保为 HTTP 谓词选择了 Match all(匹配全部)。

完成后,我选择 Create service(创建服务)。我为我的每个微服务重复此过程。在此演示中,我总共创建了四项 Refactor Spaces 服务。

AWS Migration Hub Refactor Spaces - 创建服务

最后一步定义了 Refactor Spaces 应用程序代理的路由规则。配置后,代理将成为我的前端应用程序的新 API 端点。我必须在前端应用程序中进行的唯一更改是将其指向 Refactor Spaces 应用程序代理 URI。代理根据路由定义将 API 调用路由到服务。应用程序代理支持路由到具有公有或私有可见性的所有计算平台。目前,私有端点必须通过公有 DNS 名称或其私有 IP 地址进行引用。每个 API 调用都针对代理中配置的路由集运行。当路径与规则匹配时,请求将发送到为该路径配置的目标服务。如果代理与任何路径规则不匹配,则代理有一条默认路由,该路由会将请求转发到默认服务。

我选择我刚刚创建的服务。然后,我输入路由源路径和要支持的 HTTP 谓词。当我的服务需要子路径(例如 /cart/123)时,我确保同时选择 Include child paths(包含子路径)。

Refactor Spaces - 定义路由

我对 GetItemRemoveItem 微服务重复此过程。它们被调用以分别用于不同的 HTTP 谓词:GETDELETE

基于此配置,Refactor Spaces 为我创建并管理以下架构。Refactor Spaces 应用程序代理和网络结构部署在单独的 AWS 账户中。我可能会根据我的整体式应用程序或微服务的需求进一步配置 Amazon API Gateway

Refactor Spaces - 最终架构

最终的变化是针对应用程序前端的。我将其配置修改为指向 Refactor Spaces 应用程序代理端点,而不是整体式应用程序的端点。从现在开始,Refactor Spaces 在默认情况下将 API 调用路由到整体式应用程序。它会将对 GETPOSTDELETE 谓词的 /cart 调用路由到作为 Lambda 函数实施的新微服务。

随着时间的推移,我将重复这个过程,以将其他功能逐个移出整体应用程序,直到旧式整体应用程序被新的微服务架构绞杀为止。

定价和可用性
AWS Migration Hub Refactor Spaces 现已在以下十个 AWS 区域提供:美国东部(弗吉尼亚北部)、美国西部(俄勒冈)、美国东部(俄亥俄)、亚太地区(新加坡)、亚太地区(悉尼)、亚太地区(东京)、欧洲(爱尔兰)、欧洲(法兰克福)、欧洲(伦敦)和欧洲(斯德哥尔摩)。和往常一样,我们期待将来扩展到更多区域。

这项新功能现在已开放预览版的形式提供,无需注册。您可以立即开始使用。在预览期间使用 Refactor Space 不收取任何费用。但是,您可能需要为它在 AWS 账户上预置的资源付费:Amazon API GatewayAWS Transit Gateway网络负载均衡器定价详细信息可参见 AWS Migration Hub 的定价页面。计费将在 Refactor Spaces 全面推出时开始。

立即开始重构您的应用程序

– seb