Rainbond v5.14.2 版本，又称 信创 版本。从这个版本开始，开源用户也能够利用 Rainbond 治理合乎信创要求的硬件计算资源。在这个版本中，产品团队将此前只在企业版产品中存在的信创相干性能拆分进去，融入到了开源产品路线之中。本文围绕 如何在信创环境中将利用迁徙上云 这一主题，联合 Rainbond 信创版本的能力，给出可行的落地计划。
向信创环境迁徙利用的必要性
信创产业即信息技术利用翻新产业，是我国数字化转型的重要组成部分，也是要害基础设施的重要撑持。其外围在于通过行业利用拉动构建国产化信息技术软硬件底层架构体系和全周期生态体系，解决核心技术关键环节 卡脖子 的问题，为中国倒退奠定松软的数字根底。
对个别的软件供应商而言，在面向党政军企售卖软件时，合乎国产化信创要求曾经逐步成为无奈绕过的硬性规范。即便是曾经交付实现的软件，在前期的建设打算中，处于信创转型期间的党政军企也会提出向国产化信创环境中迁徙的硬性要求。需要的背地总是暗藏着商机，把握国产化信创背景下的利用迁徙能力，将软件产品转化为 信创利用 是当下所有 ToB/ToG 信创利用供应商必须把握的能力。Rainbond 信创版本在这样的场景中能够施展极大的作用。
信创硬件生态
信创利用必须运行在国产化硬件和操作系统之上。国产化硬件生态中最重要的是 CPU 芯片，CPU 芯片的架构间接影响信创利用是否能够在国产化硬件上运行。目前支流的国产化 CPU 厂商包含飞腾、华为、龙芯、海光、兆芯等，其指令集集中在 X86、Arm 以及自主性极高的 LoongArch (MIPS 指令集的后继者) 之中。而指令集的不同，间接影响到信创利用是否须要从新编译来进行适配。
不难看出，国产化 CPU 芯片的生态有这么几个特点：
LoongArch自主水平最强，然而其生态受限重大，短时间内无奈很好的面向市场推广。- 海光、兆芯手持生态最为枯萎的
X86指令集受权，然而自主化水平最弱。X86过于成熟稳固，前人大厦已成，很难在此基础上做出翻新。 - 华为、飞腾领有
Arm指令集受权，自主化水平适中，而且Arm生态正处于蓬勃发展中，能够和X86生态掰一掰手段。
市场的反馈十分感性，在以后国内的 CPU 芯片市场中，飞腾在党政畛域 PC 市占带领先，海光与鲲鹏占据运营商服务器次要份额。回到信创利用供应商的视角，如何打好 Arm 这张牌，将会是闯入国产化信创赛道的关键点 。Rainbond 信创版本通过 一云多芯 能力，不便的纳管包含 Arm 在内的多架构集群。
“一云多芯”统管 Arm & x86 集群
顾名思义，一云多芯的异构集群，指的是在同一个集群中的计算节点中，其 CPU 芯片架构不惟一。
个别状况下，CPU 芯片的架构都是基于 Intel 公司推出的 X86 指令集，作为后起之秀的 AMD 也推出齐全兼容 X86 的 amd64 指令集，二者能够视为等同。而在国产化信创场景中，很多国产 CPU 架构都是基于 Arm 指令集开发，常见的鲲鹏 920、飞腾芯片等都属于该架构类型。为了可能融入国产化信创 IT 生态，Rainbond 自信创版本开始，全面兼容了 Arm 架构。
国产化信创绝非久而久之之事，大量在传统 X86 架构下开发的利用都须要很长时间的调整甚至重构能力齐全在国产化芯片上运行，一云多芯 主打同时可能运行多种架构利用的能力，在国产化代替的过渡阶段中将施展重大作用。
Rainbond 信创版本能够在同个集群中对立治理和调度多种不同 CPU 架构计算节点，同时也能够借助多集群治理能力纳管多个单架构集群。超高的灵活性，能够让决策者自行决定异构计算资源的部署策略。
除 Arm 架构之外，Rainbond 信创版本也兼容支流国产化软硬件，全面反对信创场景，并且取得了国内各大 CPU 厂商、操作系统厂商的认证。一体化治理信创利用的开发、运维、交付全流程，极大升高国产化信创场景下的利用治理老本。
信创利用迁徙难点
对于信创利用供应商而言，从头开发一套信创利用并不是难事。我国信创生态曾经日趋残缺，无论是操作系统、开发工具还是数据库，都不存在空白区域，它们为全新信创利用的开发提供了全面的反对。真正的难点在于如何将曾经运行在传统服务器中的遗留业务零碎迁徙到国产化信创环境中去。从传统的 X86 逾越到 Arm 架构根本意味着业务零碎中所有服务组件的从新编译，甚至重构。在保障业务连续性的前提下，实现传统利用向信创利用的转化是咱们无奈回避的课题。
首先，让咱们依照服务的开发语言、运行形式做个分类：
解释型语言
以 Python、PHP、Shell 为代表的解释型语言，也称脚本语言，是齐全与 CPU 架构无关的。咱们只须要提供能在信创环境中可用的语言解释器，即可在不改变一行代码的前提下将这种服务运行起来。
字节码型的编译文件
这种类型以 Java 语言编译出的 Jar、War 包为代表。Jar、War 包是十分常见的软件交付物。因为其打包的是与 CPU 架构无关的字节码，最终运行由跨平台的 JVM 虚拟机负责，故而咱们只须要提供能在信创环境中可用的 JDK、JRE 工具，即可在不改变一行代码的前提下将这种服务运行起来。
编译型语言
这里的形容是不严格的，因为字节码型的编译文件也产自编译型语言。在这里，咱们特指的是以 C、C++、Golang 为代表的编译型语言，它们在编译时与 CPU 架构强相干，编译出的二进制产物只能在指定的 CPU 架构下运行。这一个性也意味着迁徙过程必须通过从新编译，才能够在信创环境中运行起来。
遗留业务零碎向国产化信创环境迁徙绝非易事，须要甲方与供应商的密切合作。然而因为遗留业务零碎的个性，导致供应商可能提供的反对是不一样的。反对力度的不同，间接影响迁徙的成果。
提供反对
当甲方决意对某个遗留业务零碎进行信创迁徙时，恰好供应商承诺的反对期限还没有到期，供应商能够对业务零碎的迁徙提供全面的反对时，问题会简略很多。即便是面对编译型语言，只有可能提供源代码进行从新编译，则能够实现信创迁徙，只是耗时费劲罢了。
不提供反对
当甲方决意对某个遗留业务零碎进行信创迁徙时，恰好供应商承诺的反对期限曾经到期，甚至曾经无奈分割到供应商时，事件就难办许多。甲方对遗留业务零碎的理解不会太深，只能找到软件交付物进行剖析，从新基于信创环境搭建编译、运行环境。然而对有些经年日久的业务零碎而言，很难找到当年的源代码，如果这个服务恰好是编译型语言编译出的二进制文件，根本意味着信创迁徙走入了绝路。此时，甲方不得不思考从新投标另一家供应商来重构这个零碎，新的代替零碎落地绝非久而久之之事，期间不能因为这一个服务妨碍国产化信创的整体落地过程。
Rainbond “ 信创 ” 版本的外围性能是反对传统利用在信创环境中的云迁徙。它严密关注用户所应用的不同语言类型，并自动化实现信创迁徙的工作。一旦所有组件胜利部署，通过内置的 ServiceMesh 微服务架构，能够实现跨架构的微服务编排，将服务组件连接起来造成残缺的业务零碎。
传统利用迁徙上云
Rainbond 信创版本主动屏蔽架构差别，以最低老本将利用迁徙到国产化信创环境之中。仅须要提供源代码，即可在指定架构环境中编译运行。开源利用商店提供不同架构的利用模板，上百种开源软件一键部署。信创利用供应商能够以最小的技术老本和工夫老本，即可将不同类型的服务从新编译，并部署到信创环境中去。
异构微服务编排能力
Rainbond 信创版本凭借 一云多芯 治理能力，能够在同个集群中对立调度治理不同 CPU 架构的计算节点。利用中的服务组件也能够依照要求部署到指定的架构中去。然而只有不同架构的微服务组件之间能够互相编排、互相通信，那么它们才可能成为一个有机的整体，造成残缺的业务零碎。同时也满足信创利用从传统的 X86 向 Arm 国产化迁徙的过渡期的特殊要求。
借助于 Service Mesh 亦或是 Kubernetes Service 的能力，Rainbond 天生反对跨架构微服务之间的编排与通信。应用办法与 Rainbond 始终以来的利落拽拼积木式的微服务编排办法无异。