53、从单体架构向微服务架构迁移：策略与实践

从单体架构向微服务架构迁移：策略与实践

在当今的云计算时代，将传统的单体架构应用迁移到微服务架构是许多企业面临的重要任务。本文将探讨如何在现代化系统时，将单体架构迁移到微服务架构，并介绍一些实用的模式和策略。

1. 单体架构与微服务架构的选择

并非所有情况下都需要将单体架构迁移到微服务架构。如果现有的单体解决方案运行良好，能够满足组织的新需求，那么就没有迫切的理由进行改变。有时候，对单体架构进行重构，使其更易于更改，可能是一个正确的选择。

然而，如果单体架构变得难以更改和适应新需求，就需要做出决策：是重构单体架构，使其更易于更改；还是完全重写单体架构，采用微服务架构；或者应用“绞杀者”模式。

2. 迁移的准备阶段

对于初次接触微服务的组织和团队，以下是一些可以采取的步骤：
- 从小规模开始 ：让一个团队使用微服务实现一些新功能，积累经验。
- 搭建基础环境 ：构建基础设施和环境（包括技术和组织层面），使微服务的实现更加容易。这可能包括开发模板和进行培训。
- 包裹单体架构 ：当用微服务替换单体架构的某些部分时，可以将现有客户端重定向到这些新的微服务，并根据需要进行适配。

3. 应用“绞杀”过程

在创建了一些微服务并验证了使用微服务设计和实现系统是一个好主意之后，就可以开始应用“绞杀”过程了。
- 将新功能作为微服务开发 ：鼓励和强制团队将所有新功能通过微服务添加，而不是添加到单体架构中。这也可以促使团队在对单体架构进行更改时，首先尝试使用微服务实现。
- 将单体架构转换为微服务 ：这是一个迭代的过程，需要在单体架构中找到可以提取、重构或替换为微服务的部分。具体步骤如下：
- 寻找“细微裂缝” ：这些是单体架构中可以将组件提取到微服务实现的功能区域或组件。有时候，先提取较大的宏服务，然后随着对领域的了解，将其重构为较小的微服务会更容易。
- 重构并提取 ：对于那些虽然有一定耦合，但经过一些更改可以提取到微服务实现的部分，可以进行重构然后提取。
- 重写并替换 ：当功能在单体架构中紧密耦合时，可能需要完全重写并将其替换为微服务。

在这个过程中，可以使用单体到微服务的代理来访问新的微服务，并使用回放测试来验证提取或替换的实现。

4. 绞杀场景

在绞杀单体架构时，有多种策略和场景可供选择，以下是一些常见的场景：
| 场景 | 描述 | 操作步骤 |
| ---- | ---- | ---- |
| 添加新功能 | 尽可能将新功能实现为微服务。可以直接实现一个小的微服务，也可以在单体架构中找到与该功能相关的“细微裂缝”，提取组件到微服务。 | 1. 评估新功能是否适合作为微服务实现。
2. 若直接实现微服务，进行开发和部署。
3. 若提取组件，找到相关“细微裂缝”，提取并重构。
4. 创建单体到微服务的代理。
5. 进行回放测试。 |
| 提取痛苦部分 | 提取单体架构中导致添加新功能或更改现有功能时出现问题的部分。 | 1. 确定痛苦部分。
2. 找到相关“细微裂缝”，提取组件到微服务。
3. 若原功能耦合较大，先提取宏服务，再重构。
4. 若功能紧密耦合，冻结并重写。
5. 创建单体到微服务的代理。
6. 进行回放测试。 |
| 无法使用旧协议 | 当遗留的单体应用使用的旧通信协议在新解决方案中不再支持时，将相关功能重写为微服务。 | 1. 确定需要迁移的功能。
2. 重写功能为微服务。
3. 让其他团队了解新的微服务。
4. 若需要，对代码进行重构然后提取。
5. 创建单体到微服务的代理。
6. 进行回放测试。 |

5. 其他考虑因素

在绞杀单体架构的过程中，还需要考虑以下几点：
- 包裹单体架构 ：可以使用标准的包装模式，如外观模式、代理模式或适配器模式，来保护系统免受更改的影响。这也可以通过使用公共 API、适配器微服务或调度器来实现。
- 完全绞杀的可行性 ：有时候，完全绞杀单体架构可能不值得，因为部分单体架构可能仍然提供价值，重写的成本过高。

以下是一个简单的 mermaid 流程图，展示了从单体架构向微服务架构迁移的主要步骤：

graph LR
    A[评估单体架构] -->|运行良好| B[维持现状或重构]
    A -->|难以更改| C[准备迁移]
    C --> D[小规模尝试微服务]
    D --> E[搭建基础环境]
    E --> F[包裹单体架构]
    F --> G[开发新功能为微服务]
    G --> H[转换单体架构为微服务]
    H --> I[寻找细微裂缝]
    I -->|可提取| J[提取组件]
    I -->|紧密耦合| K[重写并替换]
    J --> L[创建代理]
    K --> L
    L --> M[回放测试]

