提高企业产品交付效率系列（1）—— 企业应用一键安装和升级
做好企业应用的交付一直是 ToB 软件厂商的关注重点。Rainbond Application Model（RAM）是Rainbond提出的一种应用模型，通过将企业应用进行模型化的抽象，搭配 Rainbond 平台的应用市场机制，最终实现了一键安装/升级。高度自动化的交付体验，提升了企业应用交付效率，降低交付成本。
通过应用模型实现自动化交付
企业应用指的是支持企业、事业单位或者政府等机构各项业务运作的软件系统。除了支持机构内部的协同工作之外，企业应用也支持企业与其供应商、业务伙伴和用户的协作与协调。
每一套企业应用的复杂程度不尽相同，但往往可以细分出相互协作的多个组件。以轻量级的系统举例，也要至少划分成业务系统与数据库两个部分。大型的系统则有可能包含数十个组件，若干组件也可以形成模块。这些组件或模块之间还需要定义一些配置，来实现彼此之间的关联依赖。如此复杂的场景，的确难为到了 ToB 软件厂商的实施交付人员。
企业应用在传统模式下的实施部署与升级，其难度、成本都与企业应用自身的复杂性成正比。这是由于在传统模式下，实施交付人员更多的通过人工的方式，手动部署服务组件、编辑配置文件。无法自动化处理的流程都具有低效与易错的通病，企业应用的组件数量和复杂性会将这些通病叠加起来。
云原生时代的企业应用交付都依靠各种容器化交付平台落地，通过发挥容器化、平台化的优势，解决了环境一致性、自动化运维、故障自愈等问题。而在简化应用交付与升级这一场景中，所选用平台的能力就十分重要。
Rainbond 是开源的云原生多云应用管理平台，兼具 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 基础设施是非常复杂的，运维人员想要在物理机、虚拟机等不同环境之间统筹有度已属不易，想要在公有云、私有云乃至混合云之间游刃有余更是对其技术能力提出了挑战。如果能有一款易用的平台抹平不同基础设施之间的差异，那就将极大的简化运维人员的管理工作。
总结
本文重点讲述了企业应用自动化安装和升级的实现过程，这个过程非常适合企业产品没有功能定制化的标准化交付，对接开发环境可以实现客户的持续交付，提高10倍以上交付效率。 然而，标准化交付在企业产品交付过程中只能占少数，对于需要功能定制化的个性化交付场景该如何提供交付效率呢？我们将在下一篇文章将详细介绍。
