曾几何时,无论是在服务器还是个人电脑,CPU 芯片畛域始终是 Intel 独占鳌头,旗下的 X86_64 架构被宽泛采纳。然而王权没有永恒,近年来 Arm64 架构异军突起,服务器端有华为鲲鹏 920 高性能芯片做代表,个人电脑端则以苹果 M1 芯片惊艳世人。Arm64 架构芯片用低功耗和高性能炫耀着其市场价值,国产化代替的洪流也在一直将 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
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 分钟疾速装置
Arm64 中的源码编译
Rainbond 具备的源码编译能力由来已久。该性能脱胎自 Heroku/buildpack 我的项目,并由 Rainbond 团队针对本身需要做了大量优化。借助其能力,使用者能够基于多种语言的源代码,跳过编写 Dockerfile 的过程,实现业务的容器化。源码编译是部署企业自行开发业务的最简略形式,仅须要提供源代码的仓库地址。
目前 Arm64
源码编译反对的语言及版本如下:
语言反对 | 版本反对 | 扩大反对 |
---|---|---|
Java:Maven/Jar/War/Gradle | openjdk 8 / 9 / 10 / 11 / 12 / 13 | pinpoint agent<br/> 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 前端我的项目 <br/>(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 <br/>memcached / mongodb <br/>oauth / phalcon <br/> pq / raphf / redis |
Html | Nginx 1.18.0 / Apache Httpd 2.2.19 |
在源码构建性能适配 Arm64
之后,使用者不须要本人对业务进行容器化,仅须要提供源码即可。这种体验,能够被称之为将业务零老本迁徙至 Arm64
容器之中。极大的加重了开发人员的技术累赘,升高了迁徙适配老本。而这一过程中,代码运行环境的解决、扩大依赖的解决都曾经由 Rainbond Arm64 源码构建能力解决实现。
源码构建的原理并不简单:
- 基于 Builder 提供一个对立的构建环境,依据业务源代码的特色,抉择对应语言的 buildpack 脚本。
- 依据 buildpack 脚本的不同,以及用户在 Rainbond 控制台中指定的版本,会从第三方对象存储(Rainbond AliyunOSS)下载对应的语言运行环境预编译包(如 Openjdk)筹备根底编译环境。
- 执行预编译过程,依据用户在 Rainbond 控制台中定义的编译个性(如依赖仓库地址等)进行编译环境的配置。
- 依据用户在 Rainbond 控制台指定的编译命令,或各语言的默认值,开始进行编译工作。期间会依据语言特色执行特定的操作,比方执行勾子函数、下载指定的扩大(PHP 扩大)等。
- 将构建实现的产物对立打包,打包的格局,是 Heroku 格调的 Slug 包。
- 基于 Runner 作为根底镜像,联结 Slug 包打包成为业务容器镜像,运行时主动解压 Slug 包,依据用户指定的启动命令,实现最终的运行。
整个构建过程领有实时推送的日志,对于开发人员而言,和在本人的开发环境中编译操作没有太多差异。而编译过程中,须要提供 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 提供了示例代码,可供源码构建测试之用。
开始构建后,会自动弹出实时推送的构建日志,供开发人员理解构建进度。
以后日志中顺次提供以下信息:
- 代码仓库地址
- 代码最新提交信息
- 首次源码构建拉取 builder 镜像(该过程仅在首次构建中拉取)
- 辨认构建环境 CPU 架构,以后为 linux-arm64
- 辨认语言及构建形式,以后为 Java-maven
- 语言运行环境版本,以后会下载 Arm64 环境可用的 openjdk1.8
- 装置 Java 语言的能力扩大,包含 Pinpoint APM agent 和 jmx-exporter
- 装置 Maven 构建环境,以后版本 3.3.9
- 执行构建命令。
接下来的输入,和规范的 Java-maven 构建输入无二,是下载 pom 及依赖的过程。在构建实现后,输入日志:
代码编译过程到此实现,接下来,runner 会利用编译打包后的 slug 文件持续构建镜像,并实现向内置镜像仓库的推送:
首次构建,会拉取 runner 镜像,这个行为只会进行一次。
至此,源代码就曾经变成了能够运行的容器镜像,该镜像能够在 Arm64
环境中运行。
继续交付
当开发者胜利将本人的业务零碎部署在 Rainbond Arm64 环境中后,Rainbond 已有的交付流程,就能够最大化的升高向 Arm64
环境交付的难度。通过将业务零碎整体公布为利用模版,就失去了能够向最终生产环境交付的规范交付物。无论是导出为离线包,还是基于线上 RainStore 交付,都能够很不便的实现。后续的流程能够参考以往的文章或参考官网文档。
应用 Rainbond 实现离线环境软件交付