可能北方地区的客户整体会更谨慎一些，因此最近我接手的云迁移项目才明显多了起来。其实早在两三年前，南方不少企业和机构就已经大规模启动了上云迁移。归纳来看，企业上云迁移主要是为了解决两个核心问题：
应用系统环境的迁移
应用系统及其运行环境的迁移难点，主要在于系统环境复杂多样，很多底层细节往往只有最初的软件开发商最清楚。针对这类应用上云场景，通常可以考虑以下几种解决方案：
使用迁云工具，将应用系统所在的服务器整体打包后迁移到云端。迁云工具的使用门槛相对较低，但不足之处在于它并不一定支持所有操作系统，尤其是一些老旧系统，当前很多迁云工具还无法兼容。使用镜像转换工具，将现有应用系统制作成镜像后再导入云平台。如果迁云工具本身不支持对应操作系统，那么即便自行制作镜像并导入云上，系统大概率也无法正常启动。此外，在镜像制作过程中，还需要安装和部署相关工具及驱动，这对实施人员的技术能力也有一定要求。联系原始软件开发商，由开发商协助在云端重新部署系统。如果能够协调开发商参与，并且应用是基于Ja va开发的，那么可以考虑使用EDAS应用托管服务，将应用软件包托管到EDAS应用容器中，从而免去日常维护应用中间件的负担。进一步来说，如果应用是基于Spring Cloud 或者Dubbo 开发的分布式系统，还可以在不修改业务代码的前提下，将分布式应用服务接入EDAS，进而解决限流降级、流量治理、健康检查等影响分布式系统稳定性的关键问题，同时实现服务拓扑、调用链追踪查询等分布式服务管理能力。数据的迁移上云
客户在评估数据迁移上云方案时，问得最多的一个问题通常都是：到底需不需要停机？
先直接说结论，应用环境本身的迁移，通常并不意味着一定要停机；而真正与停机紧密相关的，往往是数据如何迁移，以及迁移到云端之后如何完成业务切换。至于是否停机，并没有统一标准，核心还是取决于具体业务场景。比如，一个高并发、持续运行的ERP系统，和一个以新闻发布为主的门户网站，理论上都可以实现用户几乎无感知的数据迁移和系统切换，但两者在实施成本、方案复杂度以及资源投入上，显然不在同一量级。
从分类来看，数据上云迁移主要包括两部分：结构化数据迁移上云，以及非结构化数据迁移上云。
先看非结构化数据。这类数据迁移到云端，通常可以借助数据同步工具，例如rsync来完成。如果访问非结构化数据的业务代码能够配合做适当调整，还可以进一步使用OSS对象存储来承载这类数据。这样做的优势非常明显：一方面，存储容量几乎可以无限扩展；另一方面，数据可靠性最高可达到99.9999999999%。同时，数据迁移到OSS本身也有成熟工具支持，可实现在线数据迁移。
再看结构化数据迁移。这里有一个非常实用的工具，叫DTS，它基本能够完成绝大多数主流数据库之间的同构迁移，同时也支持部分不同数据库之间的异构迁移。更重要的是，DTS支持在线数据迁移，这意味着在整个数据库迁移过程中，生产数据库通常无需停机。
不过，在结构化数据迁移上云过程中，还有一个绕不开的话题，那就是Oracle数据库在云端到底应该如何部署。围绕这个问题，业内通常分为两个流派：
无论是剑宗还是气宗，企业迁移上云，本质上仍然是围绕两个问题展开，也对应着两种典型思路。
