在 Rainbond 中实现数据库结构自动化升级

2022 年 2 月 10 日
本文字数：5955 字
阅读完需：约 20 分钟

Rainbond 这款产品一直致力于打通企业应用交付的全流程，这个流程中不可或缺的一环是企业应用的不断升级、迭代。Rainbond 特有的能力，是可以将囊括多个服务组件的企业应用系统进行打包，并执行一键安装、升级以及回滚的操作。上述的内容仅仅解决了应用程序本身的版本控制问题。企业应用的升级迭代流程想要完全实现自动化，还需要能够自动处理数据库表结构（Schema）的版本控制。经过不断的探索，Rainbond 首先在源码构建领域借助业界领先的 Liquibase 集成了云原生时代的数据库 Schema 版本管理的能力。

Schema 版本管理难题

数据库表结构（Schema）定义了数据表（Table）的名字，以及每一个数据表中所包含的数据列（Column）的名字、属性等信息。它描述了一个数据库所拥有的框架，记录在数据库中的数据都需要遵循 Schema 里的定义。

区别于应用程序自身的升级，Schema 版本管理问题，本质上是一种持久化数据的升级，这一特征伴随着两个疑问：

持久化数据如何升级：云原生时代的交付，已经无法跳脱出容器化、平台化的特征。各大云原生平台在进行软件交付过程中，都不会轻易将持久化数据纳入版本控制体系中去。原因很简单，每个交付环境中的数据都是不同的，升级过程中很难抉择持久化数据的统一版本管理方案。
哪些持久化数据需要升级：既然难以抉择持久化数据的统一版本管理方案，那么退而求其次，是否可以优先选择必要的持久化数据进行版本管理。缩小范围之后，就突出了数据库表结构这一特殊持久化数据类型。其版本管理的必要性是显而易见的，应用程序本身从 V1 版本升级到了 V2 版本，那么对应的数据库表结构也需要增加必要的新表、新列。

这两个疑问引出了本文的主旨：在企业级软件交付领域，如何合理的在每次升级的过程中处理数据库表结构（Schema）的版本控制？

传统软件交付领域，在 Schema 版本管理方面有两种主流的解决方案：

人工处理：这是最基础的 Schema 版本管理方式。现场交付人员不仅需要处理应用程序的升级流程，也直接操作数据库，完成 Schema 的升级。这种方法最直接，但是无法自动化处理的流程都具有一些通病：低效、易错。
代码处理：这是一种进阶的方式。通过在应用程序内部引入第三方库，来进行 Schema 的版本管理。这一操作已经可以免除交付现场的人工处理流程，交付人员只需要将应用程序进行更新，程序本身会连接到数据库，对 Schema 作出自动化的变更。这种方式的自动化程度已经可以满足要求，但是也具有引入第三方库的通病：技术成本提升、侵入性、与语言或框架绑定。

云原生时代的解决思路

云原生时代，应用程序的使用者、交付者都希望通过所选用的平台来赋能自己的应用程序。在本文探讨的领域中，这种期待可以具体的描述为：借助平台能力，以无侵入的方式，将 Schema 版本管理能力赋予应用，使得应用在进行一键升级时， Schema 也自动完成升级。

Rainbond 作为一款云原生应用管理平台，也在不断探索为应用赋能之道。在 Schema 版本管理领域，实现了在源码构建过程中集成 Schema 版本管理的能力。应用本身不需要改动任何代码，仅仅需要将两种类型的文件放进代码根目录下的指定目录下即可。这两种文件分别是：定义了数据库实例连接地址的配置文件，升级 Schema 所使用的 Sql 脚本文件。

关于源码构建

源码构建功能，本身就是一种 Rainbond 对应用的赋能。云原生时代，应用都在向容器化的方向迈进。容器化的过程中看似无法免除 Dockerfile 的编写，实则不然。源码构建功能可以直接对接源代码，将其编译成为可运行的容器镜像。整个过程不需要开发人员的介入，提供代码仓库地址即可，极大的降低了开发人员的技术负担。

在源码构建的流程中，以无侵入的方式集成了很多能力。比如通过纳入 Pinpoint-agent 的方式集成 APM 能力。再比如通过纳入 jmx-exporter 的方式集成自定义业务监控能力。今天重点描述的，是通过纳入 Liquibase 的方式，集成 Schema 版本控制能力。

关于 Liquibase

Liquibase 是一款专门用于数据库表结构版本控制的 CI/CD 工具。从 2006 年开始，Liquibase 团队一直致力于让数据库变更管理更简单，尤其是在敏捷软件开发领域。这一工具基于 Apache 2.0 协议开源。

