曾几何时,无论是在服务器还是个人电脑,CPU芯片领域一直是 Intel 独占鳌头,旗下的 X86_64 架构被广泛采用。然而王权没有永恒,近年来 Arm64 架构异军突起,服务器端有华为鲲鹏920高性能芯片做代表,个人电脑端则以苹果M1芯片惊艳世人。Arm64 架构芯片用低功耗和高性能炫耀着其市场价值,国产化替代的洪流也在不断将 Arm64 推向军队、政府、国企的供应商们。抓住先机,迅速拥抱与适配国产化芯片,是这个时代软件交付的新话题。
从 X86_64
迈向 Arm64
并非易事,指令集的改变,影响半径极大。
最直接的影响,是原来在 X86_64
环境中可以正常运行的业务系统需要基于 Arm64
重新编译才可以运行。即使开发时使用的语言具备跨架构的能力,重新编译本身就是一种很繁复的工作,需要投入大量的人力成本和时间成本。
Arm64
的开发语言生态并不是那么健全,这无形中会增加了本不该开发人员关心的负担。很多语言本身的运行环境都需要重新编译,更不要提很多开源中间件的适配工作。
以上仅仅是开发人员关注的重点。
在软件交付领域,软件交付到客户环境中运行起来,仅仅是个开始。业务系统的管理、监控、迭代、容灾都是交付团队需要持续关注的点。多数交付团队在 X86_64
架构下,都已经有了自己的解决方案。那么容器、Kubernetes、DevOps这些先进的工具方法,在 Arm64
架构下如何复刻?
Rainbond 可以利用自身能力抹平芯片架构的差异,无论是开发人员,还是交付人员,都可以基于 Rainbond 找到拥抱 Arm64
的解决之道。Rainbond 通过不同层次的能力来解决从 X86_64
到 Arm64
的迁移问题。
既有能力:Rainbond 本身是一款适用于软件交付,或者应用运维管理的云原生应用管理平台。无论是快速交付部署,还是应用的管理、监控、迭代、容灾,既有的功能已经可以满足交付运维人员的日常需求。
容器化技术:Rainbond基于容器化技术实现,容器这种轻量级的虚拟化技术在 Arm64
领域已然大放异彩。自从容器支持多架构之后,绝大多数开源中间件都已经提供了基于不同架构的基础镜像,Arm64
自然是其中的标配。选择容器化技术,相当于选择了 Arm64
的生态支持。
自身兼容 Arm64
:Rainbond 很早就开始落子国产化架构适配,自身适配了包含 Arm64
在内的多种架构。
极简的开发环境部署: Rainbond 已经支持运行于各种个人平台的 Docker Desktop 环境中,开发者只需要借助一台具有 M1 芯片的 MacBook ,即可花十分钟搭建起自己的 Rainbond Arm64 开发环境,方便至极。
源码构建兼容 Arm64
:这是打通迁移到 Arm64
架构的最后一环。在 Rainbond 中,开发人员可以不改一行代码,直接利用源码构建自己的业务组件,即可将之部署运行于 Arm64
环境中。目前Rainbond源码构建已经支持了市面上多种主流语言,围绕语言自身的各种扩展依赖已经趋于完整。
Rainbond 云原生应用管理平台可以被部署在 Arm64
环境中。从 2020 年 1 月起,Rainbond 分别和华为、飞腾进行了适配测试。经过验证,Rainbond 在 Kunpeng 920 芯片以及 FT2000+/64 这两款 Arm64
芯片上均可以稳定运行, 达到生产可用的标准。
而对于个人开发领域,Rainbond 也在持续发力。目前,Rainbond 支持在各种个人 PC 平台下利用 Docker Desktop 运行。我们将 Rainbond 的所有组件集成进一个容器,这种方式可以使得个人开发者以最简化的方式,利用十分钟时间运行起个人的开发测试环境。而对于使用具有 M1 芯片的 MacBook 个人开发者而言,就已经相当于基于 Arm64
架构进行开发了。
在Mac上运行Rainbond,10分钟快速安装
在Windows上运行Rainbond,10分钟快速安装
Rainbond 具备的源码编译能力由来已久。该功能脱胎自 Heroku/buildpack 项目,并由 Rainbond 团队针对自身需求做了大量优化。借助其能力,使用者可以基于多种语言的源代码,跳过编写 Dockerfile 的过程,完成业务的容器化。源码编译是部署企业自行开发业务的最简单方式,仅需要提供源代码的仓库地址。
目前 Arm64
源码编译支持的语言及版本如下:
语言支持 | 版本支持 | 扩展支持 |
---|---|---|
Java: Maven/Jar/War/Gradle | openjdk 8 / 9 / 10 / 11 / 12 / 13 | pinpoint agent jmx-exporter |
Node.js | Node 4.9.1 / 5.12.0 / 6.14.4 / 7.10.1 / 8.9.3 / 8.12.0 / 9.11.2 / 10.13.0 / 11.1.0 | Yarn 1.9.4 |
Node.js 前端项目 (VUE React) |
Node 4.9.1 / 5.12.0 / 6.14.4 / 7.10.1 / 8.9.3 / 8.12.0 / 9.11.2 / 10.13.0 / 11.1.0 | Yarn 1.9.4 Nginx 1.18.0 |
Golang | Go 1.8 / 1.9 / 1.10 / 1.11 / 1.12 / 1.13 / 1.14 / 1.15 / 1.16 | |
Python | Python 2.7.9 / 2.7.17 / 3.4.9 / 3.5.7 / 3.6.6 / 3.6.10 | |
PHP | PHP 5.5.38 / 5.6.32~37 / 7.0.29 / 7.1.27 / 7.2.16 / 7.3.3 | apcu / ev / event / imgick memcached / mongodb oauth / phalcon pq / raphf / redis |
Html | Nginx 1.18.0 / Apache Httpd 2.2.19 |
在源码构建功能适配 Arm64
之后,使用者不需要自己对业务进行容器化,仅需要提供源码即可。这种体验,可以被称之为将业务零成本迁移至 Arm64
容器之中。极大的减轻了开发人员的技术负担,降低了迁移适配成本。而这一过程中,代码运行环境的处理、扩展依赖的处理都已经由 Rainbond Arm64 源码构建能力处理完成。
源码构建的原理并不复杂:
整个构建过程拥有实时推送的日志,对于开发人员而言,和在自己的开发环境中编译操作没有太多差别。而编译过程中,需要提供 Arm64
支持的包括:语言运行环境预编译包、扩展、Nginx/Httpd 等中间价都已经由官方完成适配,免去了开发人员的辛劳,少掉了不少头发。
新安装的 Rainbond 平台,在首次进行源码构建时,会拉取 builder 和 runner 镜像,这个过程会花费几分钟时间。已经在 Arm64
环境中安装过 Rainbond 的用户,可以执行以下命令,拉取最新的镜像,来获取 Arm64
源码编译能力。
以 MacBook M1 电脑上安装的 Rainbond 为例,进入 rainbond-allinone 容器中操作:
docker exec -ti rainbond-allinone bash
获取内置镜像仓库的登录密码,登录镜像仓库:
hubpassword=$(kubectl get rainbondcluster -o yaml -n rbd-system | grep password | awk '{print $2}')
docker login --username=admin --password=${hubpassword} goodrain.me
处理镜像:
images=(builder runner)
for image in ${images[@]}
do
docker pull registry.cn-hangzhou.aliyuncs.com/goodrain/${image}:v5.5.0-release
docker tag registry.cn-hangzhou.aliyuncs.com/goodrain/${image}:v5.5.0-release goodrain.me/${image}
docker push goodrain.me/${image}
done
Rainbond 提供了示例代码,可供源码构建测试之用。
开始构建后,会自动弹出实时推送的构建日志,供开发人员了解构建进度。
当前日志中依次提供以下信息:
接下来的输出,和标准的 Java-maven 构建输出无二,是下载 pom 及依赖的过程。在构建完成后,输出日志:
代码编译过程到此完成,接下来,runner 会利用编译打包后的 slug 文件继续构建镜像,并完成向内置镜像仓库的推送:
首次构建,会拉取 runner 镜像,这个行为只会进行一次。
至此,源代码就已经变成了可以运行的容器镜像,该镜像可以在 Arm64
环境中运行。
当开发者成功将自己的业务系统部署在 Rainbond Arm64 环境中后,Rainbond 已有的交付流程,就可以最大化的降低向 Arm64
环境交付的难度。通过将业务系统整体发布为应用模版,就得到了可以向最终生产环境交付的标准交付物。无论是导出为离线包,还是基于线上 RainStore 交付,都可以很方便的实现。后续的流程可以参考以往的文章或参考官方文档。
使用Rainbond实现离线环境软件交付