平迁上云方案
产品选型策略
针对传统应用平迁上云场景，常见产品对标选型策略如下图所示。
场景示例1：单体应用迁移
云上重部署应用
针对平迁方式的应用上云场景，对于已有成熟CI/CD工具及流程的企业，我们建议优先使用现有CI/CD工具，在云上重新部署应用。
对于还没有构建CI/CD能力的企业，我们建议先使用云上DevOps产品构建企业的CI/CD自动化平台，通过CI/CD流水线，在云上重新部署应用。基于阿里云云效产品构建CI/CD流水线如下图所示。
镜像迁移
对于普通单体应用，也可以使用阿里云自主研发的迁移平台服务器迁移中心（Server Migration Center，简称SMC），可将单台或多台迁移源迁移至阿里云。迁移源（或源服务器）概指企业待迁移IDC服务器、虚拟机、其他云平台的云主机或其他类型的服务器。在应用服务迁移过程中，使用SMC服务将在IDC部署的业务应用服务自动、快速、一站式迁移到云上ECS，同时提供工具支持将自建Kubernetes的应用迁移到云上。更多详细信息，请参见最佳实践概览。
场景示例2：微服务应用迁移
对于微服务应用上云，可以使用阿里云企业级分布式应用服务EDAS（Enterprise Distributed Application Service），它是一个应用托管和微服务管理的PaaS平台，提供应用开发、部署、监控、运维等全栈式解决方案，支持SpringCloud、Dubbo等微服务运行环境。
对于Spring Cloud Edgware及以上版本和Dubbo 2.5.3及以上版本的微服务应用，无需修改任何一行代码即可迁移至EDAS。
针对Spring Cloud和Dubbo微服务框架应用迁移上EDAS，有两种方案，切流迁移、双注册和双订阅迁移。这两种方案都可以保证您的应用正常运行且不中断地完成迁移。
切流迁移
使用Dubbo将原有的服务注册中心切换到微服务引擎（Micro Service Engine，简称MSE），在云上部署一套新的应用，最后通过SLB和域名配置来进行切流。
双注册和双订阅迁移
- 在应用迁移时同时接入两个注册中心（原有注册中心和EDAS注册中心），保证已迁移的应用和未迁移的应用之间能够相互调用。通过双注册和双订阅迁移应用的架构图如下。
- 支持在不重启应用的情况下，动态地变更服务注册的策略和服务订阅的策略，只需要重启一次应用就可以完成迁移。
- 已迁移的应用和未迁移的应用可以互相发现，从而实现互相调用，保证了业务的连续性。
- 使用方式简单，只需要添加依赖，并修改一行代码，就可以实现双注册和双订阅。
- 支持查看消费者服务调用列表详情，实时地查看迁移进度。
- 更多详细信息，请参见产品最佳实践平滑迁移微服务应用至EDAS
优化上云方案
场景示例：应用容器化上云
以Kubernetes为代表的容器技术正成为云计算新界面。容器提供了应用分发和交付标准，将应用与底层运行环境进行解耦。Kubernetes 作为资源调度和编排的标准，屏蔽底层架构差异性，帮助应用平滑运行在不同基础设施上。
应用容器化规范化改造
容器化的应用必须要规范化，我们不希望所完成的容器镜像只能在生产环境中运行，也不希望该容器有着外部依赖，我们希望应用在容器化之前，最少满足这三项要求：
- 与操作系统解耦，能在各种系统中运行并有极大的可移植性
- 适合部署在现代的云平台上，配置与代码分离
- 开发与生产环境对等，能够使用现代的包管理工具实施封装打包
所以，对应用进行容器化前，必须对应用进行检查并实施类似的改造，也就是进行应用规范化，规范化的过程根据已有应用的实际情况有较大的不同，一般来说，越是现代的、面向互联网的应用越容易容器化。对容器化应用的规范化改造有以下内容：
- ·准代码：明确一份代码，多分部署的原则，一个应用程序只能有且只有一个代码库或一个主库，确保该代码库中能够支持开发、测试、构建操作。
- 依赖管理：大多数编程语言都会提供一个打包系统，用来为各个类库提供打包服务，我们期望应用程序能够显式的表示自己的依赖，使用pom.xml或者package.json来描述自己的全部依赖，不要有隐式依赖。这样能够为开发者和流水线简化配置流程，可以完成一句话构建。
- 配置注入：数据库地址、三方证书、API Key等等这些在不同环境下有区别的配置应该能够独立注入，我们要求在不同环境下，容器一致，但配置不同。可以使用环境变量或 Config Service 方式进行管理，使用Config Service时也需要做到无依赖。
- 服务配置化：后端依赖的服务比如数据库MySQL、PostgreSQL、缓存、队列等都需要做到可配置化，将配置拿出，系统不应该区别对待这些服务。
- 进程整理：应用程序尽量做到一个进程运行，如果使用多个进程比如Nginx + PHP也可以接受，但一定要目的单一，易于管理。同时也需要保证进程的无状态特性，使用内存存储 session 造成粘性是无法接受的，并且状态应该持久化入数据库。单一的、无状态的进程也可以反映到并发上。
- 易处理：表示可以瞬间开启或停止，这有利于快速、弹性的伸缩应用，迅速部署变化的代码或配置 ，稳健的部署应用。当然也需要支持优雅的终止，即受到SIGTERM后会处理完任务，或者在服务中心注销，再进行关闭。
容器化上云流程
传统应用容器化大致分为五个阶段：
- 应用现状分析：梳理应用使用的资源、系统的逻辑架构拓朴、应用服务的所有数据依赖、应用上下游服务依赖关系、服务所依赖的进程、系统中需要保留的重要日志及数据、数据和文件权限等；
- 方案规划和设计：根据前期对应用系统现状的调研和分析结合容器平台特性，应用系统产出新的系统架构图和迁移的改造计划，比如是直接容器化上云还是改造后再容器化上云，以及容器化后业务系统功能和性能测试方案、系统的割接方案等。
- 编写Dockerfile：若要打包应用程序以供在Docker中运行，需要编写脚本文件Dockerfile，用于自动执行所有应用程序部署时需要执行的步骤。这通常包括一些Shell配置命令，以及用于复制应用程序包、设置所有依赖项的指令，也可以解压缩已压缩的存档或安装包。Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。在Docker镜像使用中，我们最好把经常变化的内容和基本不会变化的内容要分开，把不怎么变化的内容放在下层，创建一个基础镜像供上层使用。
- 生成镜像：使用docker commit命令将某个container的环境提交成为持久化的docker image。使用docker build命令基于dockerfile构建。这种构建方式的优势在于可以通过docker history命令溯源镜像的生成过程。并且消除了docker commit可能把一些不需要的东西误提交的隐患。镜像构建成功后，只要有docker环境就可以使用，通过利用docker push命令将镜像推送到镜像仓库中去。
- 应用部署：将docker镜像部署到对应Kubernetes集群应用。在Kubernetes集群上需要用到的部署模板，在具体实施过程中，可以根据不同的模板来部署到对应不同的集群。
重构上云方案
传统单体应用架构问题
- 单体应用复杂度高，应用迭代发布周期慢，无法支撑业务快速发展的需求。
- 开发者需要关注架构的所有细节（限流、熔断、降级等服务治理，数据访问及消息通信）。
- 运维需要负责底层基础设施（包括数据库、缓存、虚拟机等）的稳定性。
云原生应用架构
云原生应用架构特点
- 应用代码按业务域拆分解耦，降低复杂度。
- 开发者只需关注业务逻辑，与业务不相关功能下沉到云基础设施。
- 技术体系走向开放和标准。
- 运维无需关注基础设施稳定性，更多精力专注于自动化。
云原生应用架构建议
云原生应用架构示例，如下图所示。
- 微服务解决“应用架构复杂度”问题。
- 服务治理解决“业务开发关注与业务无关的限流、熔断、降级能力”。
- 容器解决应用“部署问题”问题。
- Kubernetes解决应用“编排和调度”问题。
- Service Mesh解决“侵入性微服务改造”问题。
场景示例：应用微服务化重构上云
对于复杂应用系统来说，单体应用架构代码复杂度高、可扩展性差、业务开发及部署周期慢，不能满足现业务发展需要。对于业务复杂的单体应用系统上云需求，我们建议以微服务化重构改造上云。
核心问题
- 服务拆分
如何将单体应用进行服务化改造，是“一步到位，推倒重来”还是“循序渐进的蚕食”，选取哪些功能或业务进行服务化改造，如何减少对原单体应用的修改等，这些都是在服务拆分时首要面对的问题。 - 跨服务查询
单体应用里实现查询相对简单，因为具有统一的数据库。但在微服务架构下，一个查询可能需要检索分布在不同的服务中数据，而这些服务都会拥有自己的数据库。传统的分布式数据查询机制不适用，因为会打破服务之间的数据隔离性，该隔离性要求以服务的形式提供数据，不能直接暴露数据库。
改造原则
- 渐进式，不要“推倒重来，一步到位”
- 快速见效、快速收到回报、可挑选出高价值的模块先进行服务化改造，更早的拿到结果来获得业务团队的支持。
- 减少对单体应用的改动
- 单体应用的修改是不可避免的，重要的是要减少改动同时保持数据一致性。
- 改造主要从业务维度入手，少量的技术维度。
- 拆分时做“垂直切片”
- 含业务逻辑、库表结构等前后端逻辑。
改造策略
（1）新业务构建为服务
将新的业务或功能以服务的形式进行构建，这不仅会阻止单体扩大和继续发展，快速开发出新业务功能，更体现出微服务架构的价值。常见的办法是对新业务进行领域建模，得到领域模型、服务接口等必要元素。但同时会带来问题，即新旧系统结合，即微服务与单体应用怎么协作。
- 问题识别
无论是新构建的微服务，还是旧系统提取的新服务，都会面临新旧系统如何结合的问题。新的微服务与单体应用同时存在，许多业务还需要新旧系统彼此协作才能完成。但新旧系统存在各种差异，如：协议不同（微服务以REST为主，而单体式可能基于SOAP或TCP），模型不同（实体、名称及属性等）。我们推荐的方案是使用双向代理层来完成新旧系统的交互与对接。 - 解决方案
- 双向代理层
在微服务和单体应用之间构建一个双向代理层，通过代理层完成新旧系统的对接集成，避免相互干扰，保持彼此松耦合状态。代理层还可以对单体式应用进行服务化封装，让其像微服务一样以 REST的方式对外服务。代理层支持双向通讯，重点解决新旧系统对接集成、协议适配和模型转换等问题，按照此功能定位我们可以将代理层划分成三个模块： - - 旧系统侧的集成对接：采用外观（Facade）模式，屏蔽旧系统内部细节，简化新系统对接的复杂度。 - 旧系统侧的协议适配：采用Adapter模式，向新系统提供所需的服务实体，负责请求和应答的协议适配。 - 领域模型转换器：负责请求和应答中新旧系统领域模型的转换，新旧系统都需要。 - 领域事件 单体与微服务之间的数据交互，使用API是较为直接的方式。但当一方数据变化后，API方式无法主动进行通知。因此，另一个方式是基于领域事件的数据同步。比如：单体应用发布领域事件，微服务进行订阅。当单体数据产生变化时，可以通过领域事件的方式通知微服务，微服务获取事件，更新本地数据，供本地业务查询使用。
（2）业务功能提取为微服务
- 挑战：对单体应用做拆分时，采取的策略是自上而下的“垂直切分”，要涵盖被拆分的业务的全部逻辑，主要包含业务逻辑及数据库表。为此带来了一些挑战：
- 领域模型的拆分：跨服务的对象引用、通用类的拆分等
- 数据库表的拆解分，如：从已有的表中拆出新表
- 提取入口：关于提取哪些部分进行服务化，一个重要判断点是否能给业务快速带来价值，而价值可以从新业务上线效率，或解决棘手的性能及扩展性等方面来考虑。一般来说，具有下面特点的功能模块可以入手来做改造，提取功能为服务后，同时也需要重构数据库。如：改造数据库的库表结构，提取并创建新服务对应的表及数据。
- 频繁变化（业务维度）
- 频繁调用
- 相对独立
- 共享的基础数据
- 计算密集型（利于弹性伸缩，技术维度）
- 最小化改造：对单体应用进行改造，势必会带来领域模型、库表结构等的变化。例如：我们拆分订单业务，提取出送货子业务。这些变化会直接影响代码，即要求对变化的部分做出代码调整。由于每一处访问变化部分的代码都需要，这会直接修改单体应用的代码，可能带来较大工作量，这是我们不愿意看到的，因为大量工作花费在要被替代的单体应用上。理想的方式是，在拆分出新服务的同时，不修改或尽量减少修改原有单体应用。
- 保持单体应用的数据库结构基本不变；
- 拆分出的新服务使用独立的新库表结构；
- 新服务获取数据后写入新的库表；
- 使用触发器之类机制将新库表的数据同步到单体应用库表；
- 在单体应用里，只需修改代码去调用新服务即可；数据读取可依赖原有单体应用。
专项上云方案
数据上云方案
数据上云架构设计
数据在同一业务库中采用多租户隔离机制；为数据服务层建立一套统一的管理规范，所有业务用户账号在完成相关审批流程后对相应的数据字段进行授权安全访问，对数据只有读的权限，不能对原始数据进行直接修改或删除，做到数据不搬家，可用不可见；建立统一的数据资源视图和数据血缘跟踪能力，能够对所有的数据的生命周期进行溯源查询，用以甄别数据变更过程中的真实性和准确性；根据不同业务场景结合流程节点和风险管控要求，对相关数据进行分析、建模、挖掘，提高数据服务支持。
数据上云安全防护
在企业数据迁移上云的过程中,实施数据分层保护功能已成为一个关键优先事项。同时，数据保护控制必须辅之以强大的监控工具和访问管理控制,以构建数据的整体视图，对数据的全生命周期进行监控。重点考虑以下关键数据保护领域。
- 数据分类：围绕数据识别、清单、标签和分类的功能和流程；
- 静态数据保护：有关加密/令牌化的解决方案和注意事项,包括密钥管理；
- 传输中数据保护：功能包括 TLS/SSL 层保护、数据丢失防护解决方案和安全数据传输；
- 数据监控：通过操作中心 (SOC) 进行日志记录和监视功能；
- 在云环境中,以数据为中心的保护需要在整个数据生命周期中进行。
阿里云数据上云迁移最佳实践
数据库上云
包含关系数据库及NoSQL数据库上云等场景，以Mysql为例，主要考虑以下几点：
- 根据性能场景需求，选择匹配的产品及实例规格，以最低成本达到业务需求
比如RDS和PolarDB，RDS主要是主备模式，读写IO在单机上执行，走主机总线，RT相对较低，而PolarDB是云原生的读写分离架构，读写IO会走网络，RT相对较高。从产品架构上分析，对于RT要求比较高的场景，建议使用RDS，其他情况，相同规格PolarDB实例一般比RDS QPS性能要高。 - 未来数据增长
未来三年内数据增长，如果超过单实例最高规格性能，建议PolarDB-X，通过水平切分的方式，将数据分布在多个底层mysql库，通过并行的分布式数据库操作来实现性能的提升。 - 迁移过程数据膨胀
全量数据迁移过程并发INSERT导致目标实例的表存在碎片，全量迁移完成后目标实例的表空间会比源实例大（迁移完成后可通过optimize table合并碎片，优化存储空间），所以建议选择实例规格时，预留一定的存储空间以防存储打满； - 识别无主键表
无主键表不支持增量迁移，需要提前识别，对于无主键表单独做全量迁移。
阿里云数据库上云迁移工具及最佳实践
数据传输（Data Transmission，简称DTS）是阿里云提供的一种支持关系型数据库、 NoSQL、OLAP等多种数据源之间数据交互的数据服务。DTS的数据迁移功能支持同构或异构数据源之间的数据迁移，同时提供了库表列三级映射、数据过滤等多种ETL特性，适用于多种数据库迁移上云场景。
存储数据上云
主要指非结构化数据，常见于内容管理类型的应用系统，涉及大量文件对象的存储和管理，传统的解决方案包括：
- 本地磁盘存储，数据定期备份。但这种方案存储容量和性能的扩展性、存储自身的高可用性等问题。
- 采用IP-SAN、NAS等对数据做集中存储，这种方案成本较高；
- 在数据库中存储文件。这种方案成本高，对数据库的存储资源消耗和性能影响都比较大。
针对文件对象存储，阿里云提供开放存储服务（OSS），具备高可用、高扩展、高效性、低成本等特点，能有效解决内容管理类型应用的文件对象的存储问题。应用系统需要基于OSS进行相关改造，主要包括：
- 根据应用系统文件的存储结构在OSS中规划Bucket，以及文件目录结构；
- 设置Bucket访问权限（public-read-write/public-read/private），对于安全级别要求高的应用，可设置文件在OSS上以密文形式存储；
- 对程序代码进行扫描，查找出涉及文件向存储读写的代码，将这些代码改造为以OSS SDK接口的实现。
阿里云存储数据上云迁移工具
阿里云在线迁移服务是阿里云提供的存储产品数据通道。使用在线迁移服务，可以将第三方数据轻松迁移至阿里云对象存储OSS，详情请参见在线迁移服务。
建立上云迁移组织及保障机制
在上云迁移实施前，需要建立迁移组织及保障机制，明确各小组职责及成员，确定保障机制把握项目工作进度和工作质量。
迁移组织架构
根据阿里云以往项目经验，建议组织分为以下小组，如下图所示，各小组职责如下。
- 项目管理办公室
- 负责项目进度、风险及问题管理，以及内部宣贯。
- 实施架构组
- 负责总组上云方案、割接方案设计，以及项目实施过程中技术风险把控。
- 应用开发组
- 负责应用开发、部署及应用迁移实施工作；
- 运维组
- 负责云上资源管理、数据组、中间件迁移实施及数据校验工作；
- 测试组
- 负责功能测试、联调测试及性能测试工作。
项目实施保障机制
建立项目管控机制，把握工作进度和工作质量，包含以下内容：
- 内部定期沟通计划
- 项目周报制度
- 问题和风险分析计划
制定迁移实施计划
由于上云迁移实施存在风险，所以，在应用上云实施执行前，我们建议制定详细的实施计划。这个计划表里面包含了上云迁移及割接过程的全部任务、时间段、各方人员等。项目实施过程按照这个计划表跟踪执行即可。下图给出一个示例模板，在具体的项目中可以根据项目需求来设计定制。
功能测试及联调测试
在应用上云割接前，需要进行充分的功能测试与联调测试，验证云上环境应用运行情况。功能测试及联调测试依赖企业自己的测试团队及流程工作，不作过多描述，仅在此建议，对应用功能点进行分级，优先测试验证核心功能点，对不同级别功能点测试问题，制定不同紧急程度的问题跟踪。
性能测试
性能测试方案
性能测试流程
业务测试模型构建
业务测试模型构建主要是根据搜集到的性能测试需求和生产系统的相关信息完成性能模型的构建工作，并指导性能测试过程以及测试结果的生成。
监控性能指标
监控指标包含业务监控指标、操作系统监控指标、中间件监控指标、数据库监控指标，旨在监控从各个维度描述压测时性能表现。
构建性能测试数据
测试数据主要包含两类：
- 基础测试数据
基础测试数据一般取自生产环境真实请求日志。基础测试数据非常适合真实业务模型，当然，也可以对基础测试数据进行过滤处理，获取单一业务场景测试数据。 - 采用参数化测试数据
参数化测试数据主要根据业务请求参数，按测试模型场景构建。参数化测试涉及的范围很多，比如需要准备大量用户名及相应密码参数数据；模拟纳税人纳税申报，需要准备大量的纳税人识别号、纳税人内码或纳税人系统内部识别号等参数数据，这类数据准备要求符合实际运行要求并且保证数据表之间的关联关系。
测试场景
常见性能测试场景，主要包含以下几种：
- 基准测试
- 基准测试的目的是检查业务本身是否存在性能缺陷。同时为将来的混合场景的性能测试性能分析提供参考依据。
- 稳定性测试
- 稳定性测试主要侧重系统在持续的压力情况下，长期运行时的业务处理能力及系统可能存在的缺陷。
- 业务突变测试
- 业务突变测试主要考察当业务进行突变以后，系统是否出现异常情况，资源在突变前后变化情况。
- 可靠性测试
- 可靠性测试主要是模拟各种故障（网络中断，服务异常、HA切换）下，系统是否能正确切换，处理能力是否有明显变化。
测试实施及报告
基于测试工具，构建对应测试场景的脚本，执行后，通过测试结果，并根据观测的性能指标，撰写测试报告；
测试工具
阿里云性能测试PTS（PerformanceTesting Service）产品是面向所有技术背景人员的云化测试工具。PTS是具备强大的分布式压测能力的 SaaS 压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。
PTS 目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在PTS 平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量最佳配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。详情参见什么是性能测试PTS
割接上线前的准备
应用的割接上线是整个应用上云迁移实施的最关键环节，这一环节出问题，可能会造成重大故障。针对割接上线的重要性，我们建议在实施应用割接前，制定详细的割接前检查清单,这个清单的严谨程度也许很大程度上决定了割接成功率。根据我们以往的经验，对割接上线前的准备工作，以下给出几点经验：
- 割接前需要严格确认是否所有需要预先准备的工具、迁移环境（客户本地数据中心端、网络、云端）等已经就绪。
- 检查和确认云环境Landing Zone已经就绪，并且确认云环境中的规模，安全，控制，网络以及身份验证与设计保持一致。
- 割接上线时需多方人员参与，软件厂商、集成商、用户方、云厂商等,确认这些相关人员是否已经就绪。支持的方式是现场、远程还是电话。
- 回滚预案是否就绪。割接过程好像在打一场大的战役，很多的任务或子任务会分配半小时内计划执行结束，整个过程可能会非常紧张。为降低压力，即使因为某个主客观原因导致迁移无法成功进行，如果有补救措施会让整个迁移团队降低很多压力。这个补救措施之一就是回滚预案，也即是失败后回滚到客户的原数据中心恢复业务应用，需要在割接时预留回滚执行的时间。回滚执行后，然后拥有充足的时间排查问题，以备下一个割接窗口期内再次割接。
- 根据项目实际场景，设计一个检查清单，这个清单包含了迁移割接任务的全部前置条件。下图给出一个检查清单的示例模板，在具体的项目中可以根据项目需求来设计定制。
制定详细的割接实施方案
迁移项目是复杂的，大部分迁移割接的时候都会或多或少的遇到一些无法预料的问题。造成割接失败，可能有主观原因和客观因素。主观原因可能因为迁移调研问题、迁移方案设计缺陷、迁移验证过程不够全面等。客观因素通常是客户IDC、运营商网络、云数据中心故障等。无论哪种问题导致，都可能会对迁移割接造成失败。根据以往的项目经验，我们建议在割接前制定详细的割接实施方案，以下是关于割接实施方案的一些建议。
- 数据验证，确认割接时与割接前数据保持一致。通常客户的大部分服务器镜像及数据会在割接前预先在云端复制完成。在割接窗口期开启后需要确保云端复制的数据与客户数据中心下线前保持严格一致。
- 并非所有问题都会导致迁移失败。遇到问题的时候，首先评估问题的严重程度，如果不是关键业务应用的重要的问题，可以将割接流程继续进行，同时该问题继续解决。与客户协商，该问题是否会对业务有很大影响，如果客户可以接受的话，可以先上线，然后尽快解决该问题。
- 迁移时间拖延问题处理。如果割接时不够顺利，因为种种主客观原因导致迁移割接时间长于计划时间，可以与客户协调，一起决定是否可以延迟一些时间上线。通常设计割接计划时都会留出一些缓冲时间，如果需要延迟的时间过长是客户无法接受的，那就只能执行回滚预案了。
- 网络切换问题处理。比如IP,端口，网络配置,DNS等问题，在之前的调研和检查中出现遗漏。这种问题在割接时经常会遇到，出现这种问题紧急联系相关负责方尽快解决，但并不一定会影响割接整体进行。
- 迁移的不仅是服务器或数据。而是整个企业的IT应用及环境，客户应用需要的身份管理、安全配置、数据及系统备份、高可用性架构配置，容灾方案等都需要完成。
- 严格按照迁移设计方案中指定的云服务型号匹配云上资源。拿VM举例，通常云上会提供十几个系列，数百种VM型号，使用错误的VM即使能够将服务启动起来，但会带来性能、功能以及成本的问题。
- 迁移过程确保安全合规。数据迁移严格使用加密数据传输，加密数据存储。证书、密码、权限按照合规的方式申请和使用，杜绝泄露隐患。避免因安全合规性问题带给客户严重损失。
- 制定详细的割接及回滚步骤，明确每个步骤执行时间点，前置条件，相关责任人等。以下是割接及回滚步骤的示例模板，在具体的项目中可以根据项目需求来设计定制。
割接实施步骤模板示例：
回滚实施步骤模板示例：
割接后持续观察验证
割接后对迁移的应用云上运行情况持续观察验证，做好业务和数据做好监控，持续观察业务的运行状态，直到确认完全没有问题，割接执行工作才算基本结束。
