拥抱 Arm64 的难处​

从 X86_64 迈向 Arm64 并非易事，指令集的改变，影响半径极大。

最直接的影响，是原来在 X86_64 环境中可以正常运行的业务系统需要基于 Arm64 重新编译才可以运行。即使开发时使用的语言具备跨架构的能力，重新编译本身就是一种很繁复的工作，需要投入大量的人力成本和时间成本。

Arm64 的开发语言生态并不是那么健全，这无形中会增加了本不该开发人员关心的负担。很多语言本身的运行环境都需要重新编译，更不要提很多开源中间件的适配工作。

以上仅仅是开发人员关注的重点。

在软件交付领域，软件交付到客户环境中运行起来，仅仅是个开始。业务系统的管理、监控、迭代、容灾都是交付团队需要持续关注的点。多数交付团队在 X86_64 架构下，都已经有了自己的解决方案。那么容器、Kubernetes、DevOps 这些先进的工具方法，在 Arm64 架构下如何复刻？

解决之道​

Rainbond 可以利用自身能力抹平芯片架构的差异，无论是开发人员，还是交付人员，都可以基于 Rainbond 找到拥抱 Arm64 的解决之道。Rainbond 通过不同层次的能力来解决从 X86_64 到 Arm64 的迁移问题。

• 既有能力：Rainbond 是一款不用懂 Kubernetes 的开源容器平台。无论是快速交付部署，还是应用的管理、监控、迭代、容灾，既有的功能已经可以满足交付运维人员的日常需求。

• 容器化技术：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 分钟快速安装

Arm64 中的源码编译​

Rainbond 具备的源码编译能力由来已久。该功能脱胎自 Heroku/buildpack 项目，并由 Rainbond 团队针对自身需求做了大量优化。借助其能力，使用者可以基于多种语言的源代码，跳过编写 Dockerfile 的过程，完成业务的容器化。源码编译是部署企业自行开发业务的最简单方式，仅需要提供源代码的仓库地址。

目前 Arm64 源码编译支持的语言及版本如下：

在源码构建功能适配 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 实现离线环境软件交付

离线交付的痛点​

在传统行业，如政府、能源、军工、公安、工业、交通等行业，为了防止数据泄露和运行安全考虑，一般情况下网络会采取内外网隔离的策略，以防范不必要的风险，毕竟在安全防护方面，网络物理隔离是网络安全防御最有效的手段，而网络隔离在软件交付过程中，对于外部软件开发厂商来说将会带来一系列的交付难题，也增加大量成本投入。例如：

1. 现场安装部署和验收测试，效率低下

交付过程中需要将应用程序及依赖的所有资源安装到离线客户环境，而客户环境有可能是物理服务器、虚拟机、私有云及 K8s 容器等各种环境，加上离线环境网络的限制，就会导致离线环境安装和部署效率低下。由于安装配置过程繁复，容易出错，在最终交付环境中需要重新进行验证测试工作，也需要浪费很多时间。如果部署的是微服务架构的应用系统复杂性更高，工作量还会加倍。

2. 离线环境定制开发和产品升级，成本高

定制开发需要开发人员投入，成本本来就高，在离线环境需要根据客户反馈持续迭代，迭代过程产品不断升级，每升级一次就要走一次安装部署和验证测试过程，成本很高。如果有些工作必须驻场开发，成本更高。

3. 网络不通，无法远程运维

交付完成后，应用需要持续运维，保障运行稳定性和功能持续可用，在网络无法联通的情况下，出任何问题都需要安排人员现场支持，甚至需要安排人员长期驻场。

技术选型​

上述问题的根本原因是因为，应用系统的多环境适配、应用安装部署、应用升级、应用运维等操作自动化程度不高，需要大量人员手工操作，所以效率很低，解决问题的重点在解决应用管理的自动化。当前，云原生技术已经越来越成熟，而云原生技术主要解决的就是应用管理的自动化问题，具体有两种开源实现方案 ：

1. Rancher+Helm

Rancher 是一款 K8s 管理工具，他提供 K8s 的管理 UI，包管理使用 Helm。对应离线交付的问题，Rancher 可以安装在多种运行环境（物理服务器、虚拟机、私有云），并且提供部分应用自动化运维功能，它可以解决 多环境适配和 应用运维问题，而 应用安装部署和 应用升级问题可以通过 Helm 包解决。

2. Rainbond+应用模版

Rainbond 是一款不用懂 Kubernetes 的开源容器平台。应用模版是 Rainbond 对应用打包的方案，Rainbond 提供应用的全生命周期管理（应用开发、应用编排、应用交付和应用运维）。Rainbond 可以部署到各种运行环境上（物理服务器、虚拟机、私有云），还可以部署到已有 K8s 集群和 Ranchar 上，解决客户多环境适配问题；Rainbond 提供应用运维面板解决应用运维问题，使用比较简单，不需要懂容器概念；Rainbond 的应用模版是一个亮点，只要在 Rainbond 上运行起来的应用就可以一键发布成应用模版，简化了应用模版的制作，而且应用模版可以导出离线包，特别适合离线环境的 应用安装部署和 应用升级。

下面分别比较一下两个方案

Rainbond 相比 Rancher 最大的优点就是易用性，不需要学习 K8s 和容器相关技术和概念，另外，Rainbond 提供的一体化开发环境和模块编排功能，能大幅度提高定制开发的效率。Rancher 最大的优点是完全兼容 K8s 体系，如果了解 K8s 能很快上手。

Helm 和应用模版比较

Rainbond 的应用模版 跟 OAM 的设计思路完全一致，“以应用为中心”的设计理念，屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智负担的、标准化的、一致的应用管理与交付体验。

综合对比，在离线交付场景 Rainbond+应用模版的方案优势明显，下面我们结合实际例子，来讲解 Rainbond+应用模版交付离线客户的整个过程。

使用 Rainbond 应用模版进行离线环境的应用交付​

基于 Rainbond 进行离线环境的应用交付，只需将开发环境已开发好的业务发布至应用市场，基于应用市场导出应用模板的离线包，在交付环境中进行导入操作，导入后基于应用市场一键安装即可自动运行。

预先准备环境​

• 拥有两套 Rainbond 集群，模拟开发环境及交付环境(开发环境为在线环境，交付环境为离线环境)。

• 开发环境安装，参考 在线安装文档；

• 交付环境安装，参考 离线安装文档；

• 拥有 U 盘、光盘等离线环境下应用模板离线包传输介质。

1.业务部署

整个流程始于开发环境，我们首先需要将业务搬迁至 Rainbond 之上。在开发环境基于部署自己的业务，可以支持源代码或是镜像。当前以 Spring Cloud 微服务框架 Pig 为例，部署参考SpringCloud Pig 在 Rainbond 部署及应用制作。

2.应用发布

将开发测试环境已开发完成的应用发布至内部组件库：点击应用左侧导航栏 发布 按钮，选择 发布到组件库 ，该过程需要 新建应用模板，应用模板定义了以下信息:

创建应用模板后定义应用发布版本：

发布组件模型配置：

发布插件模型信息：

要发布的应用中其组件携带有插件时，会进行展示并在发布过程中跟随组件发布。

所有信息配置完毕后，点击发布按钮进行发布，业务开发过程中定义的组件间依赖关系、环境配置、持久化存储、插件、运行环境及上述定义的所有信息都将会被打包发布。

3.应用导出