经过长期的迭代，Liquibase 已经非常成熟可靠，通过 sql、yaml、xml、json 在内的多种文件格式，开发人员可以快速的定义出符合 Liquibase 风格的数据库表结构变更文件，这种文件被称之为 changelog。基于 changelog 中的定义，Liquibase 可以非常方便的在多个变更操作版本之间升级与回滚。

Liquibase 提供多种方式供开发人员交互，包括一种通用的命令行操作模式，源码构建通过命令行形式集成 Liquibase 的 Schema 版本管理能力。

代码定义的 Schema 版本控制能力

Rainbond 源码构建推崇代码定义各种能力。对于 Schema 版本控制能力而言，也是通过代码仓库中的指定文件来定义的，我们可以简要的称之为 Schema As Code，这种代码定义能力的实践，要求每一次 CI 工作都由一个代码仓库地址开始，比如 Git。对于每一个数据库实例来说，通过指定目录下的配置文件和 changelog 来定义数据库表结构版本。默认情况下，是指代码根目录下的 Schema目录。

下面是一个代码结构示例，Rainbond 官方同时提供了一份完整的代码示例 java-maven-demo :

.├── Procfile├── README.md├── Schema│   ├── changelog.sql       # 定义数据库表结构│   └── mysql.properties    # 定义数据库实例连接信息├── pom.xml└── src

复制代码

Schema 目录下的 mysql.properties 和 changlog.sql文件定义了如何进行 Schema 版本控制。

mysql.properties 定义了数据库实例的连接方式，以及所引用的 changelog 文件地址。

driver=com.mysql.cj.jdbc.Driverurl=jdbc:mysql://${MYSQL_HOST}:${MYSQL_PORT}/${MYSQL_DATABASE}?createDatabaseIfNotExist=true&characterEncoding=utf8username=${MYSQL_USER}password=${MYSQL_PASSWORD}changeLogFile=changelog.sql

复制代码

最简化定义项包括：

driver：指定使用的 jdbc 驱动，源码构建中集成的驱动支持 mysql、mariadb、mssql、mongo、postgresql、sqlite 等常见类型数据库。
url：定义数据库连接地址，可以通过 jdbc 的标准写法来预创数据库实例。
username&password：定义数据库实例的登录凭据。
changeLogFile：定义该数据库实例表结构变更文件的路径。

源码构建过程中，会遍历识别 Schema 目录下的所有 properties 文件，并在启动时处理每一个数据库实例的 Schema 版本控制流程。通过配置文件的组合，在以下各种常见场景中都可以很好的工作。

单个数据库实例
多个相同类型数据库实例，比如应用同时连接了多个 mysql
多个不同类型数据库实例，比如应用同时连接了 mysql、mongo
同个数据库中的多个数据库实例，比如应用同时使用同个 mysql 中的多个库实例

changlog 的最佳实践

changelog 文件，是管理 Schema 的关键所在。以下是一个示例：

-- liquibase formatted sql-- changeset guox.goodrain:1create table person (id int primary key,name varchar(50) not null,address1 varchar(50),address2 varchar(50),city varchar(30));-- rollback drop table person;-- changeset guox.goodrain:2create table company (id int primary key,name varchar(50) not null,address1 varchar(50),address2 varchar(50),city varchar(30));-- rollback drop table company;

复制代码

推荐使用 sql 类型的 changelog 文件来定义 Schema 版本，因为这最符合开发人员的习惯。

changlog 文件通过注释来定义一些行为。常见如下：

# 定义 changelog 文件的格式，这是每一个 changelog 文件的开头项-- liquibase formatted sql # 定义变更集，后面跟随的，是开发人员姓名，以及变更集的序号，这个序号很重要，建议使用有序数字来定义-- changeset guox.goodrain:1# 定义回滚操作，每一个变更集都应该定义与之对应的回滚操作，这使得在变更出现问题时，快速回滚到指定版本的变更集-- rollback drop table staff;

复制代码

Liquibase 官方提出了一系列的最佳实践，有一些最佳实践应该作为开发人员的默认行为。

每个变更集仅包含一个变更，通过细化数据库表结构的变更版本，这可以防止失败的自动提交语句使数据库处于意外状态。
changeset 的 ID，选择有序且独一无二的数列，或者对开发者友好的名字。
让版本永远可回滚，为每一个 changeset 设置合理的回滚操作。

有关于 mysql.properties 和 changlog.sql 文件的写法，更多的特性请参考 liquibase 文档 ，这些特性都可以被源码构建所继承。

Schema 生命周期流程

1. 构建流程

执行正常的源码构建流程时，会自动识别代码根目录下的 Schema 目录，准备 Schema 版本管理所需要的基础环境，包括 jre 和 Liquibase 工具包。

构建日志会有以下提示：

2. 启动流程

完成构建流程后，服务组件会自动进入启动过程中， Rainbond 平台会根据代码中定义好的配置文件，针对每一个数据库实例，进行自动升级处理。

