1.什么是应用迁移?
应用迁移是指将应用从一个计算环境迁移到另一个环境的过程。
应用迁移是指将软件应用从一个计算环境迁移到另一个环境的过程。 例如,可将应用从一个数据中心迁移到另一个数据中心,从本地服务器迁移到云提供商环境,或从公有云迁移到私有云环境。
由于应用通常设计为在特定网络架构中的特定操作系统上运行,或者是针对单一云平台开发的,因此将应用迁移到新环境可能会带来一系列挑战。 通常,从虚拟化的架构或基于服务的架构迁移应用比迁移在裸机硬件上运行的应用要简单一些。
确定总体应用迁移战略时,要考虑每个应用的依赖关系和技术需求,以及企业在安全、合规以及成本方面的限制因素。
即使在相同的技术环境中,不同的应用也可能采用不同的云迁移途径。 从云计算早期开始,开发人员就用以下术语表示这些应用迁移模式。
更换主机: 也称为直接迁移,这是一种常见的战略,是指企业将应用从本地服务器迁移到云中的虚拟机 ,而不做任何重大变更。 为应用更换主机的速度通常比其他迁移战略更快,并且可显著减少迁移成本。 缺点是应用未作修改,因此无法得益于云原生计算能力,在云端长期运行这些应用最终可能会产生更高的成本。
重构或重设架构: 重构是指对应用进行重大更改,使其可以在云环境中更有效地扩展或运行。 这可能包括对应用的主要部分重写代码,使其能够更有效地利用云原生功能,例如将单体式应用重新构造为一系列微服务,或对 SQL 数据存储进行现代化改造,使其成为 NoSQL。
更换平台: 介于直接迁移和重构之间的一种方法,更换应用的平台需要对应用进行重大更改,使其能够从云架构获得更多收益。 示例包括:升级应用以使用云原生管理数据库,更改应用所使用的操作系统或中间件,或者使应用实现容器化。
淘汰/取代: 在某些情况下,直接淘汰应用是最合理的做法。 这可能是因为其价值有限;环境中的其他地方已存在重复的功能;或者与迁移应用相比,由新产品(通常是软件即服务 (SaaS) 平台)取代它的性价比更高。
要制定最合适贵组织独特 IT 环境和业务需求的应用迁移战略,必须清楚了解组织中的应用组合、安全与合规要求的具体内容、当前使用的云资源以及本地存储、计算和网络基础架构的状况。
为成功进行云迁移,还需要了解关键的业务推动因素,确保战略与这些因素保持一致。 需要弄清楚为什么要迁移到云以及希望通过这种转变达到什么目的。
在下面的视频中,Andrea Crawford 详细介绍了云迁移:
What is Cloud Migration? (4:46)
利益相关方可能会担心应用迁移导致业务中断或产生意外成本。 最常见的风险包括:
- 不可预见的技术挑战:例如,应用可能有很多依赖关系,重构或更换平台可能远比最初预想的更复杂、更耗时。
- 意外成本:如果规划不当,企业可能会产生未列入预算的意外成本,例如,新的许可费用,或者为了让员工快速熟悉新工具而进行培训的成本。
- 意外宕机:对应用进行重大更改可能会导致冲突或问题,造成应用和所连接的系统或依赖系统意外宕机。
- 文化问题或变更管理困难:不同的组织使用应用的方式各不相同,这些差异可能会导致摩擦,从而减缓迁移项目的速度。
无论是更换主机、重构还是淘汰产品组合中的应用,都需要围绕相关风险和收益开展仔细而全面的评估,这样有助于降低与应用迁移相关的总体风险。 尤其是,一定要比较部门级成本与企业总成本,并评估将应用保留在本地所需的任何硬件的总体拥有成本 (TCO)。
过去几年,企业一直在想方设法将应用迁移到云端,因为他们希望获得云提供商所带来的灵活性、可扩展性或可预测的按使用量付费的成本结构。
而如今,他们还希望环境能够支持创新。 无论这是意味着使用高性能处理器以支持深度学习算法,还是部署容器化应用,帮助开发团队快速实施变更以改善客户的数字化体验,云技术始终支持企业尝试新生事物,检验新的奇思妙想,以及更快地进行试错和摸索。 在许多情况下,相较于可能被取代的虚拟机,容器化等云友好型技术能够为最终用户带来更出色的体验。
一般来说,应用迁移规划流程可以分为三个阶段。 在每一个阶段,必须权衡所有潜在方案的成本,包括选择将某些工作负载保留在本地,这一点至关重要。
应用确定与评估。 在这个初始发现阶段,首先要确保掌握产品组合中所有应用的完整目录。 然后,根据应用是否为业务关键型、是否具有战略价值以及将应用迁移到云端的目的,对应用进行分类。 必须尽可能了解每个应用在以下方面的价值:
- 对业务的影响
- 满足关键业务需求的能力
- 数据的及时性和重要性
- 规模、复杂性和易管理性
- 维护和开发成本
- 迁移到云可以增加的价值
然后,针对考虑要迁移的每个应用,进行云亲和力评估。 在这个过程中,可以确定哪些应用准备按原样迁移,哪些需要进行重大更改后才适合在云端使用。
还可以借助应用依赖关系发现工具,确定将特定工作负载迁出当前环境的可行性。
总体拥有成本 (TCO) 评估。 确定云迁移项目的总成本是一项复杂的工作。 需要比较将应用和基础架构保留在本地的“假设”方案和迁移到云端的相关方案。 这意味着需要计算任一方案中,保留在本地的硬件的采购、运营和维护成本以及软件许可成本。
需要比较任一方案中,云提供商月度账单的成本和迁移本身的成本,包括测试新基础架构和培训员工使用新软件的成本。 别忘了保留在本地的原有应用的维护成本。
总体风险和项目持续时间评估。 在迁移规划的最后阶段,须制定项目时间表,确定可能会遇到的任何风险或障碍。
一般来说,应用越老旧,迁移到云端的难度也就越大(因此,价值也可能越低)。 过时的软件存在许多方面的问题:维护成本高,停止补丁更新后会引发安全问题,以及在现代计算环境中性能较差。 在决定是否迁移原有应用之前,必须首先对其开展全面的评估。
当组织评估应用的迁移可行性和优先级时,须考虑以下问题。
复杂性:应用是在哪里开发的? 如果是在企业内部开发的,开发人员是否仍在贵公司工作?应用的文档是否持续可用?应用是什么时候开发的? 已经用了多久?组织中有多少其他应用或工作流程在某种程度上依赖该应用?
关键性:每天有多少用户依赖于该应用? 每周呢?在造成业务运营中断前能够承受多长的宕机时间?该应用用于生产、开发、测试还是全部这三种环境?该应用是由内部 IT 团队还是由外部供应商管理?是否有其他应用的运行/停机必须与该应用同步?
合规性:该应用必须遵守哪些法规要求?
可用性:该应用必须符合哪些正常运行率标准? 例如,它是否要达到服务级别协议 (SLA) 所规定的 99.99% 的正常运行率?
测试
为了确保应用迁移过程中没有数据或功能损失,必须在迁移期间进行测试,以验证所有数据都存在、数据完整性得以保持以及数据现在位于正确的存储位置。
同时,还必须在迁移完成后进行跟进测试,确定应用性能基准,并确保安全控制措施落实到位。
虚拟化是许多云迁移战略中的一个基本组成部分,因为虚拟机可以方便地在新的物理硬件环境中运行。 甚至还可以在物理主机之间迁移在虚拟机上运行的实时应用,而不会干扰最终用户的体验。 虚拟化计算环境的灵活性和多功能性极大地简化了应用迁移过程。
虚拟机管理器的类型和迁移操作
目前可用的多种复制和迁移解决方案使客户能够在裸机服务器、云中的虚拟服务器甚至虚拟机管理器之间迁移虚拟机。
- VMWare 应用迁移:可将在本地 VMware 实例上运行的虚拟机直接迁移到在私有云中运行的 VMWare VCenter Server,而不会中断运营、导致停机或要求重新配置应用。
- Red Hat 应用迁移:Red Hat 提供了应用迁移工具箱,这是一个可自定义而且可扩展的软件解决方案,用于分析 IT 环境以确定应用的相互依赖关系。 它提供仪表板样式的分析报告,重点指出可能会在迁移期间遇到问题的应用。
许多服务可用于帮助企业制定战略和计划,以及成功执行云迁移。
迁移蓝图:通过全面的蓝图服务,供应商可以帮助您厘清迁移战略和目标,收集有关应用和环境的信息,发现用户和业务的需求,并制定迁移的详细行动计划。
迁移部署: 如果您选择管理部署服务,那么供应商不仅可以帮助您制定迁移战略和计划,还会管理迁移过程本身,执行任何相关的测试和故障排除任务。 这通常是完整的服务,包括全面的端到端支持。
云管理服务:云管理服务通常包括对基于云的 IT 环境进行监控和维护。 云管理服务提供商将承担多项职责,包括管理云安全性,以及代表您从供应商那里采购即服务产品。 应用迁移服务可包含在成套的服务产品中,也可以按需添加。
应用现代化:应用现代化服务包含自定义的开发服务,通过修改原有应用,使之能够在容器或虚拟化环境中运行,为原有应用在云环境中的使用做好准备。
云迁移服务
IBM 云迁移服务可帮助企业处理云迁移,从而使您可以将精力放在其他方面的重要工作上。
云计算将 IT 基础架构转型为公用事业形式:借助云计算,可通过互联网"插入"计算资源和应用,而无需在本地进行安装和维护
2.软件国产化可选适配技术路线
一、总览
基于C86(海光)、ARM(鲲鹏)两大技术路线,通过下表从芯片、操作系统、数据库、中间件几个方面对主流非信创产品和信创产品做出介绍,并给出通用选型建议。
表1 技术选型总览表
分类 | 现用产品 | 国产替代产品 | 选型建议 | |
芯片 | Intel X86 | 海光鲲鹏飞腾龙芯 | 海光鲲鹏 | |
操作系统 | RedHatCentOSWindows | 商用产品银河麒麟V10统信UOS | 银河麒麟V10统信UOS | |
数据库 | OracleMySQLPostgreSQLSQLServerDB2 | 商用产品达梦瀚高PolarDB | 瀚高PolarDB-X PolarDB-O | |
中间件 | Web中间件 | TomcatWebLogicWebShere | 开源的产品即可 | 开源的产品即可 |
数据缓存服务 | Redis | 开源的产品即可 | 开源的产品即可 | |
负载均衡反向代理 | NginxCaddy | 开源的产品即可 | 开源的产品即可 | |
消息队列 | KafkaRabbitMQActiveMQ | 开源的产品即可 | 开源的产品即可 |
二、国产芯片选型推荐
当前信创云已明确后续将基于C86(海光)、ARM(鲲鹏)两大技术路线提供信创云服务,根据调研结果,信息系统现用开发语言主要包括.NET、C/C++、Go、Java、Lua、Node,当前主要运行在X86架构。对于.NET语言,如果依赖Windows系统生态,则改造难度大,建议使用非Windows体系的技术栈进行重构;对于C/C++语言开发的业务系统,从X86迁移到ARM改动相对较多,建议选择X86架构的海光CPU,减少改动;对于Go、Java、Lua、Node语言开发的业务系统,对CPU依赖较小,海光、鲲鹏均可选用。
表2 国产芯片适配选型推荐表
语言 | 改造难度 | 推荐建议 | 详细分析 |
.NET | 大 | 重构迁移(鲲鹏或海光) | 海光:CPU综合性能好;应用生态极好,上云适配、迁移基本无需改造,但属于x86阵营,自主可控程度有限。鲲鹏:拥有自主发展权,安全可控程度高,应用生态较好,性能好。 |
C/C++ | 较大 | 重构/适配迁移(鲲鹏或海光) | |
Go | 小 | 适配迁移(鲲鹏或海光) | |
Java | 小 | 适配迁移(鲲鹏或海光) | |
Lua | 小 | 适配迁移(鲲鹏或海光) | |
Node | 小 | 适配迁移(鲲鹏或海光) |
三、国产操作系统选型推荐
当前主流国产操作系统主要包括商用的银河麒麟、统信UOS,开源的龙蜥、OpenEuler。关于操作系统的选型,结合国家财政部已发布的《通用服务器政府采购需求标准(2023 版)》,商用操作系统满足采购需求标准的所有要求,其中最大的优势是产品已历经市场考验,应用生态较好,服务支持力度比较大,遇到问题可以找厂商协助解决,因此优选推荐基于国产商用操作系统进行适配迁移;其次,统信UOS操作系统在桌面端的使用更为广泛,信息系统多为服务端适配改造,建议优先选用银河麒麟(服务器版)。
表3 主流操作系统对比分析表
操作系统名称 | 厂商名称 | 详细分析 |
银河麒麟 | 麒麟软件 | 1、满足《通用服务器政府采购需求标准(2023 版)》所有要求,可更好支撑后续顺利通过信创符合性测评;2、名录内产品,认可度高,合规性高;3、有技术厂商做后台支持,方便后续运维;4、收费,使用成本高。 |
统信UOS | 统信软件 | |
欧拉 | 华为 | 1、有效降低使用成本;2、代码开源,可以自行封装使用;3、后续运维难度大,需要自行解决操作系统问题。 |
龙蜥 | 阿里 |
四、国产数据库选型推荐
根据调研结果,政务信息系统现用的非国产数据库包括Oracle、Mysql、SQLserver、MariaDB、PostgreSQL等,数据库选型原则,主要从技术和服务支持两个方面考虑。一是,从技术方面,目前国产关系型数据库产品较为丰富,共分为两大阵营,一类是以PolarDB、GuassDB为代表的新一代云原生关系型数据库,既拥有分布式设计的快速弹性能力,还具备高可用和高可靠保障,可高度兼容Oracle、Mysql等数据库引擎,更适合基于云服务模式的数据库平滑迁移;另一类是以瀚高、达梦为代表的国产关系型数据库,对Oracle、PostgreSQL等具备很好的兼容性以及成熟的迁移适配方案,部署方式更加灵活,可移植性高,数据冗余小,在使用和维护成本较低的前提下,又能高度的保证数据的完整性和一致性;二是,从支持力度方面考虑,应优先考虑运维力量强、服务保障水平高的厂商。
综合上述,政务信息系统采用的数据库及替换建议如表4所示。
表4 数据库替换建议表
数据库 | 是否需要替换 | 替代建议 | 详细分析 |
MariaDB | 是 | 瀚高等国产关系型数据库 | 瀚高:1.支持运维团队全国覆盖,7*24小时售后服务;2. 对Oracle、PostgreSQL等具备很好的兼容性以及成熟的迁移适配方案;3. 已通过安全可靠测评,完全满足《数据库政府采购需求标准(2023 年版)》各项要求。PolarDB:1. 高度兼容Oracle、Mysql等数据库引擎,可实现上述数据库的快速适配迁移;2. 基于市信创政务云平台能力,实现统一的云原生数据库支撑,降低迁移难度;3. 已通过安全可靠测评,完全满足《数据库政府采购需求标准(2023 年版)》各项要求。 |
MySQL | 是 | PolarDB-X | |
Oracle | 是 | PolarDB-O | |
PostgreSQL | 是 | 瀚高等国产关系型数据库 | |
SqlServer | 是 | 瀚高等国产关系型数据库 | |
DB2 | 是 | PolarDB-X |
五、国产中间件选型推荐
根据调研结果,政务信息系统现用的中间件系统,多为国外开源产品,且根据技术需要,涉及Web应用、反向代理及负载均衡、数据缓存、消息队列等多种类型。按照拟定的产品选型原则,目前仅有web中间件属于信创名录产品,建议优先选用;其他类型中间件均为国内各厂商自研闭源或开源产品,建议依据产品性能、服务支持能力等因素自主选择,并在履约验收阶段要求产品厂商提供产品测试报告及与其他关联国产基础软硬件的互认证证书,以证明其产品能在关联国产基础软硬件环境内正常工作。
根据对现用中间件系统统计分析,主要用到的中间件及推荐建议如下表所示:
表5 主要中间件替代建议推荐表
中间件 | 是否必须替换 | 替代建议 | 详细分析 |
Apache | 是 | InforSuite(中创)TongWeb(东方通) | 建议优先选用国内厂商自研闭源或开源产品 |
Nginx | 是 | InforSuiteLB(中创)Tengine(阿里开源) | |
Tomcat | 是 | InforSuite(中创)TongWeb(东方通) | |
Undertow | 是 | InforSuite(中创)TongWeb(东方通) | |
RabbitMQ | 是 | InforSuiteMQ(中创)RocketMQ(阿里开源) | |
Redis | 是 | InforSuiteRDS(中创)Tendis(腾讯开源) |
六、开发语言选型推荐
应用系统基础开发语言层面,分为跨平台解释型语言、跨平台编译型语言及Windows系技术栈应用,分析如下:
1、跨平台解释型语言应用
JAVA、Python、Perl、Ruby等跨平台应用适配难度相对低,需要安装Java虚拟机和各版本语言解释器,各语言虚拟机或解释器,其中大多已被国产化操作系统预置,所以跨平台应用或可直接运行于信创环境,或仅需修改少量代码即可运行。当应用有使用Windows底层库或IE插件时,需对此部分代码适配改造,对编译型语言so库也需移植编译。
2、跨平台编译型语言应用
C/C++等跨平台语言适配难度相对适中,如C/C++语言应用程序,其编译后得到可执行程序,可执行程序执行时依赖的指令是CPU架构相关的。因此须使用源代码,经重新编译后可运行于信创环境,或经修改少量代码后进行编译即可运行于信创环境。当应用有使用Windows底层库时,需对此部分代码适配改造。
3、Windows系技术栈应用
.Net框架、C#、http://VB.Net、ASP. Net、J#等适配迁移难度相对较高,其依赖于Windows的特定功能或API,无法运行于信创环境,需对应用进行重构方可运行。也可通过CrossOver、.Net core、Mono等尝试适配改造,但有稳定性、安全性、知识产权等方面的风险。