将应用模板进行本地化导出，在首页应用市场中找到已发布的应用，点击最后方扩展按钮，选择导出应用模板，选择应用版本后点击应用模板规范下的导出按钮，导出过程完全自动化，待导出完成后点击下载按钮即可将应用模板下载至本地，保存至 U 盘等移动存储设备中，带到离线交付环境中去。

接下来进入离线交付流程，交付人员携带着装有离线包的 U 盘等移动存储设备，开始导入应用模版。

4.应用导入

使用已导出的应用模板在交付环境中导入，点击应用市场界面的离线导入按钮，选择本地的应用模板上传，上传完毕后选择导入范围： 企业或团队，企业为当前交付环境所有人可见，团队为指定团队下的人员可见；点击确认导入即进入自动化导入步骤。

5.一键部署

应用导入后点击安装按钮在当前交付环境即可一键部署该业务系统，该环境业务运行环境与开发环境完全一致，到此完成离线环境下的软件交付。

6.增量升级

软件在更新迭代过程中需要进行某些模块的升级，进行此类升级时即可使用增量升级来节省发布及导入导出时间。

要达成增量升级的效果，需要重新进行应用发布操作，选择之前已创建的应用模板，修改版本号，如之前版本设置为 2.9，则此次发布设置为 3.0。

在应用发布步骤选择需要进行升级的组件进行发布，而不需要选择所有组件。发布完成后，导出新版本的应用模版离线包，在交付环境中再次导入。

交付环境导入后，平台会对应用模板不同版本进行对比，并通过应用拓扑图中的待升级选项提示用户进行升级。展示版本间属性变更情况，用户选择需要升级的版本进行升级即可，平台将自动执行升级操作，变更组件构建版本。

升级过程中不会变动环境配置类信息，这类信息需要人为改动才会生效：

• 环境变量的值

• 配置文件的内容

• 持久化存储

7.一键回滚

在升级版本上线后出现异常情况需要回滚时，平台提供了一键回滚功能，在升级记录界面选择对应记录点击回滚按钮即可对升级操作进行回滚。

在回滚的过程中，新增组件并不会被删除，如需变更，需要人为操作。

8.应用运维功能

软件产品交付完成以后需要进行长期的运维，在运维层面，交付人员需要考虑服务的可用性、可伸缩性、资源监控，Rainbond 提供了诸多运维功能，例如：

• 服务性能分析

通过 Rainbond 插件机制扩展性能分析功能，服务实时性能分析插件运行在目标分析服务同一个网络空间内，监控网卡的流量来统计分析服务的工作性能，对服务本身的工作流程和性能无影响，收集服务的平均响应时间，吞吐率等主要指标。

• 资源监控报警

  基于 Prometheus 对平台及业务进行监控，基于 ETCD 动态发现 需要监控的 targets，自动配置与管理 Prometheus 服务。

• 实例伸缩

  对服务组件进行垂直伸缩或水平伸缩，在流量高峰期灵活进行扩容。

• 网关管理

  应用网关支持灰度发布和 A/B 测试功能。

场景拓展​

上面的例子主要针对常见的离线软件交付场景，但在真实的离线交付场景中，还可能存在以下场景，如：

• 离线模块定制，每个客户交付的模块不一定，根据需要在客户现场开启或关闭模块，或者模块编排。

• 离线定制开发，在离线场景下进行完整的软件开发过程，包括源码管理、源码编译、开发测试环境管理、团队协作、版本发布流程等。

总结​

本文我们分析了离线交付场景的问题，对比了可能的技术方案，并使用一个例子完整讲解离线交付全过程，整个过程自动化程度很高。使用 Rainbond 进行离线交付肯定可以提高效率，但到底在哪些方面提高我们的效率，我再总结一下：

• 离线环境应用系统一键导出和导入 交付过程中只需要携带基于 Rainbond 导出的应用模板离线包在交付环境进行导入，即可一键安装整套业务系统。

• 开发环境和离线环境完全一致 Rainbond 屏蔽了底层环境的差异，基于应用模板进行交付，模板对应用的运行环境、依赖关系进行打包，开发环境和离线环境完全一致，不需要进行重复性测试。

• 一体化客户定制环境 软件交付过程中，不同的客户会有不同的定制需求，也就意味着需要为不同客户开发不同的模块，这些定制的模块在不同项目中都不尽相同，通过 Rainbond 提供的应用编排，就可以针对不同客户编排和开启不同功能模块；如果需要定制开发，就可基于交付环境已部署的 Rainbond 直接进行离线代码开发工作，包括源码编译、配置组件运行环境等，在交付环境中完成所有定制工作。

• 离线环境客户持续交付 对于项目实施团队而言，在实施过程中需要不断将 新功能、缺陷修复 等快速落实到交付环境或用户手中，传统的持续交付过程中，离线环境下需要交付人员驻场，手动执行更新上线操作，该过程不仅增加了交付时间，且长期的手动执行操作会增加部署的风险；而 Rainbond 的持续交付能力，能够实现应用后续的增量导入、导出和版本升级，能够带来以下优势:

  • 通过自动化方式实现，有效缩短代码提交到部署上线的时间。

  • 软件在整个生命周期内都处于可部署升级的状态。

  • 简化升级步骤，使软件版本更加清晰。

  • 让交付过程成为可预期的、可视化的过程。

• 离线环境下自动化运维

  服务高可用，自容错和自恢复机制，减少人工运维，提高业务系统稳定性。

当前业务模块化和解耦的问题​

• 架构耦合度还是太高，解耦的不彻底 。比如通过微服务架构拆解的微服务，受开发语言和微服务框架限制，跨开发语言不能调用，跨框架也无法使用，还受限于部署环境，换个环境需要重新解决部署问题。
• 从开发者角度定义模块，而不是从使用者角度定义模块，导致使用体验不好 。现在我们定义的模块通常都是开发定义的，由于开发离实际使用场景比较远，主观的认为模块拆的细和小，不管有什么场景需求我的模块都能复用和满足，但从使用者角度，模块拆分的越小越细，学习和使用的成本就越高，甚至根本使用不起来，很多模块化是过度的拆解和过度的设计。
• 模块化发布复杂，维护和升级成本高 。现在的模块化本身是一个开发过程，定义和打包过程都需要开发参与，导致成本高。

基于 Rainbond 应用模型的解耦和实现思路​

Rainbond 是一款不用懂 Kubernetes 的开源容器平台。它可以管理应用全生命周期。下面我们详细讲解一下 Rainbond 如何解决上述问题。

Rainbond 的核心抽象和定义了一套应用模型，通过应用模型从架构上解决解耦问题，应用模型将应用、运维特性和底层基础设施彻底解耦，应用又由多个业务组件拼装而成，每个业务组件可以是不同开发语言和不同构建方式，只要符合业务契约就可以拼装。通过以上解耦方式，彻底将业务组件、运维能力和部署环境解耦，业务组件只需要专注纯业务，不再关心由于使用场景差异需要匹配不同开发框架、服务治理功能、运维工具和部署环境，业务组件、运维能力和部署环境实现根据使用场景自由组合和拼装。

基于业务组件的拼装场景：

• 从业务功能开发上，业务组件提供的是基于业务协议的服务，不受框架和开发语言限制，可以供其他业务场景复用；
• 从运维管理上，在开发测试环境不需要开启运维的特性，在生产环境对业务的治理、监控、性能、稳定性和安全性有更高的要求，按需开启通过插件机制实现的运维特性；
• 从部署环境上，应用模型底层实现对接标准 k8s API，所有符合 k8s 标准 API 的基础设施都可以实现对接和部署，也就实现了业务组件不需要改动就可以部署到公有云、私有云和边缘设备上。