处理过程中，在服务组件的日志中的头部位置，会打印相关的记录：

上图中演示了针对同一个 mysql 数据库中的多个库实例进行表结构的升级操作。对于空的库实例而言，这也相当于一次初始化的操作。

在示例中，Rainbond 分别向应用所连接的同个 mysql 数据库中的两个库实例（分别名为 Initialize anotherdb）进行了表结构初始化操作，分别创建了表company 、person 以及 another_company 、another_person。在数据库组件的 Web 终端登录后，可以验证：

3. 发布到组件库

Rainbond 特有的发布机制，可以将业务组件和数据库组件统一发布为一个应用模版。方便在不同的环境中一键安装交付。通过应用模版交付的应用，依然具有 Schema 版本控制的能力。全新安装的应用模版，其数据库也会被初始化为上述状态。在这里，我们称发布的应用为源应用，由应用模版安装而来的应用为已交付应用。

4. 代码更新

当开发人员持续迭代业务系统的时候，Schema 也随之改动，假定新版本的业务系统，要求 Initialize 新增表 staff，并为已有的 person 表添加一个新的列 country。那么开发人员应该为对应的 changelog.sql 文件新增以下内容，并和新的业务代码一并提交，保证业务代码和 Schema 保持一致。

-- changeset other.goodrain:3alter table person add column country varchar(2);create table staff (id int primary key,name varchar(50) not null,address1 varchar(50),address2 varchar(50),city varchar(30));-- rollback drop table staff;-- rollback alter table person drop column country;

复制代码

在源应用处点击构建，Rainbond 会拉取最新的代码，更新业务应用的同时，为 Schema 进行升级。

构建过程中没有任何变化，但是在启动过程中，针对更新的 Initialize 和保持原状的 anotherdb 库实例，Rainbond 给出两种不同的处理：

5. 基于应用模版的升级

源应用有了新的版本，已交付应用也应随之有变更。首先，应用模版需要有一个更新的版本，重复发布流程，定义更高的版本号即可。已交付应用可以根据 Rainbond 的提示，一键升级到更新后的版本。

6. 验证

登录已交付应用的数据库组件中，可以查看对应的 Schema 变化。

7. 回滚

数据库表结构的回滚操作是一个很严肃的问题。本着数据库表结构只增不减的原则，已经生效的 Schema 不会随着已交付应用的一键回滚而有任何变动。如果一定要进行回滚，则需要运维人员登录业务组件的 Web 终端手动操作。

需要注意的是回滚的顺序：数据库表结构应该先于应用程序回滚。这是由于一旦应用程序回滚完成， changlog 文件本身也回滚到了上个版本，无法再进行数据库表结构的回滚。

执行以下命令，可以根据指定的配置文件，对数据库表结构进行回滚操作，回滚幅度以 1 个 changeset 为单位。

cd Schema/liquibase rollbackCount 1 --defaults-file=mysql.properties

复制代码

鉴于回滚后的业务组件一旦重启或更新，就会比对 changelog 文件后重新升级 Schema，所以在执行回滚操作后，务必添加环境变量 ALLOW_SCHEMA_UPDATE=false 来禁用 Schema 版本管理控制功能，直到新版本应用模版的升级。

常见问题

如何在 *.properties 配置文件中合理的定义所有数据库实例的连接地址和凭据？

使用环境变量来代替 *.properties 配置文件中的数据路实例连接地址和凭据信息，定义方式详见文中的示例。Rainbond 源码构建过程中，会拾取运行环境中的所有环境变量，对目标配置文件进行渲染，所以对于环境变量的命名并不重要，只需要保证定义的环境变量会在最终交付环境中生成即可。无论环境变量来自于自定义的环境配置还是 Rainbond 独有的连接信息机制。

执行回滚操作失败？

回滚如何操作，定义在 changlog 文件中。务必保证每一个 changeset 都有对应的回滚策略，方可保证每次回滚都得到正确的结果。

执行 Schema 升级的过程中报错：!! Failed to check the database status. Check /app/Schema/xxx.properties.log

每一次执行 Schema 变更的过程中，都会先进行检查，包括数据库实例地址的连通性、changelog 文件的可执行性。如果检查不通过，则不会对数据库作出任何操作，但是检查的结果会记录在日志文件中，可以登录 Web 终端，查看提示中的日志文件内容。

老用户如何获取 Schema 版本控制功能？

这一功能和 Rainbond 的版本脱离，所以老用户可以通过更新源码构建相关组件来获取这一能力。执行以下一组命令即可：

# 以下命令在 Rainbond 集群内任意节点执行；如果你使用 dind-allinone 版本，则应该在 rainbond-allinone 容器中执行
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