48、应用迁移、现代化与单体架构拆分全解析

应用迁移、现代化与单体架构拆分全解析

在当今数字化时代，将应用迁移到云端并对其进行现代化改造，以及处理单体架构系统，是许多组织面临的重要挑战。下面将详细介绍相关的策略、模式和实践方法。

1. 应用迁移与现代化概述

将现有应用从传统 IT 环境迁移到云端并进行现代化改造，一般分为迁移和现代化两个主要阶段。迁移是将应用从一个平台转移到另一个平台，这里是从传统 IT 迁移到云端；现代化则是改变应用，使其在云端运行得更好，包括改变架构和包装方式。

在进行应用迁移和现代化时，架构师、开发负责人和管理者需要做出许多决策。组织需要关注业务价值，采用一些实践方法，如“从小处着手”和“铺平道路”。

• 从小处着手 ：让团队在云端实现一些新功能，这有助于学习云架构原则并构建基础设施。
• 铺平道路 ：确保团队具备实现云应用所需的基础设施和环境，包括技术和组织层面。

云开发是一个渐进的过程，团队需要在 DevOps 和敏捷实践方面成熟后，才能成功应用云架构风格。以下是一些常见的迁移和现代化策略的起点：
- Lift and Shift 和虚拟化应用 ：这是重新托管和重新平台化的策略，基于团队已有的技能，但通常不应是云之旅的终点。
- 容器化应用 ：这是朝着正确方向迈出的进一步步骤，它促使团队采用更好的运营流程，并要求应用具有可复制性。
- 重构单体架构 ：当团队准备好重构单体架构时，就可以利用云原生架构的原则。

2. 迁移和架构现代化模式

2.1 迁移模式 - Lift and Shift

Lift and Shift 是将应用迁移到云端的模式，即重新托管策略。将应用的副本部署到云端，而不是部署到传统 IT 环境。云端需要具备与传统 IT 相同类型的服务器和操作系统。这种迁移方式提供了一些云应用的优势，如利用云的共享基础设施、可扩展性和弹性。但迁移后应用在云端的运行方式与在传统 IT 中基本相同。

2.2 架构现代化模式 - 重构单体架构

重构单体架构是改善应用架构的模式，它不改变应用的用户功能，而是改变提供功能的软件结构。主要有两条重构路径：
- 将大泥球重构为模块化单体 ：使应用架构更模块化，但仍作为单体在单台计算机上的单个进程中运行。
- 将大泥球或模块化单体重构为分布式架构 ：使应用架构模块化，并将模块变为可以在不同计算机上运行的服务，从而更好地利用多台计算机的容量。

3. 迁移和现代化策略

常见的迁移和现代化策略可以单独、逐步或组合使用，取决于起始平台和结构以及最终目标。以下是一些常用策略：
| 策略 | 描述 |
| ---- | ---- |
| Lift and Shift (1) | 简单地将应用从传统 IT 迁移到云端，保留应用架构 |
| Lift and Shift (1) 和 Refactor the Monolith (4) | 将应用迁移到云端并改善其架构 |
| New Cloud Application (5) | 创建一个新的云应用，可具有任何架构结构 |

在迁移应用到云端时，开发者还可以对架构进行重构，以实现以下改进：
- 客户端/服务器 ：将应用重构为客户端/服务器架构，分离客户端应用和服务器端的用户功能。
- 云原生 ：将客户端/服务器架构的服务器部分重构为云原生架构，确保应用在云端运行得更好。

4. 托管和部署现代化

除了迁移应用到云端和现代化架构外，还可以通过改善应用的包装方式来实现现代化，使应用更易于部署和管理。主要有两种策略：
- 虚拟化应用 (2) ：将应用或分布式架构中的每个服务打包为在虚拟机管理程序中运行的虚拟服务器，利用基础设施即服务 (IaaS) 服务模型。
- 容器化应用 (3) ：将应用或分布式架构中的每个服务打包为在容器引擎中运行的容器，利用平台即服务 (PaaS) 服务模型。

这些包装模式与应用的平台和架构无关，可以在传统 IT 或云端应用，并且可以应用于不同的架构类型。

以下是应用迁移和现代化的流程 mermaid 流程图：

graph LR
    A[传统 IT 应用] --> B{Lift and Shift}
    B --> C[云端应用（保留架构）]
    C --> D{是否重构单体架构}
    D -- 是 --> E[重构后的云端应用]
    D -- 否 --> C
    B --> F{是否进行包装现代化}
    F -- 虚拟化 --> G[虚拟化的云端应用]
    F -- 容器化 --> H[容器化的云端应用]

综上所述，应用迁移和现代化是一个复杂的过程，需要综合考虑多种因素和策略。通过合理选择和应用这些策略，可以使应用更好地适应云端环境，提高开发和运营效率。

5. 单体架构概述与问题分析

在软件系统中，单体架构曾经是一种常见的设计方式。单体应用通常被打包为一个单一的部署文件，运行在应用服务器上，它包含了来自各个子域的业务逻辑组件，如服务、模块、库等。这些组件之间存在着依赖关系，并且随着时间的推移，这种依赖关系往往会不断增加。