解耦不仅能提高各种场景的灵活性，还能让业务组件、运维插件和基础设施复用率大幅度提高，当积累的可复用的能力越多，我们面对不同场景、不同用户和不同市场的响应能力也越强。

Rainbond 应用模型遵循“以应用为中心”的设计理念，将应用无关的底层复杂技术封装，简化理解和使用体验。应用模型可以以应用模版的形式展现和存储，以上可复用的能力通过应用模版发布到应用市场，供其他人使用，从而实现模块复用。通常我们实现模块化主要考虑开发者，而应用模版更多考虑使用者，从使用者角度抽象定义，让使用者能用起来，从而拉动应用模版的生产。从使用体验上，应用模版可以一键安装和一键升级，通过“拖拉拽”的方式实现业务拼装。应用模版有很强灵活性，应用模版支持不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还可以持续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。

应用模版具备可打包业务的能力，有四个特点：

1. 模块化，可以形成可复用的能力单元，按需拼装使用场景。
2. 自治，自给自足，可以独立安装、升级和管理，确保组合的灵活性。
3. 可编排，模版和模版可以拼装出新模版，具备无限拼装能力。
4. 可发现，通过内部服务和外部服务两种方式体现，可供业务和技术、开发者和其他应用访问。

应用模版的定义和实现内容：

• 应用基本的元数据
  • 名称
  • 时间戳
  • 版本号和别称
  • 资源占用情况
• 应用治理模式（ k8s service 模式、Service Mesh 内置和 Istio）
• 应用网关信息
  • 对外端口
  • 域名和证书
  • 发布策略
• 应用全局配置
• 一个或多个业务组件
  • 业务组件的依赖关系
  • 业务组件类型（源码、镜像、Helm 和第三方 API）
    • 组件的构建方式
    • 组件的存储方式
    • 组件的配置方式
    • 组件的运行方式
  • 业务组件的插件
  • 组件端口和协议
  • 组件环境变量

模块发布和拼装流程​

在 Rainbond 中应用模版是模块的表现形式，模块发布和拼装流程就是应用模版的发布和拼装过程。模块建设是一个长期过程，强调积累，更多是在实践过程中的沉淀，同时需要根据反馈来持续迭代。 这个过程分四步：

第一步： 模块以应用模版的形式一键发布，所见即所得​

发布业务组件首先需要从业务角度定义颗粒度和业务接口，然后将要发布的组件在 Rainbond 构建，Rainbond 支持各种构建源，构建的同时也在定义应用模版，只要构建成功，就可以一键发布成应用模版，也就意味着任何在使用平台的开发者都具备发布应用模版的能力，发布的门槛低有利于知识和经验的分享。

第二步： 通过应用市场存放不同颗粒度的模块​

应用模版支持不同颗粒度，针对不同使用场景包装不同颗粒度：

• 面向内部研发场景，主要积累技术模版，模版颗粒度相对较小，为了提高开发效率。
• 面向客户交付场景，主要积累业务模版，模版颗粒度较大，通过模版可以快速拼装客户解决方案，提高交付效率。
• 面向销售场景，主要积累可以销售的产品模版，颗粒度最大，能帮助销售快速演示、使用和整体交付。

第三步：通过应用模版实现模块化拼装​

从应用市场一键安装需要拼装的模块（应用模版），通过“拖拉拽”将多个模块拼装成需要场景，拼装后原模块发布新版本，在拼装好的场景里按需升级。新拼装好的场景发布成应用模版，可以是更大的模块支持更大场景的拼装，也通过应用模版实现后续客户交付流程。

第四步：在真实应用场景中，持续积累和迭代​

模块的建设过程，要避免过度设计和提前过度拆解，模块提早拆解或拆解的粒度太小，会导致模块开发和维护成本高，使用体验不好。所以，模块前期设计和开发只能占少部分，大部分模块在真实场景中才能看到它的价值，这时候再发布成可复用的模块，更加具备实用性。同时，模块的边界和功能在真实场景中才有意义，需要根据实际需求不断迭代。

使用场景​

可拼装的业务模块，提高开发效率和客户交付速度​

对于软件公司的研发和客户交付场景，通过可拼装的业务模块，在新项目研发和新客户交付过程中复用，减少重复性开发，能大幅度提高效率。

行业业务中台，实现行业能力积累和复用​

对于行业用户，实现数字化的过程，会建设很多套系统，这些系统有很多能力是通用的，把这些能力积累下来，后续建设过程直接复用，不仅减少了建设周期，复用成熟的能力还能提高系统成熟度。另外，需要业务融合和数据融场景，可以通过业务编排，实现系统之间的互联互通。

2B 软件公司的产品化包装和模块化销售​

对于 2B 软件公司，会面对项目个性化和产品标准化的矛盾，要解决这对矛盾有两个解决方案：一个是让个性化的项目也能快速沉淀出产品，这个过程通过发布应用模版能快速实现；另一个是将个性化的项目按模块化拆解，不同客户选择不同模块，实现根据客户需求个性化销售；这两个方案可以进一步融合，在早期，个性化项目是驱动力，项目的模版可以作为给其他客户演示和交付的产品基础，在不断的交付客户过程中，发现和拆解可复用的模块和个性化的模块，等交付客户越多，积累的可复用模块也就越多，也知道哪些模块有商业价值，模块化成为产品的基础，更好服务销售和交付，产品化也就越成熟。

多云痛点​

• 多云环境的统一监控和运维管理：：

  企业使用多云增加了统一运维管理的复杂性，对于单云架构，可使用云服务商提供的管理工具，但对于多云架构，如何使用统一平台进行运维管理，进而提升 IT 服务交付效率、增加资源利用率，降低运维成本，成为值得关注的问题。

• 多云环境下的应用管理：

  单机环境下，应用的部署、管理相对简单，对于多云的分布式环境，应用的部署、运维、标准化管理成为难点，同时，传统的应用、基于微服务架构的应用、以及近来发展迅猛的 Serverless 应用，不同类型的应用也为一站式应用管理增加了难度。

• 多云环境中核心业务迁移和部署：

  使用多云后，无法避免数据的跨云迁移，在异构的云、数据中心之间进行数据迁移，如何保证数据的一致性及低时延，又成为了新的挑战。

使用 Rainbond 管理多云应用​

企业除了资源管理之外，其实应用程序管理是更贴近于企业的需求，应用有多种类型，包括传统的应用，像 Mysql、Tomcat、Nginx，还有基于微服务架构的应用、以及 Serverless 应用等。

企业需要一个可以管理各类计算资源和各类应用程序的一站式管理平台 ——— Rainbond 应运而生。

Rainbond 是一款不用懂 Kubernetes 的开源容器平台。它提供多云和混合云场景下的应用管理能力，支持跨云的多集群统一管理，以及应用在多云环境下的统一部署和管理。基于 Rainbond 上开发的任何运行的应用，都能够交付给任何基于 Rainbond 的应用管理平台上去使用，也就是基于 Rainbond 可以将任何应用以任何规模部署到任何云上面，对开发者来说就是 只需构建一次，即可随时随地运行。

Rainbond 与 CMP 对比​

上图中简述的绘画了 Rainbond 与传统 CMP 的对比，可以很直观看出 Rainbond 关注的是应用层面，CMP 关注的是底层计算资源。

