业务痛点
- 开发迁移工具主要面向私有云环境，随着公有云用户越来越多，需要以SaaS形态为相关客户服务。急需将工具平台化，并使其具有扩展性和可靠性，同时希望在不增加人力的情况下完成平台的运维。
- 用户担心从传统环境迁移到云平台的过程对业务系统有影响。因此需要保证迁移人员对原架构和云平台的技术能力，迁移周期管控，迁移成本和迁移后业务系统的稳定性。
- 用户对业务连续性、减少人员干预导致的风险、控制迁移周期和成本、批量高效迁移等问题要求较高。
解决方案
- 上云需求的产生——从工具到SaaS
从2016年开始，用户团队开发了针对私有云整机迁移的工具HyperMotion，这款工具基于云原生API接口开发，实现高度自动化的迁移。随着时间的发展，越来越多的企业选择将一部分负载运行在公有云上，混合云的形态越来越多。公有云迁移的需求也随之增多。所以，用户在2019年初增加了对阿里云迁移的支持。不同于私有云的迁移，如何让用户的客户更快的进入迁移流程，不把时间花在介质下载和安装的步骤呢？SaaS化是解决这个问题的最佳选择。
- 云迁移的痛点
2016年开始，在建设金融行业私有云建设过程中，迁移是私有云建设中非常强烈的刚需。同时，对后续云平台扩容起着至关重要的作用。但是用户在上云时却谨小慎微，总结其原因主要有以下几个方面：
- 如何保障业务在上云过程和上云运行的稳定性
在任何行业中，稳定、可靠是当仁不让的第一原则，对于关乎民生的金融行业更是如此。所以在实际云平台建设过程中，原有业务系统上云时往往受到的阻力最大。究其原因就是在上云过程中没有一套完整的、科学的方法论及工具让用户打消对上云的顾虑。
- 业务连续性
在上云过程中，如何保障业务系统连续性是用户尤为关注的一点，任何客户都希望在迁移过程中全程无感知，业务中断为0。但是在实际从云下到云上迁移过程中，是一个极其复杂的建设过程中，如果没有强有力的工具支撑，很难做到这一点。
- 如何选择上云方式
用户在上云方式上面临多种选择，常见的七种策略：重新托管(Rehosting), 更换平台（Replatforming), 重新购买(Repurchasing), 重构(Refactoring/Re-architecting),退役（Retire), 保留(Retian)。那么对于传统行业客户最简单、高效的就是Reshot方式。传统客户由于历史原因，积累下大量的业务系统，这些老旧的业务系统只能勉强维持运行，可能由于开发厂商的消失，根本谈不到重新部署、升级和新功能开发。所以在实际迁移时，对应用本身依赖程度越低越好。所以在众多迁移方式中，Rehost成为快速上云的不二选择。Rehost方式通常是从操作系统底层即块级别实施整体搬迁，对应用影响最小。同时，用户在快速上云后，可以逐步改造自己的业务系统，逐步将应用过渡到云原生方式。
- 迁移可验证，失败可回退
为了保障迁移后的稳定性，在正式将业务切换到云平台前，需要进行必要的验证工作。验证过程中，不能影响原有业务的运行状态。如果迁移失败，需要快速的将系统回滚至原有系统。
- 如何减少人员依赖和人为干预的风险
迁移涉及业务系统、涉及原架构、目标云架构的技术特性，因此对人员技术能力要求较高；然而过多人为干预又会导致诸如业务影响、周期控制、成本居高的问题。因此，将迁移过程工具化，将技术逻辑抽象处理并融合到操作流程中，以此降低人员技术能力要求，通过迁移工具底层运行最大化自动化迁移过程。
- 如何保障业务在上云过程和上云运行的稳定性
- 如何基于云原生资源进行云迁移
在开发之初，用户坚持使用云原生的方式构建整个迁移流程。对云原生使用方式包括云原生的API和云原生资源。
使用云原生API，能够大幅度简化繁琐的迁移流程，减少用户操作，降低出现错误的概率。并且通过对迁移流程的抽象，使迁移软件能够支持多云平台。在对接一朵新的云平台时，开发周期仅为2周。
使用云原生的资源，能够减少在迁移过程中资源转换的时间损耗。在迁移过程中，将数据直接存储在云平台块存储上，之后能够快速的将存储转换为云主机，达成迁移中验证和切换的需求。
下面以迁移中最常见的两个流程：数据同步和启动主机来说明对云原生资源的使用方式。
- 数据同步
为了实现Rehost的效果，需要使用块级别的差量同步技术来满足整机迁移的效果。如下图所示，用户分别在10点和12点进行了同步，10点同步时为第一次同步数据，所以用户会同步磁盘中的所有有效块。在阿里云侧，利用阿里云EBS作为接收端，创建一个与源端同样大小的云硬盘，将该EBS挂载到云代理同步的ECS上后，将数据直接写入该EBS设备上。在10点完成后，这块EBS设备的状态与源端数据状态一致。在同步完成后，迁移平台会调用EBS快照接口，进行快照，保留当时状态。后续用户可以使用该时间点对迁移后的系统进行验证。
在12点同步时，通过对10点到12点变化块序列的记录，同步逻辑发现系统删除了两个块，并新增了一个块。同步程序在接收端的EBS上也执行删除两个快，并复制一个块的动作，此时磁盘的状态又和源端磁盘保持了一致。完成后再次执行EBS快照操作。此时用户可以使用10点和12点的快照进行迁移验证操作。
- 启动主机
启动主机的过程其实就是由云平台的块存储转换为云主机的过程。由于阿里云目前并不支持直接用云硬盘直接作为系统盘启动，所以在阿里云处理上，采用了其他策略。整个流程如下：
- 根据用户选择的快照时间点进行主机启动。
- 通过驱动修复主机镜像和用户选择时间点的快照，重组成用于驱动修复的镜像。
- 使用该镜像模板启动主机后，进行驱动修复。驱动修复主要是解决源端环境和目标环境的驱动差异、符合目标平台管制需求。例如：在KVM平台上需要使用virtio驱动，在云平台上使用DHCP方式获取IP地址。
- 对修复好的磁盘再次进行快照，重组用于启动的迁移主机镜像。
- 进行主机启动，完成迁移验证或启动流程。用户可以登录修复后的主机，进行验证。此时，源端主机仍然处于运行状态。
- 数据同步
- 从工具到平台
在工具阶段，为用户提供产品时往往以私有化方式部署为主。用户通过镜像方式下载安装介质到本地环境进行安装。介质大小在3.6G左右，由于目前很多网盘都有速度限制，所以用户往往下载好需要几个小时。平台化后，用户无须再在将时间花在下载介质的时间上，而可以快速的进入整个迁移流程。
在单机版本软件上，往往都是一个用户进行操作，并无太多的并发压力。到了SaaS版本，首先需要实现多租户模式，意味着软件需要承受更多的并发压力，这就要求平台具备高度扩展能力，满足用户量激增的压力。
原有单机版本并发迁移时，需要用户手动对云代理节点进行扩容，在SaaS版本里为了更好的用户体验，云代理节点也应当具备弹性扩展能力。
研发团队需要用最短的时间将单机版本改造为线上SaaS版本。由于人力资源的限制，实施团队需要兼顾私有项目和线上运维，这就要求平台稳定、高可靠、易运维。所以对云原生的应用就变得尤为关键。
在由工具向平台改造过程中，必须要解决以下几个问题：
- 应用本身改造
为了支持多租户的需要，增加了单独的用户管理模块，来满足多租户的需要；同时为了满足线上运营的需求，还针对性的开发了运营模块来支撑不同角色用户的操作需求。在原有单机版本中由于客户在实施过程中基本都是本地局域网，所以源端和控制端通讯时不受制约，但是SaaS平台上线后。为了降低用户网络配置成本，需要将源端和控制端的通讯变为单向。即源端可以访问控制端，无须控制端直接与源端连接。
- 平台部署和运维
在阿里云服务选择上，尽量选择云原生的服务来满足用户的需求，通过价格比对，寻找适合用户的方案。
使用云原生服务另外的一个好处就是服务之间的关联性，几乎不需要复杂配置就可以完成，例如：监控、日志等运维支持服务。
平台上线初期采用按量计费的方式，寻找到规律后，再转为包年包月或改为资源包购买方式。
用户的所有服务都是以容器化方式进行部署，所以在选择Kubernetes托管服务商，用户对比了自建、专有版本、托管版本和Serverless版本的价格。最初为了节约成本，选择了Serverless版本，Serverless版本使用按量计费的方式，是集中模式下性价比最高的，但是随着平台上线后，用户在使用云原生监控时发现Serverless版并不支持插件的安装，导致监控和告警服务无法使用。最终，基于成本的考虑，选择了托管版本，能够满足用户的需求。
- CI流程的改造
在之前的CI流程，用户只需要提供镜像文件（QCOW2）和ISO文件。在SaaS平台上线后，流程出现了很大的变化。一方面用户搭建了三套环境：本地的Kubernetes、阿里云上的QA和生产环境。本地环境采用及时更新的策略，研发代码Review入库后，立即会更新到研发环境中。而QA和线上环境采用手动部署方式，从特定的代码分支进行部署。在镜像仓库选择上，线下环境使用Harbor，而线上环境直接使用阿里云的镜像仓库服务。CI控制采用Jenkins触发方式，所有脚本都使用代码仓库进行统一管理。
- 应用本身改造
上云价值
得益于云原生的使用，从7月份提出需求，9月份在阿里云上线内部测试版本，到今年元旦之后正式邀请客户进行使用。能在这么短的时间内，将一款单机版本的软件具有多用户并发支持能力的SaaS平台，云原生提供的支持功不可没。
- 在没有增加人力的情况下，运维压力并没有过多增加，云原生的方式提供天然的容灾、备份服务，使得运维人员很轻松的简单配置就可以实现传统运维需要大量安装和配置的效果。
- 利于成本控制，具有高度可扩展性。由于迁移本身是具有一定专业性的产品，用户以企业用户为主。所以客户增长的速度可能不会像C端增长明显，所以采用按量计费的方式可以更精细化的控制成本。同时，基于云的扩展性，用户量一旦激增后，也可以轻松应对。
- 函数计算服务的使用，简化了开发成本，运维成本直接降为零。目前将License服务使用函数计算提供，如果使用传统方式构建，用户至少需要http服务端、定义接口等开发，再加上部署上打包成容器、部署等操作，成本很高。但是如果使用阿里的函数计算服务，天然支持http trigger方式，用户只需要在函数中定义接口，发布一下马上就可以使用了。并且函数计算拥有详细的监控，调用统计等信息一目了然，通过日志服务收集日志信息，可以用于后续的分析。