当前位置：首页 > 文章列表 > 数据库 > MySQL > 在Rainbond中实现数据库结构自动化升级

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

来源：SegmentFault 2023-01-24 10:38:58 0浏览收藏

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个数据库开发实战，手把手教大家学习《在Rainbond中实现数据库结构自动化升级》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！

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 来定义数据库表结构版本。默认情况下，是指代码根目录下的

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

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

最简化定义项包括：

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

源码构建过程中，会遍历识别

-- liquibase formatted sql
-- changeset guox.goodrain:1
create 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:2
create 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 类型的

-- changeset other.goodrain:3
alter 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 进行升级。

构建过程中没有任何变化，但是在启动过程中，针对更新的

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

鉴于回滚后的业务组件一旦重启或更新，就会比对 changelog 文件后重新升级 Schema，所以在执行回滚操作后，务必添加环境变量

# 以下命令在 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