CMP 是基于“资源”的多云管理，可以实现多云下所有资源的统一管理。例如：在 CMP 中可开通某云厂商的虚拟机，包括订单的管理等。但 CMP 对于应用的管理就相对来说弱一些，无法将多个云上的应用进行统一运维、管理。

Rainbond 是“应用级”的多云管理，通过统一的应用模型，应用可以透明在多云上运行和迁移。例如：应用在物理服务器上开发和测试，不用任何改动就可以部署到各类公有云或客户的私有云上。

多云应用管理的四个典型场景​

在 Rainbond 中实现多云目前有以下四个典型场景：

• 开发和生产环境分离：

  在 CI/CD 的场景中，一些用户出于安全的考虑，希望开发环境和测试环境部署在本地的私有云集群，生产环境部署在公有云上。通过 Rainbond 可以将开发环境、测试环境和生产环境的集群统一管理，配合容器开发流水线，完成业务上线流水化作业，提高企业代码交付和部署的效率。

• 多云应用统一管理：

  通过 Rainbond 对接和管理多云，统一管理多云下的所有应用，通过拓扑图查看业务的状态，管理应用的全生命周期，提高应用运维的效率。

• 通过应用市场实现多云应用交付：

  在行业云或 ISV 场景中，应用需要交付到各种客户场景，Rainbond 的应用市场，可以将应用以模版的形式存放到应用市场，根据需要一键交付到客户环境，根据需要还能按需升级。

• 多云应用备份和迁移：

  通过 Rainbond 实现应用从一个云备份和迁移到其他云。

具体实现​

1、通过 Rainbond 对接多云

首先需拥有可用的 Rainbond 。

完成 Rainbond 控制台的安装后，进入 Rainbond 控制台 企业视图 >> 集群 >> 添加集群，在公有云或私有云的服务器上安装 Rainbond 集群端 ，可添加并对接多个集群。

多集群对接后效果图👇

2、多云应用统一管理

当 Rainbond 对接多集群后，在 Rainbond 上可以创建和管理多团队，并为每个团队在多集群中分配资源，在团队空间中就可以管理应用全生命周期。

3、开发环境和生产环境分离

A 云上做测试/开发，B 云上进行生产 是最常见的环境分离。一般是在云上做测试/开发，在本地进行生产。但有时候可能颠倒过来，因为你可能需要云的多区域能力或者像 CDN 这种高级功能来为生产环境加速。

**例如：**在私有云环境中，部署开发环境，快速复制出测试、生产环境。快速复制支持跨团队、跨集群。

4、通过应用市场实现多云应用交付：

用户可将已部署的业务通过 Rainbond 应用发布 功能一键发布到内部应用商店，可通过应用模板对应用进行版本管理以及应用详情介绍。也可通过应用模板可在多云环境中一键部署。

通过 Rainbond 一键安装 Gitlab​

Rainbond 作为应用运行环境，Gitlab 可以运行在 Rainbond 之上，为了便于 Gitlab 安装，我们制作了 Gitlab 安装包放到了 Rainbond 的应用市场，实现 Gitlab 的一键安装。

1. 安装 Rainbond，安装步骤。

2. 从应用市场搜索“Gitlab”，点击安装，一键完成 Gitlab 所有安装和配置工作，包括数据安装和初始化。

3. 安装完成，通过 Rainbond 管理和运维 Gitlab。

   

Rainbond 源码构建对接 Gitlab Oauth，实现一键代码部署​

使用过Rainbond的小伙伴一定知道，在Rainbond上创建组件有三种方式：源代码创建、镜像创建、应用市场创建。

源码构建方式通过配置源码地址实现代码构建，Gitlab 虽然可以提供源码地址，但构建新应用需要拷贝源码地址及设置用户名密码，这个过程很麻烦，也容易犯错。

为了与 GitLab 配合有更好的体验，Rainbond 做了产品化的支持，通过 OAuth2.0 协议与 GitLab 进行对接。

配置 GitLab Applications

进入 User Settings → Applications

创建后请保存 Application ID 和 Secret，后面会用到。

使用私有化部署 Rainbond 时，需配置 GItLab 允许向本地网络发送 Webhook 请求

进入 Admin area → settings → NetWork → Outbound requests

勾选 Allow requests to the local network from hooks and services 选项即可

配置 Rainbond OAuth

进入 Rainbond 首页企业视图 → 设置 → Oauth 第三方服务集成 → 开启并查看配置 → 添加

Rainbond OAuth 认证

进入 Rainbond 首页企业视图 → 个人中心 → OAuth 账户绑定 → 对应账号 → 去认证

对接后效果

接下来展示 Rainbond 与 Gitlab 对接后平台的效果图。

当我们对接成功后，进入基于源码构建的页面会展示下图中的效果，展示所有的仓库列表。

通过 Rainbond OAuth2 与 GitLab 进行对接后，在 Rainbond 平台登录不同的账号时，需进入个人中心认证，认证后 Rainbond 会根据账号不同的权限展示不同的代码仓库。

Rainbond 对接 Gitlab WebHook，自动触发构建​

当我们完成整合 Rainbond 和 Gitlab Oauth ，选择指定仓库，点击创建组件，可选择代码版本（自动获取代码分支以及 tag）和 开启自动构建。

创建完成后在组件中配置 WebHook 自动构建，提交代码，Commit 信息包含“@deploy”关键字，就可以触发 WebHook 自动构建。

Commit 信息关键字触发 GitLab WebHook 原生是不支持的，在这之前有社区用户提出在提交代码触发构建时，每一次提交都会触发构建，用户并不想这样做，所以 Rainbond 研发团队研发了根据提交的 Commit 信息包含关键字去触发自动构建。

下图中展示了用户从创建组件到持续开发的整个流程。

总结​

一体化开发环境的能力：

• 代码管理：代码相关的所有管理功能，提供 web 界面的管理（Gitlab）
• wiki ：在线编辑文档，提供版本管理功能（Gitlab）
• 问题管理：Issue 管理（Gitlab）
• 持续集成：代码自动编译和构建（Rainbond）
• 环境管理：快速搭建开发或测试环境，保证开发、测试、生产环境一致性（Rainbond）
• 架构编排：无侵入的 Service Mesh 架构编排（Rainbond）
• 模块复用：通过组件库 实现公司内部模块、应用、服务积累和复用，同时实现了软件资产管理（Rainbond）
• 持续交付：开发、测试、生产环境持续交付流程（Rainbond）
• 应用管理：应用监控和运维面板（Rainbond）
• 团队管理： 多团队管理，成员、角色管理（Rainbond）

一体化开发环境的价值：

1. 开箱即用
2. 让开发团队专注在写业务代码，不要在环境上浪费时间。
3. 应用粒度抽象，使用简单，上手快。
4. 过程自动化，提高操作效率（持续集成、环境管理、持续交付等）。

个性化交付的难点​

对于企业产品交付，个性化程度越高，交付成本也就越高，交付的成本不仅有人力成本，还有时间成本，只有解决了个性化交付的效率问题，产品的利润率能大幅度提高，同时实现规模化交付。

个性化交付主要由交付环境的个性化和产品功能的个性化组成：

个性化环境面临的交付难题​

