使用 AWS Migration Hub Refactor Spaces 实践绞杀者模式 - 渐进式微服务化
解析 Refactor Spaces 实现绞杀者模式、路由控制和渐进式迁移的方法。
Refactor Spaces 概述
Refactor Spaces 是支持从单体应用向微服务渐进式迁移的服务，最多可管理 50 个服务和 100 条路由。自动构建实现绞杀者模式所需的基础设施（API Gateway、NLB、Transit Gateway 实现 VPC 间连接），通过基于 URL 路径的路由实现按功能单元的渐进式迁移。支持多账户配置，与 AWS Organizations 集成可自动发现组织内的账户并作为环境成员添加。创建环境时网络结构（Transit Gateway）自动配置，无需手动设置不同 VPC 或账户中服务间的通信路径。
绞杀者模式的实现
创建环境后会自动构建 API Gateway 作为代理，所有流量路由到单体应用。开发新微服务后，将对应 URL 路径（如 /api/orders）的路由切换到新服务。其余路径继续路由到单体应用。逐步添加路由，最终所有路径迁移到新服务后废弃单体应用。出现问题时删除路由即可立即回退到单体应用。该方式的优势在于从用户角度看维持单一端点（API Gateway URL），前端或客户端应用无需更改。迁移完全通过后端路由变更完成，迁移期间服务不中断。
路由与多账户
Refactor Spaces 的路由由默认路由（回退到单体应用）和服务路由（分发到微服务）构成。基于 URL 路径的路由将 /api/orders 路由到新微服务，其余路由到单体应用。多账户配置可将单体应用和微服务放置在不同账户中，分离安全边界。服务端点支持两种类型：Lambda 函数和 HTTP URL（ALB 或 NLB 端点）。以 Lambda 为目标时可直接集成无服务器微服务；以 HTTP URL 为目标时可将 ECS 或 EKS 运行的容器服务放置在后端。新微服务的添加只需创建服务和路由，API Gateway 配置变更由 Refactor Spaces 自动管理。 关于微服务迁移的详细解析，可参考Amazon 相关书籍。
Refactor Spaces 定价与限制
Refactor Spaces 本身不收取额外费用。成本取决于自动构建的 API Gateway、NLB、Transit Gateway 资源费用。API Gateway 请求费用是主要成本因素。Transit Gateway 的连接费和数据处理费也会随着多账户配置中服务数量增加而累积。迁移完成后废弃单体应用并删除 Refactor Spaces 环境，代理资源费用也随之消除。限制方面，每个环境最多 50 个服务和 100 条路由，拥有数百个微服务的大规模系统需要分割到多个环境，或在迁移完成后计划过渡到直接管理 API Gateway 的架构。
与其他迁移方式的比较
实现绞杀者模式除 Refactor Spaces 外还有其他方法。手动构建 API Gateway 并自行管理路由规则的方式自定义程度高，但手动维护 Transit Gateway 和 NLB 配置带来运维负担。使用 ALB 路径路由在单体应用和微服务间分发流量的方式适合单 VPC、单账户迁移，但不适合多账户分离。使用 Service Mesh（App Mesh）的流量分割适合已经在 ECS 或 EKS 上进行容器化的环境，但当单体应用仍在 VM 上运行时导入障碍较高。Refactor Spaces 的价值在于自动化这些基础设施构建，使迁移团队只需专注于路由的添加和删除。
迁移计划最佳实践
要使用 Refactor Spaces 成功实现渐进式迁移，首先按 API 路径单元盘点单体应用功能，从依赖关系最少的边界开始迁移。最安全的首个迁移目标是只读 API（如 /api/products 的 GET）。涉及写入的 API 需要注意事务边界设计，考虑 Saga 模式或事件驱动架构来维护单体应用与微服务间的数据一致性。迁移期间的监控应在 CloudWatch 中监视 API Gateway 延迟指标和 5xx 错误率，路由切换后如检测到异常应立即删除路由回退到单体应用。与金丝雀部署结合时，可使用 API Gateway 阶段变量或基于请求头的路由将部分流量发送到新服务，进一步降低风险。
总结
Refactor Spaces 自动构建绞杀者模式基础设施，支持从单体应用向微服务的渐进式迁移。通过基于 URL 路径的路由实现按功能单元迁移，多账户配置分离安全边界。同时支持 Lambda 和 HTTP URL 服务端点，迁移期间的回滚只需删除路由即可立即执行。与其他方式相比运维负担更低，为迁移团队提供了专注于应用分解的环境。