46、应用迁移与重构：从虚拟化到微服务的全面指南-优快云博客

本文链接：https://blog.youkuaiyun.com/php55/article/details/154172093

应用迁移与重构：从虚拟化到微服务的全面指南

1. 应用迁移研究案例

在云计算领域，有不少关于应用迁移的成功案例。例如，太古可口可乐运用“提升并转移（Lift and Shift）”和“应用虚拟化（Virtualize the Application）”两种方法，将其本地数据中心迁移至亚马逊云科技（AWS）云环境。亚马逊还为此发布了相关案例研究。此外，威睿（VMware）与福雷斯特（Forrester）合作，针对一所公立大学在 AWS 上采用 VMware 的总体经济影响进行了研究。这些案例都凸显了将应用虚拟化到云环境中的优势。

2. 应用容器化

2.1 容器化的优势

当你有一个现有的应用程序，想要将其迁移到云端，或者已经使用“提升并转移”方法将其迁移到了云端，此时你可能希望避免更改应用程序本身，但愿意改变其部署的打包方式，以使其在云端运行得更好。容器化就是一种很好的选择。

与将应用程序托管在虚拟服务器中相比，将其托管在容器中可以更有效地利用云资源，因为容器比虚拟服务器更轻量级。轻量级的打包应用程序启动速度更快，并且可以在相同的内存和 CPU 占用下更轻松地进行扩展。

2.2 虚拟服务器的局限性

虽然大多数 IT 团队对虚拟服务器技术比较熟悉，因为它已经在传统 IT 环境中使用了数十年，但虚拟服务器也存在一些挑战：
- 打补丁问题 ：虚拟服务器通常基于已知软件版本（操作系统、中间件和应用程序）的镜像创建。由于虚拟服务器通常运行时间较长，运维团队倾向于对运行中的软件打补丁，而不是构建新的服务器镜像并完全替换现有虚拟服务器。这会导致配置漂移，使得在出现问题时更难调试。
- 专有性 ：虚拟服务器技术尚未达到其他打包技术的标准化程度。将虚拟服务器镜像移植到其他虚拟机管理程序或虚拟镜像格式通常需要大量工作。
- 开销大 ：由于虚拟服务器的密度较低，并且创建、管理和打补丁现有虚拟服务器需要更多的精力，因此其运营成本通常比其他技术（如容器）更高。

2.3 容器化的操作步骤

容器化是应用程序打包在虚拟服务器之后的下一次演进。以下是容器化的操作步骤：
1. 选择操作系统 ：容器（如 Docker 容器）可以运行 Linux 或 Windows。应用程序需要能够在这些操作系统的当前版本中运行，才能进行容器化。
2. 考虑中间件 ：如果应用程序依赖于中间件（如应用服务器或数据库），则该中间件必须能够在容器操作系统中运行。
3. 选择基础镜像 ：你可以为应用程序从头创建容器镜像，但供应商通常会为标准运行时和应用服务器提供基础镜像。如果你的应用程序运行在相当标准的运行时或应用服务器中，建议从供应商的基础镜像开始构建。

2.4 容器化的优势总结

容器化具有以下优势：
- 更高的密度 ：由于容器共享底层操作系统内核，因此可以在相同的内存空间中容纳更多的容器，并且容器镜像占用的磁盘空间也比虚拟服务器少。
- 更快的启动速度 ：由于共享操作系统内核和在公共共享进程空间中运行，容器的启动速度明显快于虚拟服务器。
- 配置一致性 ：容器很难从其原始配置（镜像）进行更改，这意味着所有从相同容器镜像创建的容器都是完全相同的，便于操作和维护。
- 更高的可移植性 ：容器技术在早期就围绕镜像配置（Dockerfile）和容器运行时引擎进行了标准化，并且大多数项目都保持了兼容性。因此，构建的容器通常可以更轻松地在不同的云环境和本地环境之间移动。

2.5 容器化面临的挑战

尽管容器化有诸多优势，但也面临一些挑战：
- 自动化转换 ：现有的开发和部署自动化通常是为支持虚拟服务器部署而构建的，将其转换为支持容器化需要时间和精力。
- 中间件适配 ：现有的中间件或第三方应用程序可能仅为虚拟服务器环境构建或优化，你可能需要将其转换为支持容器化的版本或产品。
- 技能缺失 ：缺乏容器环境的技能可能是将开发和部署流程及自动化转换为支持容器的障碍，你可能需要对员工进行相关技术培训。
- 容器构建困难 ：手动构建容器可能很困难，建议开发自动化流程，在 DevOps 管道中以标准化的方式构建和部署容器。
- 容器编排复杂 ：容器编排可能特别难以正确实施，建议由具有相关技能的团队来管理多个应用程序的共享编排环境。

2.6 容器化案例

容器化自 2013 年 Docker 推出以来，已被广泛接受，有许多成功的案例：
- IBM 首席信息官办公室通过将数千个应用程序从虚拟服务器迁移到 Kubernetes 中的容器，实现了运营成本降低 90%，总运营操作减少 55%。
- Tinder 记录了他们将应用程序迁移到容器和 Kubernetes 的过程以及从中获得的优势。
- The Warehouse Group 也记录了他们使用 Docker 将应用程序迁移到容器的优势。
- 云原生计算基金会（CNCF）有一份全面的案例研究列表，描述了 CNCF 内许多不同项目的优势，所有这些项目都依赖于容器化。