• 基础设施个性化，适配难度大 不同客户提供的基础设施资源多种多样。私有化场景下，不同的客户有自己独有的基础设施，比如不同的硬件，有的客户拥有自建机房，有的采购了阿里云、华为云等这样的公有云服务。操作系统也是各有不同，例如在企业内部常见的操作系统有 CentOS/Redhat/Ubuntu/Debian/麒麟OS 等等。对于CPU 架构来讲，有 x86 的服务器，也有 ARM 的服务器。不同的基础设施，软件都需要进行适配，提升了软件交付部门的工作量。

• 离线环境，交付效率极低 一些客户环境考虑到安全因素，不允许连接外网，导致软件交付后期维护难度极大。售后人员由于网络离线无法及时收取异常告警信息，需要用户收取到告警反馈给售后人员，可能由于技术的差异导致问题定位和修复过程不顺利。由于离线，一些预期内的变更或升级需要出差客户现场，支持的成本比较高。

• 由于交付环境变化，测试工作量大 由于交付环境个性化，不能保证功能都能正常工作，所以部署完成后，为了保障交付质量会有测试验证的流程，对于自动化测试无法覆盖还需要人工手动回归来保障交付的环境质量。交付产品越复杂，测试验证也就会越复杂。

个性化功能需求面临的交付难题​

• 缺少模块复用，定制开发后期维护困难 对于需要定制化开发的交付，通常基于现有代码直接修改，这种方式看起来复用了代码，但需要全量测试，而且每个客户一个分支，交付客户越多，管理会比较混乱，产品有新的版本需要花大力气给每个客户升级，在交付不同客户时开发的新功能，也不能快速积累到标准产品中。如果客户需要持续迭代，交付客户这个版本需要长期维护。

• 无法建立从开发环境到客户环境的持续交付流程 为了让产品满足客户的个性化使用效果，通常需要有一个持续迭代的过程，这个过程中，客户会经常反馈，修改完后也希望能快速看到效果，这对交付的敏捷性提出很高的挑战，如果无法达到客户时效性的要求，就需要驻场开发，驻场开发会耗费更多人力物力。

Rainbond的解决方案​

Rainbond 是一款不用懂 Kubernetes 的开源容器平台。它提供应用的全生命周期管理：应用开发、应用编排、应用交付、应用运维；用户在软件开发阶段利用 源码构建、应用复制、应用市场 功能搭建开发环境，快速构建一体化开发平台，业务系统的运维包括由平台进行管理（弹性伸缩、健康监测、异常预警），用户只需专注于业务代码，其他问题平台进行解决，有效解决开发过程中效率问题。

Rainbond从四个方面解决个性化交付的难题：

1、通过应用模版交付各种客户环境​

在软件交付过程中Rainbond将业务系统抽象为应用模板，企业产品只要在Rainbond能够正常运行，即可通过应用模板发布至应用市场，应用模板中包含服务运行态所需的全部资源，通过应用发布至应用市场或导出离线安装包的形式，在任何已连接该应用市场的Rainbond集群中均可一键安装，完成应用交付。

• 屏蔽客户环境差异，一套产品模版交付所有客户 Rainbond支持对接和管理各类公有云、私有云、物理服务器、边缘设备，企业产品的模版运行在Rainbond之上，所以交付客户将Rainbond 连同产品模版一同交付给客户，产品的模版是应用级包装和抽象，基于应用模板进行应用交付时，模板中包含了产品运行所需的全部资源，与底层操作系统隔离，只需关注自身业务，业务之外的技术问题：资源管理、运维、架构、治理、环境等，Rainbond平台一站式解决。

• 无需单独适配，支持国产化CPU 在国家提倡国产化和信创的大背景下，最终客户的运行环境也在逐步使用国产化CPU，国产化CPU种类多，比如飞腾、鲲鹏、龙芯、申威等，适配这些CPU需要独立编译和打包，要全部适配工作量很大，Rainbond支持国产化CPU平台的自动编译和打包。国产化CPU编译和打包参考文章：x86架构应用如何向Arm架构低成本迁移

• 离线环境自动化交付 在离线环境下基于应用模板进行交付，交付人员无需考虑众多的离线资源，只需将应用模板导入已安装的Rainbond平台，一键安装即可完成交付过程，规避了传统模式下需要导入大量的离线资源、下载更新文件以及交付遇到问题时寻求远程协助的不畅。离线交付可参考文章： 使用Rainbond实现离线环境软件交付。

• 保证环境一致性，避免重复测试 通过Rainbond的应用模版交付客户，应用模版包含企业产品运行环境的所有要素（软件包版本、环境变量、操作系统、配置文件、端口、依赖关系等等），这样能保证最终软件交付运行环境与开发测试环境的一致，减少了由于底层环境不同而需要的重复测试工作。

2、将产品功能模块化，按需交付和模块化拼装​

Rainbond的模块化可参考文章： 使用Rainbond打包业务模块，实现业务积木式拼装

• 根据客户需求，按模块选择性交付 一个完整的企业产品会包括很多功能，对于不同客户根据费用和场景选择的功能也会有差异，通过Rainbond可以将产品功能实现模块化，类似上图，每一个六边形块都是一个模块，整个产品的所有模块可以通过应用模版一键交付到客户环境，然后删掉不需要的功能模块，就完成了模块化交付。

• 以模块化业务拼装为基础，然后定制开发

当积累了可复用的模块化组件后，交付客户先以已经积累的模块化组件为基础，拼装基础架构，然后再开发需要定制的服务，新开发的服务有复用价值，又可以一键发布到应用市场，为后续交付助力。

3、面向功能定制的开箱即用开发环境​

Rainbond提供的开发环境整合代码仓库、Web IDE、制品库、源码编译、持续构建、开发测试环境管理、发布和回滚等功能，并提供多种适合2B定制化交付的功能。 Rainbond的开发环境可参考文章： Rainbond整合GitLab、 Rainbond集成Web IDE

• 定制化环境快速搭建 要定制化交付客户，需要基于标准化产品定制开发，而搭建定制开发环境需要新建代码分支、安装数据库服务、配置编译和构建流程等、建立测试环境等，如果交付的项目比较多，后期管理会更加复杂。Rainbond通过应用复制功能可以一键搭建针对某个客户的开发测试环境，每个客户环境可以配置不同的开发人员，并设定相应权限，交付完成后，依然保留定制交付过程中的所有历史何上下文环境，即便人员有变动，其他人可以快速接手。

• 复杂项目的一体化集成环境 对于复杂一些的项目，通常涉及业务集成和软件厂商的软件集成，以前通常的做法是，先各自完成自己的功能，再集成和联调，但由于业务边界、开发语言、运行环境等差异，集成过程会花费很长时间，甚至会把之前做的事情推倒重来。在敏捷开发里倡导尽早集成，Rainbond提供一体化集成环境，在项目开发就为集成做准备，每个厂商在Rainbond有各自的环境，不同厂商的接口通过Rainbond的提供微服务架构集成，Rainbond的微服务架构支持跨语言、跨协议服务编排，并通过拓扑图了解项目整体架构和依赖关系。

• 在客户现场的离线开发环境 通常情况下，使用Rainbond在公司内部环境进行开发，基于应用市场或离线包完成交付，后续产品更新或bug修复可完成持续升级，但涉密场景或用户数据隐私场景，客户要求在他们服务器上搭建环境开发，而且通常不能上网，也就是需要离线的开发测试环境， 此时开发人员需要准备大量离线资源，包括IDE工具、maven/npm依赖包，导致开发环境搭建异常麻烦，而Rainbond在离线环境能够提供全套的离线开发环境，即开即用，包括IDE工具、依赖包一站式解决，解决离线环境开发难的难题。

