将单体分解为微服务

Tabby Ward 和 Dmitry Gulin、Amazon Web Services (AWS)

2023 年 4 月（文档历史记录）

迁移到 Amazon Web Services (AWS) 云具有许多优势，包括技术和业务灵活性、新的收入机会和降低的成本。要充分利用这些优势，您应该通过将整体应用程序重构为微服务来不断实现组织软件的现代化。此过程包括三个主要步骤：

• 将单体分解为微服务 — 使用本指南提供的分解模式将整体应用程序分解为微服务。

• 集成微服务 - 使用 AWS 无服务器服务将新创建的微服务集成到微服务架构中。

• 为微服务启用数据持久性 - 通过分散数据存储，促进微服务之间的多语言持久性。

现代化通常涉及两种类型的项目：

• Brownfield 项目涉及在现有或遗留系统的背景下开发和部署新的软件系统。

• Greenfield 项目涉及从头开始为全新的环境创建系统，而不涉及任何遗留代码。

对于棕地项目，应用程序现代化之旅的第一步是将投资组合中的整体分解为微服务。

大多数应用程序最初都是为特定业务用例设计的单体。如果单体架构不强制模块化设计，那么对于那些在既定领域知识的范围内没有明确定义职责的应用程序来说，单体结构仍然是有效选择。作为单个部署单元的整体结构的核心特征也可以帮助减少设计缺陷，例如紧密耦合或缺乏内部结构。

尽管对于某些用例来说，单体可能是一个有效的选择，但它通常不适合现代应用程序。单体架构的内部结构定义不明确会使代码难以维护，这使得新开发人员的学习过程曲折，并导致额外的支持成本。高耦合和低内聚会显著增加添加新功能所需的时间，并且您可能无法根据流量模式扩展单个组件。单体还需要多个团队为一个大型版本进行协调，这增加了协作和知识转移的负担。最后，您会发现，随着您的业务或用户群的增长，添加新功能或打造新的用户体验变得困难。

为了避免这种情况，您可以使用分解模式来分解单体应用程序，将它们转换为多个微服务，然后将其迁移到微服务架构。微服务架构将应用程序结构化为一系列松耦合服务。微服务旨在通过支持持续交付和持续部署（CI/CD）流程来加速软件开发。

在开始分解过程之前，您应评估要分解哪些单体。确保包含存在可靠性或性能问题的单体，或者在紧密耦合的架构中包含多个组件。我们还建议您充分了解单体架构的业务用例、其技术及其与其他应用程序的相互依赖关系。

本指南适用于应用程序所有者、企业主、架构师、技术主管和项目经理。它讨论了以下六种用于分解单体的云原生模式，并描述了每种模式的优势和劣势：

• 按业务能力分解

• 按子域分解

• 按交易分解

• 按团队提供的服务模式

• strangler fig 模式

• 按抽象模式分支

本指南为内容系列的一部分，该系列涵盖了 AWS 建议的应用程序现代化方法。该系列还包括：

• 在 AWS 云中实现应用程序现代化的策略

• 在 AWS 云中实现应用程序现代化的分阶段方法

• 评估 AWS 云中应用程序现代化的准备情况

• 通过使用 AWS 无服务器服务集成微服务

• 为微服务启用数据持久性

目标业务成果

在将整体分解为微服务后，您应该期待以下结果：

• 将您的单体应用程序高效过渡到微服务架构。

• 快速调整飘忽不定的业务需求，而不中断核心活动，例如高可扩展性、改进的弹性、持续交付和故障隔离。

• 加快创新，因为每项微服务都可以单独测试和部署。