3. 单体应用重构

3.1 重构的必要性

如果你有一个现有的应用程序，它可以正常工作，但发展得比较混乱，你可能希望将其现代化为模块化单体应用（Modular Monolith）或分布式架构（Distributed Architecture），使其看起来像是从一开始就设计为新的云应用程序。

有些应用程序架构比其他架构更复杂，其架构选择可以支持小型开发团队独立工作，也可能阻碍他们；可以使应用程序在多计算机环境中更高效地运行，也可能阻止它。当出现以下情况时，你可能需要考虑改变应用程序的架构：
- 频繁变更困难 ：如果应用程序经常更改，但由于其设计原因难以更新，这可能表明其当前架构不可持续，需要更改。
- 迁移失败 ：如果你尝试对应用程序进行虚拟化或容器化，但由于应用程序对其当前硬件和软件环境有太多依赖而失败，你应该考虑改变其架构。
- 资源使用低效 ：如果应用程序在使用计算资源方面非常低效，其架构和打包方式可能是导致低效的原因。

3.2 重构的决策步骤

重构单体应用程序的过程需要做出一些决策：
1. 是否保留现有部分 ：有时，单体应用程序需要从头重新构思和实现。如果应用程序使用的语言、框架或工具包不再受支持，或者当前团队缺乏相关技能，完全重写可能是唯一的选择。但由于成本和时间的原因，完全重写通常不可行。在这种情况下，最好的方法是重构现有代码，在不改变其行为的前提下改善其结构。
2. 是否拆分应用程序 ：需要考虑不同部分的应用程序是否有不同的扩展需求。如果所有部分的扩展需求相似，你可能希望暂时将它们保留在一起；如果有不同的扩展需求，则可以考虑使用“扼杀单体应用（Strangle the Monolith）”方法将应用程序拆分为不同的分布式组件。

3.3 重构的注意事项

重构大型应用程序不是一蹴而就的，需要深入了解云的工作原理和应用程序的功能。团队通常会先使用“提升并转移”方法将应用程序迁移到云端，以获得在云端工作的经验。在重构过程中，需要确保应用程序的行为在重构过程中不发生改变，这意味着需要有足够的测试覆盖，并拥有自动化测试策略，以便在每次重构步骤前后快速运行测试。

3.4 重构案例

3.4.1 已发布的案例

Allen Fang 发布了一篇关于 Shopback 如何重构单体应用程序的案例研究，该应用程序使用了许多常见的模式，如命令查询职责分离（CQRS）和防腐层（Anti-Corruption Layer）。
威睿 Tanzu 团队记录了他们如何将示例单体 SpringTrader 应用程序重构为微服务，以便部署到 Cloud Foundry 上。

3.4.2 航空公司案例

一个航空公司团队将一个传统的本地 Java 应用程序现代化为云原生应用程序。该应用程序最初是一个 Web 表单应用程序，客户资料信息和正在进行的预订数据存储在本地的 Oracle 关系数据库中，而预订交易和座位预订工作由后端大型机应用程序完成。

团队利用一个高优先级的高管需求（航班取消或延误时的自动重新预订功能）作为契机，开始了现代化之旅。他们首先在传统网站内构建了一个单页应用程序（Single-Page Application）来管理重新预订，并使用云原生方法和微服务构建了新的业务逻辑。

在接下来的阶段，团队将网站中的一些现有代码重构为新的微服务，使所有预订都可以通过新的云原生应用程序进行。他们还将基于单页应用程序的方法改为使用微前端（Micro Frontends）来表示网站新部分的多个用户体验。

最后，团队将剩余的单体应用程序进行容器化，并将其迁移到云端，仅对其进行必要的更改，以将其迁移到云数据库而不是原来的 Oracle 数据库。这种巧妙的技术被称为“最后提升并转移（Lift and Shift at the End）”，是他们重构单体应用程序努力的顶峰。

综上所述，无论是应用容器化还是单体应用重构，都有各自的优势和挑战。在实际操作中，需要根据应用程序的具体情况和业务需求，选择合适的方法和策略，以实现应用程序的高效迁移和现代化。

以下是一个简单的 mermaid 流程图，展示应用迁移与重构的主要步骤：

graph LR
    A[现有应用程序] --> B{选择迁移方法}
    B -->|提升并转移| C[迁移到云端]
    B -->|应用虚拟化| D[虚拟服务器部署]
    B -->|应用容器化| E[容器化部署]
    C --> F{是否需要重构}
    D --> F
    E --> F
    F -->|是| G[重构单体应用]
    F -->|否| H[持续运行]
    G --> I[模块化或分布式架构]
    I --> J[云原生微服务]