4、远程持续交付和运维​

客户交付是一个持续的过程，定制开发的过程需要持续迭代，新版本发布或bug修复需要给客户升级，功能交付完成需要保障运行稳定性，通过Rainbond可以实现在公司完成上述过程。

• 远程持续迭代和交付 通过Rainbond在公司开发测试产品，并发布到应用市场，应用市场管理产品的所有版本，包括各种定制化客户版本。针对客户环境是否可以上网，支持两种流程：

  1. 客户环境可以联网，客户通过分配的token连接到应用市场，并一键安装指定版本的产品和版本，如果发布新的版本，客户环境可以自动发现，客户可以自助升级。
  2. 客户环境不能联网，从应用市场导出离线软件包，发给客户，客户自助导入，并一键安装或升级。

• 远程客户环境运维 Rainbond提供应用自动化运维的能力，并可以通过Web界面监控和管理，对于可以联网的客户环境，远程就可以完成所有后期运维。Rainbond实现应用管理和运维参考：云原生应用管理和运维

总结​

对于2B的软件企业的个性化交付，Rainbond实现交付过程自动化，并最大限度少写代码，能大幅度减少人员投入，通过应用市场积累的模块化组件，还能提高企业面对市场的响应速度，随着业务逐渐模块化，Rainbond逐步成为2B软件企业全流程的PaaS平台，是扩展市场和提高企业竞争力的利器。

通过应用模型实现自动化交付​

企业应用指的是支持企业、事业单位或者政府等机构各项业务运作的软件系统。除了支持机构内部的协同工作之外，企业应用也支持企业与其供应商、业务伙伴和用户的协作与协调。

每一套企业应用的复杂程度不尽相同，但往往可以细分出相互协作的多个组件。以轻量级的系统举例，也要至少划分成业务系统与数据库两个部分。大型的系统则有可能包含数十个组件，若干组件也可以形成模块。这些组件或模块之间还需要定义一些配置，来实现彼此之间的关联依赖。如此复杂的场景，的确难为到了 ToB 软件厂商的实施交付人员。

企业应用在传统模式下的实施部署与升级，其难度、成本都与企业应用自身的复杂性成正比。这是由于在传统模式下，实施交付人员更多的通过人工的方式，手动部署服务组件、编辑配置文件。无法自动化处理的流程都具有低效与易错的通病，企业应用的组件数量和复杂性会将这些通病叠加起来。

云原生时代的企业应用交付都依靠各种容器化交付平台落地，通过发挥容器化、平台化的优势，解决了环境一致性、自动化运维、故障自愈等问题。而在简化应用交付与升级这一场景中，所选用平台的能力就十分重要。

Rainbond 是一款不用懂 Kubernetes 的开源容器平台。它兼具 Kubernetes 集群自动化管理能力，以及企业应用一键安装升级能力。Rainbond Application Model（RAM）是基于 Rainbond 提出的一种应用模型，通过将企业应用进行模型化的抽象，搭配 Rainbond 平台的应用市场机制，最终实现了一键安装/升级。高度自动化的交付体验，提升了企业应用交付效率，降低交付成本。

RAM 模型的抽象，囊括了企业应用所包含的所有服务组件以及组件间的关联关系。这一高级抽象无关乎企业应用内部包含多少服务组件，也无关乎组件间的关联关系是否复杂。应用模版（RAM模型在应用市场领域的具体实现）可以发布到 Rainbond 特有的应用市场中，发布出的应用模版可以作为企业应用的安装包看待，无论原有架构多么复杂、内部组件多寡，都可以完成一键安装与升级。

为了适应更广泛的交付领域，RAM 模型正在努力向 Open Application Model（OAM）演进。OAM 是业界新提出的一种应用模型，其设计是为了能够以简单的方式，在复杂环境中间交付更加健壮的企业应用。

使用Rainbond一键安装企业应用​

Rainbond的应用模版是应用模型的具体实现，是企业应用一键安装的载体。当制作好了应用模版，发布到应用市场，就可以通过应用模版一键安装，一键安装过程可以将企业应用从开发环境中完美复刻到交付环境中。组件的特性、镜像、插件、依赖关系都得以保持原样。

就实际操作而言，点击应用模版右侧的安装，选定团队、集群、应用、版本等必要信息后，确定即可开始安装目标企业应用。

Rainbond本身能支持各类客户环境，不管是服务器还是虚拟机，是联网还是离线，X86还是国产CPU都能支持， 只要客户环境能安装Rainbond，就可以通过应用模版一键安装。

制作一个可以一键安装的应用模版​

应用模版所承载的企业应用，借助一键安装能力已然可以快速的交付部署。然而交付完成的企业应用是否可以在安装完成后自动进入可用的状态，和应用模版的制作过程有很大的关系。接下来，我们来介绍下，一键安装即可用的应用模版，应该具备怎样的“自我修养”。

环境变量定义连接信息

可被访问的地址，是组件之间的相互关联调用的关键。通常情况下，可被访问的地址会以 IP:Port 或域名的形式体现。然而 IP 的变更，在交付场景中是必然出现的，这严重影响了一键安装即可用的能力。所以不要将连接地址写成固定值，而是将其设计成为可以通过环境变量的方式动态拾取并配置的形式。Rainbond 平台提供非常强大的连接信息注入功能，专门用于处理组件间的访问地址。

数据自动初始化

企业应用的持久化数据，应该与程序文件分离。所有需要持久化的数据，都应该具有独立的目录，这些目录在容器启动前，可以为空。如果有多个目录需要被持久化时，它们最好拥有相同的父级目录。所有的数据库中间件、业务持久化数据需要支持自动初始化。数据的初始化有多种方式可供选择，开发人员可以根据实际情况自行选择：

• 业务代码管理数据版本（推荐）

由开发人员在企业应用程序内部添加逻辑，完成对数据库表结构的初始化操作。这是一种非常通用的方法，企业应用在启动时自动检测可连接到的数据库中是否存在指定的表结构，如不存在则进行一次初始化。这种方式更被推崇的原因在于开发人员也可以借助这一方式完成数据库表结构的升级操作。参考 源码构建实现数据库表结构自由升级回滚 可以了解一种基于 Liquibase 结合 Rainbond 源码构建能力的数据库版本解决方案。

• 官方镜像提供的能力

对于市面上常见的各类数据库中间件而言，其官方镜像均具备数据自动初始化的能力。包括但不限于 Mysql、Mongo、Postgresql等常见数据库。

• 针对非结构化数据制作初始化插件

对于更一般化的场景，平台支持以插件机制来针对服务组件的指定持久化目录进行数据初始化，这种方式借助了外部的对象存储来保持需要被初始化的数据。

合理的解耦方案

为了实现一键安装企业应用的目标，需要划分出可以被解耦的不同模块，并且将模块以应用模版的方式发布出来。每一个模块对应的应用模版，都应该是可以被独立安装并运行的。交付实施人员根据最终客户的业务需求，按需一键部署出多个应用模块，并在图形化界面下进行拼装，即完成了企业应用的整体交付。对于企业应用开发人员来说，合理的解耦方案，可以达成模块化复用的效果，降低开发人员的重复工作量。

深入了解到如何合理划分模块：使用Rainbond打包业务模块，实现业务积木式拼装

使用Rainbond一键升级企业应用​

由 RAM 实现而来的应用模版是具备版本控制机制的，这意味着在同个应用模版的不同版本之间可以快速的升级与回滚。

