业务痛点
自2016年开发迁移工具主要面向私有云环境，但是随着公有云用户越来越多，我们迫切的希望以一种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月份在阿里云上线内部测试版本，到今年春节之后正式邀请客户进行使用，并且今年春节后推出了“零接触”云迁移免费3个月时间。能在这么短的时间内，将一款单机版本的软件具有多用户并发支持能力的SaaS平台，云原生提供的支持功不可没。
在没有增加人力的情况下，运维压力并没有过多增加，云原生的方式提供天然的容灾、备份服务，使得运维人员很轻松的简单配置就可以实现传统运维需要大量安装和配置的效果。
利于成本控制，具有高度可扩展性。由于迁移本身是具有一定专业性的产品，用户以企业用户为主。所以客户增长的速度可能不会像C端增长明显，所以采用按量计费的方式可以更精细化的控制成本。同时，基于云的扩展性，用户量一旦激增后，也可以轻松应对。
函数计算服务的使用，简化了开发成本，运维成本直接降为零。目前将License服务使用函数计算提供，如果使用传统方式构建，我们至少需要http服务端、定义接口等开发，再加上部署上打包成容器、部署等操作，成本很高。但是如果使用阿里的函数计算服务，天然支持http trigger方式，我们只需要在函数中定义接口，发布一下马上就可以使用了。并且函数计算拥有详细的监控，调用统计等信息一目了然，通过日志服务收集日志信息，可以用于后续的分析。
选用的产品