通过应用这些策略和模式，可以逐步将单体架构迁移到微服务架构，使应用更好地适应云计算环境。在实际应用中，还需要根据组织和技术的具体情况，制定适合自己的迁移步骤。

从单体架构向微服务架构迁移：策略与实践

6. 云应用架构与模式决策

在云计算环境下开发应用，需要做出一系列关于架构和设计的决策，这些决策将影响应用在云端的性能和可维护性。

• 单体或分布式架构 ：应用可以从单体架构开始，当多个团队需要处理应用的不同部分，并且保持代码的可维护性和低技术债务比快速拼凑新功能更重要时，分布式架构会更具优势。
• 云原生特性 ：为了使应用在云计算中运行良好，应在设计中融入云原生特性，如无状态性、可复制性、打包成应用程序包以及通过服务 API 暴露等。虽然并非所有应用都需要具备这些特性，但具备的特性越多，应用在云端的运行效果越好。
• 微服务的选择 ：在开发分布式架构时，应根据业务领域的功能交互来确定哪些组件应开发为微服务。每个微服务应专注于单一业务功能，这样可以独立开发、部署、扩展和失败，尽管这需要额外的设计工作。
• 编排或编排 ：当微服务之间的交互复杂、动态且不可预测时，应采用编排而非编排的方式。在单个应用中，较简单且需要更可靠的交互可以进行编排，而不可预测的交互则通过编排来发现。
• 状态存储 ：由于云原生微服务是无状态的，需要考虑将状态存储在何处。关系型数据库并非总是存储应用数据的最佳方式，应探索更符合云计算特点的存储方式。
• 应用客户端 ：需要考虑用户如何访问云端运行的应用，以及应用如何支持不同类型的设备和与其他应用协作。

7. 传统应用的迁移与现代化

将传统 IT 应用迁移到云端并进行现代化改造，需要考虑以下决策：
- 迁移与现代化的必要性 ：传统 IT 应用在云端可能无法良好运行，需要采取措施使其在云端运行得更好。可以采用应用迁移和现代化的技术，如“提升和转移”。
- 逐步迁移 ：如果传统 IT 应用太大且太重要，无法一次性迁移到云端，可以采用“绞杀”策略，逐步将其迁移，同时保证用户的正常使用。

8. 模式应用与架构结构

以下是各个章节在云应用架构中的体现，通过这些模式的应用，可以构建出适合云计算环境的应用：
| 章节 | 架构体现 |
| ---- | ---- |
| 第 1 和 2 章 | 整个应用是云应用，可以采用多种应用架构，其中分布式架构最灵活，更符合云计算的特点。 |
| 第 3 章 | 应用是具有云原生架构的云原生应用。 |
| 第 4 和 5 章 | 云原生架构由微服务架构组成，通过围绕领域建模来发现微服务并进行设计。 |
| 第 6 章 | 如果有多个应用，可以通过事件骨干进行连接，并在事件驱动架构中通过事件编排进行协调。 |
| 第 7 章 | 云原生应用及其微服务是无状态的，将状态存储在云原生存储选项中，通常是云数据库。 |
| 第 8 章 | 用户通过客户端应用访问应用。 |
| 第 9 和 10 章 | 可以使用应用迁移和现代化技术将现有应用从传统 IT 迁移到云端，对于大型应用可以采用“绞杀”策略逐步迁移。 |

下面的 mermaid 流程图展示了云应用架构各部分之间的关系：

graph LR
    A[云应用] --> B[应用架构]
    B -->|分布式架构| C[云原生架构]
    C --> D[微服务架构]
    D --> E[微服务设计]
    F[多个应用] --> G[事件骨干]
    G --> H[事件编排]
    C --> I[云原生存储]
    I --> J[云数据库]
    A --> K[客户端应用]
    L[传统应用] --> M[应用迁移与现代化]
    M -->|绞杀策略| N[逐步迁移]

9. 总结

通过应用上述模式和策略，可以做出明智的决策，开发出适合云计算环境的应用。在实际应用中，需要根据应用的需求、团队的技能和偏好进行定制化的决策。同时，要根据组织和技术的具体情况，制定适合自己的迁移和开发步骤，以确保应用能够在云端高效、稳定地运行。在迁移过程中，要注意各个环节的测试和验证，如回放测试等，以保证迁移的质量和可靠性。并且要认识到完全绞杀单体架构并非总是必要的，应根据实际情况保留部分有价值的单体架构部分。通过不断的实践和总结，不断优化应用架构和迁移策略，以适应云计算环境的不断发展和变化。