对于开发人员而言，在源应用一侧作出需要的变更，无论是代码的改动后构建，还是新加入其他组件，都会在下一次应用模版发布过程中叠加到新版本的应用模版中去。开发人员务必注意发布时定义的版本号，Rainbond 通过它来确定是否进行升级。

对于交付人员而言，只需要将不同版本的应用模版导入到交付环境中，Rainbond 会自动识别同个应用模版的不同版本，并执行一键升级操作。

而在已经交付完成，正在运行的应用页面中，小 A 找到了升级的入口。Rainbond 识别到了最新的版本，而升级操作也是一键触发，非常好用。

一键安装和一键升级的实现原理​

基于 RAM 模型实现的应用模版为何能做到一键安装复杂应用？首先需要了解应用模版内部构造。

应用模版由两个部分组成：应用元数据、容器镜像压缩包。

应用元数据

应用元数据负责描述应用以及其内部组件的特征。换句话说，应用元数据是对 RAM 模型的描述。这些元数据会保存在 Rainbond 数据库中，Rainbond 通过拾取这些元数据，了解到需要安装的是一个什么样子的应用。这些元数据主要包括的内容如下：

容器镜像

业务容器镜像的来源，应用模版一经导入后，容器镜像会被装载到 Rainbond 所引用的容器镜像仓库中。启动每一个组件时，Rainbond 会根据元数据中记录的镜像地址拉取对应的镜像。

经过应用元数据的解析插入，以及容器镜像的导入，交付人员就可以在客户环境中一键安装企业应用了。

企业应用一键安装完成后，Rainbond 可以保障让其运行起来。如果希望能更进一步，确保企业应用内部的业务逻辑也能够正常工作，则需要在应用模版的制作过程中注意更多的自动化改进。

升级

一键升级和一键安装的原理类似，一键升级的过程实际上是分别对应用元数据和容器镜像进行了版本的变更。

容器镜像的升级很好处理，只需要引用不同的 tag 即可。而对于可升级应用内的所有组件而言，升级的过程中会覆盖以下应用元数据变更。

值得注意的是，基于应用模版的升级，仅包含了应用程序的升级。实际环境中，经常涉及到持久化数据的变更。最常见的一种情况，是企业应用所使用的数据库的表结构，需要跟随应用程序的升级而变化。前文中介绍的 源码构建实现数据库表结构自由升级回滚 方案，就可以处理这种表结构的版本控制。

企业应用的管理与运维​

企业应用的安装与升级都是一次性的，而管理与运维则是长久持续的。

当企业应用被交付到客户环境之后，运维人员需要掌控管理运行环境的能力。现代 IT 基础设施是非常复杂的，运维人员想要在物理机、虚拟机等不同环境之间统筹有度已属不易，想要在公有云、私有云乃至混合云之间游刃有余更是对其技术能力提出了挑战。如果能有一款易用的平台抹平不同基础设施之间的差异，那就将极大的简化运维人员的管理工作。

了解 云原生应用管理，像管理手机APP一样管理企业应用 。

总结​

本文重点讲述了企业应用自动化安装和升级的实现过程，这个过程非常适合企业产品没有功能定制化的标准化交付，对接开发环境可以实现客户的持续交付，提高10倍以上交付效率。 然而，标准化交付在企业产品交付过程中只能占少数，对于需要功能定制化的个性化交付场景该如何提供交付效率呢？我们将在下一篇文章将详细介绍。

建立企业应用商店，从应用商店一键安装企业应用​

手机 APP 的安装已经做到了极致的简单，在预装好的 AppStore 中一键安装想要的 APP 即可。这种一键安装的体验流程，哪怕一个小朋友都可以很好的掌握。企业应用部署难度大，组件数量多，其安装的复杂程度远高于手机 APP 。那么在企业应用的安装领域，能否做到安装手机 APP 一样的一键式体验呢？

类比手机 APP 的安装过程，应用商店这个集合了大批 APP 的平台是必不可少的一环，正是有苹果 AppStore、Google Play 这样生态繁盛的应用商店，才让手机消费者随心所欲的安装手机 APP。Rainbond 应用商店是企业级的 AppStore。每个用户都可以将自己部署在 Rainbond 上的企业应用发布到应用商店中去，供其他用户使用，其他用户只要从应用商店一键安装和升级，使用体验和手机 AppStore 的体验类似。

为了最终用户的使用体验，开发手机 APP 的企业需要按应用商店的标准开发和上架，企业应用商店的实现也是类似的思路，企业应用的供应商需要按企业应用商店的标准打包和上架，Rainbond 内置的应用商店有一整套的应用打包、测试和上架过程，比如从源码打包、二进制文件打包、容器打包等，这些打包过程都不需要改动原有代码。按应用商店的规范打包和上架，不仅简化了应用的安装和升级过程，同时也建立了企业应用的验收标准。

企业应用管理复杂，该如何简化管理？​

对于一个手机 APP 而言，实际上我们可以做的管理操作很少，仅仅涉及到安装、升级、删除。而一个企业应用则要复杂得多，一个企业应用所需要的管理操作，至少包含了以下这些点：

• 生命周期管理：就像手机用户需要安装、使用、升级、删除 APP 一样，安装、升级、启动、关闭、删除等生命周期管理相关的操作，是企业应用所需要的最基础的管理操作。
• 批量管理：手机 APP 只有一个组件需要管理，而企业应用往往是多个服务组件相互依赖组合形成的。所以会需要有批量操作的需求。
• 资源分配：手机用户从来不用关心需要为一个 APP 分配多少资源，而企业应用的管理者必须关心为每个组件分配合理的计算资源。计算资源分配不足会让企业应用运行不畅甚至无法运行，过多的分配计算资源会导致资源浪费。
• 伸缩特性：手机 APP 并没有运行多份的需求，它只需要保证在手机中正常运行， 满足主人的个人使用压力即可。企业应用无论是在高可用方面还是在抗并发方面，都会对横向伸缩能力提出要求。
• 可观测性：手机用户从来不关心是否能够看到手机 APP 的运行状态，只关心它们的功能。但是企业应用管理者会对企业应用提出很高的可观测性要求，包括运行状态、资源占用、性能表现、运行稳定性等。
• 故障恢复：手机用户允许 APP 偶尔出现闪退，无非是重新打开一次罢了。而企业应用管理者对企业应用的期待是，即使企业应用出现了问题，也可以快速从故障状态中恢复过来。
• 迁移/备份：手机 APP 的用户数据都保存在云端，数据的迁移、备份操作简单。企业应用重视数据，对迁移备份等操作要求很高，有的场景甚至要求跨集群迁移备份。

经过对比，可以发现企业应用在管理方面需要注重的点，比手机 APP 复杂得多。但这不意味着企业应用管理人员一定要付出更多的努力来管理企业应用。选择正确的企业应用管理工具，会使得企业应用管理工作事半功倍。

Rainbond 从三个方面简化企业应用的管理：

1. 让常规的管理简单容易上手，比如：安装、升级、启动、关闭、删除、伸缩、配置域名等管理操作都可以一步完成。
2. 复杂的运维过程实现自动化，比如：安装/升级/启动的操作过程、健康检测、服务高可用、自动伸缩等。
3. 过程实时监控和可视化，由于管理过程实现了简单操作和自动化，就需要加强监控和可视化了解应用运行情况，做到过程可控可管。

让企业应用常规管理简单容易上手​

