在云计算市场规模不断扩大的大背景下，云迁移的需求越来越大且面临挑战。云迁移不是一个迁移软件工具，而是一种服务。前IBM资深架构师姜亚杰从云迁移的三个阶段、四个维度到八个步骤的方法，简述业务连续性实施方法论。分享了“平台 + 工具 + 服务”的云迁移解决方案，最后通过简述4个典型的云迁移场景分析教你如何做好云迁移。

数十款阿里云产品限时折扣中，，领券开始云上实践吧！

以下是精彩视频内容整理：

云计算作为IT基础架构已经成为不可逆转的趋势

根据Gartner预测，截至2020年云计算市场规模将达到4114.8亿美元，同比增长约15.7%，2016-2020年复合增长率将达到约17%。根据IDC数据，2020年中国云计算市场规模将达到52.42亿美元，同比增速约21.5%，2014-2020年复合增长率将达到约33.21%，综合来看中国市场复合增长率是高于全球的。在云计算作为IT基础架构的趋势之下，企业上云需要考虑的最大因素仍旧是安全和迁移。

云迁移所面临的挑战

对于企业上云来说，想要帮助企业制定整体的应用上云、数据上云的解决方案，识别复杂系统上云风险，并辅以专业的技术力量，帮助企业安全、便捷、有序地进行迁移，保证业务的安全性、可用性、业务连续性，就会面临以下挑战：

1）物理环境、虚拟化环境、云环境以及异构混合环境是基于生产环境的不同环境，此外还有不同的操作系统、数据库、中间件和应用，也会有竖井式和分布式的架构，并且应用本身也有紧耦合和松耦合的形式，因此生产环境复杂且多种多样导致迁移方案复杂且实施困难。

2) 对生产端的影响大：例如迁移时间窗口长,客户应用厂商支持力度不够,也可能会影响系统性能和稳定性,另外逻辑迁移对网络链路带宽资源要求也比较高。

3)迁移过程中的安全保障要求比较高:确保数据的安全加密以及在数据迁移过程中保证数据一致性与完整性校验,系统的高可用性与灾备机制对于用户来说也是有相应的要求的,迁移回退保障机制也是需要考虑的问题。

4）需要专业的技术支持团队及其迁移方法与流程：目标架构的规划设计是否合理，对于云环境下是否能正常运行且尽量发挥云计算优势具有直接影响，迁移方案的合理制定和迁移工具的合理利用对于一个系统或者一个应用相互之间配合起到重要作用。迁移的阶段性保障、迁移准备中的测试验证、迁移过程中的可视化与自动化以及迁移后运维等也是需要考虑的问题。

云环境下对迁移的理解

云迁移绝不仅仅是一个简单的搬运过程，也不是某个单一迁移工具的实施，而是一项服务。从优化角度来讲，云迁移不仅是将数据从生产端拷贝到云端的过程，而是一个系统迁移与架构优化的过程。从复杂度角度来讲，云迁移是一个迁移业务的过程，而是一个复杂的、受多种因素影响的系统工程。从业务连续性角度来说，云迁移的整个过程要对业务层透明化，将对业务的影响降至最低。

云迁移方法论

云迁移方法可以从三个阶段和四个维度来看，首先分析三个阶段，第一阶段是评估阶段，主要是对现状梳理与应用系统关联关系分析，第二个阶段是设计阶段，对目标架构优化设计及迁移方案设计，第三个阶段是实施阶段，要对目标架构搭建，迁移演练及批次实施，试运行保障。四个维度则包括基础设施、技术、IT流程以及人员组织。

基于云迁移的三个阶段细分为八个主要步骤，评估阶段主要包括项目启动、现状梳理以及应用系统关联关系分析三个步骤，设计阶段包括云架构优化设计和云迁移方案设计，实施阶段包括目标架构、迁移演练及实施和试运行三个步骤。

云迁移将遵循一套完整的经过实践证明的方法论，对将要迁移的相关涉及模块进行全面梳理和评估。首先确定整个系统有多少个模块以及模块之间的关系，以业务应用为主线，梳理当前生产环境且明确出目标云环境组成模块，之后基于迁移所涉及的相关模块，确定关键服务或服务组，针对每一个服务会梳理相应IT组件通过一定的连接方式来支持一个或多个IT服务，并确定所有内部配置和外联接口。

应用系统关联关系分析是基于对当前现状的梳理，制定IT系统逻辑拓扑图，理清现有应用系统、子系统之间的输入输出关系和耦合关系，并明确对应硬件、软件、系统之间的关联关系。

基于云计算参考架构，要使得云计算充分发挥快速弹性等特点，规划目标云架构，就要考虑以下几个方面:

IT基础架构：需要考虑云平台参考架构与最佳实践以及IT基础架构优化设计，同时计算、存储、网络、安全、负载等资源也是需要考虑的问题。

运维管理:需要考虑支持国际标准ITIL的运维管理体系，运维流程标准化和实时监控告警等。

安全管控:借鉴包括安全流程管理和安全技术实现、以风险为导向的信息安全通用架构模型。

业务连续性：要考虑到是否支持业务需求以及高可用的、持续运转的企业级业务连续性参考架构。

云迁移方案设计

设计阶段大致分为四个阶段：

