模块化个性化交付

个性化交付的难点​

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

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

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

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

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

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

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

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

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

Rainbond的解决方案​

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

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 集群自动化管理能力，以及企业应用一键安装升级能力。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倍以上交付效率。 然而，标准化交付在企业产品交付过程中只能占少数，对于需要功能定制化的个性化交付场景该如何提供交付效率呢？我们将在下一篇文章将详细介绍。