前文已经分析过，手机用户对 APP 的管理操作是仅限于开启、关闭等简单的操作。对于企业应用而言，我们希望企业应用管理者主动发起的管理操作，也是足够简单的操作。企业应用管理人员完全通过图形化界面，来完成对企业应用的生命周期管理操作。

对于企业应用整体而言，可以执行批量的管理操作：

涉及到生命周期管理的操作包括但不限于：

• 企业应用整体的启动、停用、更新、构建、升级
• 面向企业应用内部所有组件的批量启动、关闭、更新、构建、重启、删除

对于希望将企业应用完整的迁移到其他集群，或者做一份备份的场景而言，图形化操作的迁移/备份功能可以解决问题：

对于指定的服务组件而言，可以进行的主动管理操作会更多：

除了较为常见的生命周期管理之外，企业应用的管理者还可以有更多的主动操作：

• 版本管理，在多个构建版本之间一键升级或回滚

• 伸缩管理，主动的为服务组件设置计算资源、实例数量

• 环境配置，主动为服务组件设置环境变量，挂载配置文件

• 存储管理，主动为服务组件添加持久化设置，使数据持久化的保存

• 端口管理，主动为服务组件添加端口访问策略

• 插件管理，主动为服务组件安装可以扩展运维能力的插件

• 进入 Web 终端，直接操作当前服务组件的容器 shell 环境

常规企业应用管理操作基本都是 UI 界面，过程也不需要学习底层技术，通过界面摸索就可以上手。

复杂的运维过程实现自动化​

企业应用确实比手机 APP 复杂太多，但是我们又希望企业应用的管理者尽量少操管理的心，那么提供自动化的运维能力就十分有必要。

Rainbond 被设计成一款具备强大自动化运维能力的平台。这些自动化运维能力，可以最大限度的解放企业应用管理人员的双手，切实提升生产力。这些自动化运维能力提炼自许多工程师长久以来的运维工作经验，这些能力往往表现在企业 IT 系统的底层，平日里不显山露水，但是却关乎企业应用运行的好坏。

1. 常规管理的过程实现自动化

   企业应用的常规管理本身是挺复杂的，为了前端的操作简单，后端的实现过程就必须自动化。 比如：

   • 安装过程自动化，安装过程需要为每一个服务自动化完成软件包安装、服务配置、端口管理、服务启动等步骤。
   • 升级过程自动化，升级过程需要自动化完成对比版本差异、差异安装、滚动升级等步骤。
   • 启动过程自动化，当一个企业应用有多个子服务时，还需要自动处理它的服务启动顺序。

2. 健康检测与故障恢复

   企业应用管理人员不希望为了应对不知何时会发生的企业应用故障而每时每刻值守在机房。因此 Rainbond 提供健康检测能力，来替代企业应用管理人员，时刻关注着企业应用的健康状况。并且提供可选的异常处理手段，在异常发生时自动处理。

   Rainbond 平台支持两种模式的探针来自动检测服务组件中所有实例的健康状况。TCP 模式的探针，会每隔一段时间侦测服务组件的指定端口是否可以联通，这种检测是基于网络和端口的联通性来实现的。而 HTTP 模式的探针，会每隔一段时间，请求指定的 URL，并根据 HTTP 返回码来判断实例的健康状况。相对而言，TCP 探针应用的范围更广泛，而 HTTP 探针会更加精确。因为可能存在这样一种软件设计缺陷，WEB SERVER 处于正常工作状态，端口可以正常监听，但是业务接口已经无法提供正确的返回，这对于最终用户而言，也是一种应该被检测到的错误。

   对于检测失败之后的处理，平台提供两种策略，下线与重启。

   将问题实例从负载均衡中下线，这是一种降级行为。触发下线后，不会再有新的请求到达问题实例，问题实例从巨大的访问压力中得以缓解。接下来，如果服务组件足够健壮，它会在处理完大量的积压请求后恢复，重新通过健康检测后上线。这里包含一个隐藏的假设，要求服务组件具备多实例特征，否则问题实例的下线会导致服务组件整体无法提供服务。

   重启则是一种相对武断的处理方式。但不可否认的是，在服务组件不那么健壮的情况下，重启实例是最简单有效的恢复手段。

   

3. 高可用能力

   Rainbond 为企业应用提供了高可用能力的支持。在一个 Rainbond 集群中，往往存在多种不同身份的服务器节点，而每种不同身份的服务器节点也不止一台。这意味着 Rainbond 本身就是高可用的，运行在其上的企业应用，也可以自由的在不同的宿主机节点之间漂移。

   在 Rainbond 集群中的某台服务器出现故障时，Rainbond 集群并不会受其影响，也会将受到服务器故障影响的企业应用重新调度到其他正常的服务器中去。企业应用管理人员只需要在事后修复故障的服务器，整个 Rainbond 集群又会完成自愈，而企业应用在这个过程中受到的影响是可以忽略不计，尤其是当企业应用本身伸缩了多个实例的状态下，可以做到最终用户无感的处理体验。

4. 自动伸缩能力

   如果企业应用的最终用户是人，那么它的访问压力情况，都会有潮汐特征。好比一款供企业内部人员使用的 OA 系统，工作日的流量远比休息日高，工作时间的流量远比下班时间高。那么可否让这款 OA 系统根据流量的大小，自动调整实例的数量。令其忙时启动足够数量的实例抵御访问压力，闲时自动降低实例数量，将资源留给其他企业应用。Rainbond 平台可以赋予企业应用自动伸缩的能力。

   Rainbond 平台对于其托管的每个企业应用的当前状态了如指掌。当然也了解当前企业应用的资源使用数量是否已经接近分配的上限。通过自动伸缩的设置，可以为企业应用设置一个上限，当 Rainbond 发现企业应用使用的资源已经超过这个设定值时，自动的扩展实例的数量。这个设定值，可以是内存使用量/率或 CPU 使用量/率，亦或是两种资源的综合设定值。

   

管理过程可观测和可视化，做到可控可管​

手机用户不会想着观察 APP 内部的运行状态，但是企业应用管理人员不这么想。可观测性是一切管理工作的前提，只有看得见，才能摸得着。

Rainbond 提供的可观测性无处不在，从集群维度开始，到应用级别，最终到每一个服务组件级别，都体现着丰富的可观测性。

对于一个企业应用而言，看到它内部的拓扑结构，和所有组件的运行状态是最基本的可观测性要求。Rainbond 提供了应用拓扑图界面，并根据不同的颜色来体现每一个服务组件的运行状态。绿色代表运行中，黑色代表已停止，而红色代表服务组件处于异常状态。

对于单个服务组件而言，其可观测性的粒度要更细致。服务组件的总览页面中，描述了当前服务组件的详细信息，服务组件的每个实例，也都体现自己的运行状态。

下方的操作记录，更是详细描述了服务组件发生过的每一件事。

服务组件的监控页面，集中的体现了有关其运行状态的各种可视化图表。

• 体现业务性能情况的实时分析曲线

• 有助于优化程序的 5 分钟请求排行

• 各个实例的资源用量曲线

• 支持基于 Prometheus 体系的 Exporter 指标自行绘图

Rainbond 的监控大屏系统，提供全局可观测性的中心。

写在最后​

Rainbond 提供一个解决企业应用的管理问题的全新思路，它不仅优化了管理和使用体验，还能高效管理应用供应商，应用商店也让管理人员对应用自主可控，减少对供应商的依赖。