以下是一个表格，总结虚拟服务器和容器的对比：
| 对比项 | 虚拟服务器 | 容器 |
| ---- | ---- | ---- |
| 重量 | 重量级 | 轻量级 |
| 启动速度 | 慢 | 快 |
| 资源利用效率 | 低 | 高 |
| 可移植性 | 低 | 高 |
| 配置一致性 | 易漂移 | 高一致性 |
| 运营成本 | 高 | 低 |

4. 应用迁移与重构的综合考量

4.1 不同迁移与重构方法的适用场景

在选择应用迁移与重构方法时，需要根据应用的具体情况来决定。以下是不同方法的适用场景总结：
| 迁移与重构方法 | 适用场景 |
| ---- | ---- |
| 提升并转移（Lift and Shift） | 应用对现有硬件和软件环境依赖较小，希望快速将应用迁移到云端，以获得云计算的一些基本优势，如弹性扩展等。适合作为初步探索云计算的方法。 |
| 应用虚拟化（Virtualize the Application） | 团队熟悉虚拟服务器技术，且应用可以在虚拟服务器环境中较好运行。当需要快速迁移应用且对应用本身改动较小时适用，但长期来看可能存在一些局限性。 |
| 应用容器化（Containerize the Application） | 应用具有一定的独立性，且需要更高的资源利用效率、更快的启动速度和更好的可移植性。适合云原生应用的开发和部署。 |
| 重构单体应用（Refactor the Monolith） | 应用发展混乱，频繁变更困难，资源使用低效，或者难以进行虚拟化和容器化。希望将应用现代化为模块化或分布式架构，以提高可维护性和扩展性。 |

4.2 迁移与重构的实施流程

为了更好地实施应用迁移与重构，以下是一个通用的实施流程：
1. 评估阶段
- 对现有应用进行全面评估，包括应用的功能、架构、依赖关系、性能等方面。
- 确定业务对应用的需求，如可用性、扩展性、成本等。
- 根据评估结果，选择合适的迁移与重构方法。
2. 规划阶段
- 制定详细的迁移与重构计划，包括时间表、资源需求、风险评估等。
- 准备必要的环境和工具，如云计算平台、容器编排工具、自动化测试工具等。
3. 实施阶段
- 按照计划进行迁移或重构操作，如使用“提升并转移”方法将应用迁移到云端，或者进行应用的容器化和重构。
- 在实施过程中，进行充分的测试，确保应用的功能和性能不受影响。
4. 监控与优化阶段
- 迁移或重构完成后，对应用进行监控，收集性能数据。
- 根据监控结果，对应用进行优化，如调整资源配置、优化代码等。

4.3 风险与应对策略

在应用迁移与重构过程中，可能会遇到一些风险，以下是常见风险及应对策略：
| 风险 | 应对策略 |
| ---- | ---- |
| 技术风险 | 如对新的技术（如容器化、微服务）不熟悉，导致实施困难。可以提前进行技术培训，引入专业的技术人员进行指导。 |
| 业务中断风险 | 迁移或重构过程中可能会导致业务中断，影响用户体验。可以采用分阶段实施的方法，先在测试环境中进行充分测试，再逐步迁移到生产环境。同时，制定应急预案，以应对可能出现的业务中断情况。 |
| 数据丢失风险 | 在迁移过程中，可能会出现数据丢失的情况。需要在迁移前进行数据备份，并在迁移过程中进行数据验证，确保数据的完整性。 |
| 成本超支风险 | 迁移与重构可能会超出预算。在规划阶段进行详细的成本估算，并在实施过程中严格控制成本，及时调整计划以避免成本超支。 |

5. 总结与展望

5.1 总结

应用迁移与重构是云计算时代应用现代化的重要手段。通过应用虚拟化、容器化和重构单体应用等方法，可以提高应用的性能、可维护性和可扩展性，降低运营成本。不同的方法适用于不同的场景，在选择时需要综合考虑应用的特点和业务需求。同时，在实施过程中需要遵循一定的流程，充分考虑可能出现的风险，并采取相应的应对策略。

5.2 展望

随着云计算技术的不断发展，应用迁移与重构的方法也将不断创新和完善。未来，可能会出现更加自动化、智能化的迁移与重构工具，进一步降低实施难度和成本。同时，云原生技术将得到更广泛的应用，微服务架构将成为应用开发的主流趋势。企业在进行应用迁移与重构时，需要紧跟技术发展的步伐，不断提升自身的技术能力和创新能力，以适应市场的变化和竞争的需求。

以下是一个 mermaid 流程图，展示应用迁移与重构的实施流程：

graph LR
    A[评估阶段] --> B[规划阶段]
    B --> C[实施阶段]
    C --> D[监控与优化阶段]
    A --> E[评估应用情况]
    A --> F[确定业务需求]
    A --> G[选择迁移与重构方法]
    B --> H[制定详细计划]
    B --> I[准备环境和工具]
    C --> J[执行迁移或重构操作]
    C --> K[进行充分测试]
    D --> L[监控应用性能]
    D --> M[根据结果优化应用]

总之，应用迁移与重构是一个复杂而又重要的过程，需要企业认真对待，合理选择方法和策略，以实现应用的高效迁移和现代化，为企业的发展提供有力支持。