然而，随着时间的推移和业务的发展，单体架构可能会面临一些问题。例如，单体组件在网络上使用的协议、消息格式和 API 设计标准可能与新的客户端应用不兼容。而且，即使最初设计良好的单体架构，也可能会因为后续的架构修订和技术债务的积累，逐渐演变成难以更改和维护的“大泥球”架构。这种架构使得添加新功能变得困难，难以利用新的协议和技术，并且部署也变得更加复杂，因为任何更改都可能影响到系统的其他部分，需要对整个系统进行测试。

6. 引入“绞杀单体”概念

当单体架构面临上述问题时，一种有效的解决方案是采用“绞杀单体”的方法，将现有的单体系统逐步转换为微服务架构。“绞杀单体”这一概念源于马丁·福勒的比喻，类似于绞杀藤缠绕并取代树木的过程。在软件领域，就是通过在原系统外部添加新功能，并将原系统内的现有功能替换或重写为微服务，逐步“绞杀”原有的单体系统，直到最终完全被新的微服务系统所取代。

“绞杀单体”需要进行两项相互支持的活动：
- 放弃 ：在基于微服务的新系统中进行所有新开发，逐渐放弃单体系统中很少使用或不再使用的功能。在某些特殊情况下，如使用模式快速变化，单体系统的功能可能会逐渐过时，最终可以直接丢弃。
- 迁移 ：将单体系统中的功能逐步重新实现在基于微服务的新系统中。在迁移过程中，部分功能仍由单体系统提供，而已迁移的功能则由新系统提供。有时可能需要结合微服务代码和单体系统代码来实现某些功能。

7. 绞杀单体的模式与实践

当决定采用“绞杀单体”的方法时，首先需要考虑是一次性完全重写单体系统，还是逐步将其转换为微服务架构。在某些情况下，如业务需求发生了重大变化，一次性重写可能是合适的选择。但通常情况下，由于成本和时间的限制，逐步“绞杀”单体系统更为可行。

以下是一些在“绞杀单体”过程中可以应用的模式和实践：
- 从小处着手 ：让团队使用微服务实现一些新功能，这有助于学习微服务原则，并构建所需的基础设施和环境，例如设置 DevOps 和交付管道，以便能够构建、测试和部署微服务。
- 保护系统 ：通过为现有外部系统创建代理或外观来包装单体系统，保护系统免受不必要的更改。
- 添加新功能 ：在验证组织内可以成功进行微服务开发后，制定指令，鼓励和强制将任何新的开发工作以微服务的形式添加，避免继续向现有单体应用中添加功能。
- 转换单体为微服务 ：寻找并确定可以提取、重构或替换为微服务的区域，将单体系统中的功能逐步替换为微服务。具体方法包括：
- 寻找裂缝 ：在单体系统中寻找容易提取功能的区域，即“裂缝”。如果这些“裂缝”揭示了定义良好的 API，可以将相关组件提取为微服务。
- 重构后提取 ：对于一些存在一定耦合的区域，可以先对单体系统的部分进行重构，使其更易于提取为微服务。
- 替换为微服务 ：对于功能紧密耦合的区域，锁定单体系统中的代码，用新的微服务重新实现该功能，并在验证后移除原有的实现。

此外，还有一些支持性的模式：
- 单体到微服务代理 ：在单体系统中需要访问新服务的地方，可以使用代理来提供访问解决方案。
- 回放测试 ：在将代码从单体系统提取或重写为微服务后，通过对新实现进行一组输入和操作的回放测试，并与原实现进行比较，验证新实现是否正常运行。

8. 总结与流程梳理

为了更清晰地展示“绞杀单体”的过程，以下是一个 mermaid 流程图：

graph LR
    A[单体系统] --> B{是否从小处着手}
    B -- 是 --> C[团队实现新微服务功能]
    C --> D[设置基础设施和环境]
    D --> E{是否包装单体系统}
    E -- 是 --> F[创建代理或外观包装单体]
    F --> G{是否添加新功能为微服务}
    G -- 是 --> H[新功能以微服务形式添加]
    H --> I{是否转换单体为微服务}
    I -- 是 --> J[寻找可转换区域]
    J --> K{提取方式}
    K -- 直接提取 --> L[提取组件为微服务]
    K -- 重构后提取 --> M[重构后提取为微服务]
    K -- 替换 --> N[替换为新微服务]
    L --> O[验证新实现] --> P[移除原实现]
    M --> O
    N --> O
    B -- 否 --> A
    E -- 否 --> G
    G -- 否 --> I

总的来说，无论是应用迁移和现代化，还是“绞杀单体”将单体架构转换为微服务架构，都是为了让软件系统更好地适应不断变化的业务需求和技术环境。在实际操作中，需要根据具体情况选择合适的策略和方法，逐步推进系统的改进和升级。通过合理运用这些技术和实践，可以提高系统的灵活性、可维护性和开发效率，为组织带来更大的价值。