第一阶段是要制定迁移策略与标准，譬如总体的迁移策略与流程、迁移的批次规划原则、迁移方式的选择（逻辑迁移，物理迁移）、数据迁移技术的选择（离线迁移，在线迁移和迁移）风险等都是需要考虑的问题。

第二个阶段是制定迁移主计划，主要是划分批次和时间、制定迁移流程、迁移团队和职责的定义以及迁移风险评估和风险控制。

第三个阶段是为各个待迁移应用制定迁移详细计划，比如制定迁移步骤、验证计划（测试计划）以及应急方案和回退计划等。

第四个阶段是为批次或应用制定迁移演练计划，包括沙盘演练和数据复制/切换演练等。

迁移演练及实施

通过详细计划和全面测试，在切换和迁移前全面掌握项目风险(Reduce Risks = Detail Plan + Thorough Tests)。沙盘演练的演练迁移操作流程的主要目的是让各项目组成员熟悉迁移操作流程，而实际演练/数据复制的主要目的则是准确估计各迁移任务的时间，验证数据的完整性和一致性、测试业务的验证计划、制定检验人员分布协调沟通机制以及演练迁移操作流程。

业务连续性实施方法论

实际上迁移过程中以及迁移后都是要考虑业务连续性的，业务连续性方法论大致分为三个阶段，分析与评估阶段主要是做灾难分析、风险分析以及业务影响分析；接下来是设计与实施阶段，主要做的是容灾策略、方案设计和容灾的实施；最后是运维与管理阶段，主要做灾难恢复原和容灾流程设计。

云迁移解决方案

主要是通过“平台 + 工具 + 服务”的方式解决云迁移和云容灾的实际需求，实现了跨异构云平台之间的应用级在线热迁移功能，解决了上云迁移、多中心应用迁移、云服务商之间应用迁移的问题。对于云迁移解决方案可以从三个角度去研究，从复制的角度来讲，主要是系统的分析，然后选取迁移的主机，部署与源端相同配置主机，再通过I/O捕获机制，实时传输至目标端。从迁移角度来说主要是恢复数据至目标端主机，恢复应用于目标端主机以及迁移过程自动化、可视化。从监控角度来说主要包括主机的状态监控、复制状态的监控以及应用健康状态的监控。

云迁移方案总架构

迁移两端主机（含虚拟机与物理机）均安装迁移Agent, 用来进行主机状态监控与数据迁移，在源端与目标端分别部署迁移控制器与Agent，然后迁移平台进行双向通信。通过应用关联关系分析，将紧耦合的系统组成一致性组，基于一致性组的切换实现应用级迁移，并且源端与目标端之间需要具备稳定网络连接。

数据复制原理与数据加密机制

首先要将源端的数据与目标端做同步，当源端的数据发生变化的过程中就要在系统层面捕获操作系统I/O，因为捕获操作系统I/O相对比较小，占用的互联网宽度也就比较小。之后把增量传出到目标端，目标端再从系统层以I/O的形式写入到存储，最后进行对数据进行时间校验、逻辑校验并写入存储。

基于原子服务的流程自编排

简单的说就是将每一个云端的服务形成一个原子服务，然后将原子服务自编排，编排成一个支持串行与并行的流程，编排的输入参数可自动关联前序原子服务输出参数，除输入参数必填之外，还支持执行时手工填写、参数传递与脚本的执行，同时实现了手工原子服务编排与自动化脚本执行，并且支持原子服务执行异常后的跳过功能与手工参数传递。

典型场景

P2V

迁移时间窗口较长，可采用备份/恢复或数据库倒入/倒出方式，若迁移时间窗口短，则采用在线P2V工具或P2V是用户本身的环境从物理化变为虚拟化环境的一个场景，其特点是如果迁移时间窗口比数据复制工具来实现。另外还需要考虑的问题有虚拟化环境下如何做目标架构设计，以及网络的切换要保证RTO切换时间，同时应用系统关联关系也需要跟紧。如果操作系统是异构的，则需要采用非结构化数据实时复制+结构化数据倒入/倒出相结合的方式，并充分测试验证。

V2C

该场景的特点是若迁移时间窗口长，采用备份/恢复方式，若迁移时间窗口短，可考虑采用基于Hypervisor的V2C工具并切换。如果是异构数据库迁移，如mysQl to RDB，这时可以采用云平台迁移工具或服务（如DTS）。同样还有需要考虑的问题，例如云环境目标架构规划、应用系统关联关系、保证数据的一致性和完整性以及迁移演练与测试。

P2C

迁移时间窗口长，可采用备份/恢复的方式将系统和数据迁移上云，若迁移时间窗口短，可采用P2V + V2C，之后进行实时数据复制并切换，如应用系统老旧，没有厂商支持等情况下，则需要保证P2V+V2C的测试验证成功。另外还需要考虑到云环境目标架构设计、云环境网络切换、应用系统关联关系、P2V + V2C的方案有效性验证以及数据安全。

C2C

迁移时间窗口长，可采用备份/恢复或倒入/倒出方式，若迁移时间窗口短，则可采用目标端独立部署+实时数据复制并切换方式。特殊情况下，需要采用C2V + V2C工具组合的方式，对于异构数据库迁移，可采用云平台迁移工具或服务（如DTS）。此外还需要考虑：云和云之间网络打通、跨异构云平台之间的架构变更、应用系统关联关系、数据安全、迁移方案有效性验证等问题。