开发者友好的数据库变更管理平台是怎样的？

Bytebase 101

公司概况

Bytebase 是一款聚焦在团队协作场景下的数据库结构变更和版本管理的开源工具，主要解决研发工程师和 DBA（数据库管理员）在变更数据库结构时的协同问题。

创始人陈天舟曾在 Google 硅谷总部云数据库团队担任技术负责人，也是 Google 内部 PostgreSQL 和 MySQL 分支的主要维护者。联合创始人徐丹青曾任 Google 总部主任工程师，两次获得谷歌最高工程奖，参与并带领谷歌云的数据库和云服务基础设施的设计和研发。2021 年，他俩共同创立 Bytebase ❤️，2022 年正式开启商业化，并保持两周一次的高速迭代版本的频次。

产品价值

Bytebase 产品的核心价值在于数据库的变更管理，包括访问控制等相关的能力。Bytebase 对开发者更加友好，能够提升开发者的研发效能和研发效率。

设计理念

数据库变更过程中的挑战

面对业务需求快速变化，难免会遇到各种各样的问题，常见的例子有：

1. 多个团队一起去对数据库发起变更，需要解决冲突的问题，例如对多个 SQL 脚本的执行顺序编排。
2. ISV（Independent Software Vendors，独立软件开发商）的用户是私有化的环境，可能对本地数据库做了额外的变更，当新版应用发布的时候，就可能出现脚本冲突，或者对象冲突等，导致脚本发布失败。
3. 应用有多个版本，不同的版本服务于不同的用户，需要维持对应的多套 Schema 版本，而 Schema 可能又由一堆脚本去组成，还需要维护脚本的执行顺序（比如高级版发现了个 bug，还要把这个对应的脚本 cherry-pick 回低版本），这会导致整个 Schema 的版本管理变得非常困难🤕️。

4. 出于某些不知名原因，库里面建了一些对象（表、索引），在生产库不敢轻易删除，难以维护。

Bytebase 的出现有效应对上述这些挑战。

生产力工具

日常研发过程中，需要各种生产力工具来提升效率，比如代码变更管理使用 GitLab，基础设施变更管理使用 Terraform。而 Bytebase 可以搞定数据库变更管理。

Bytebase 不仅面向 DBA，而是一个面向研发组织设计的，也就是 DBA 和开发团队协作使用的 DevOps 平台。正因为如此，Bytebase 很注重和研发流程的整合，原生集成了从上游的代码仓库，到下游的研发管理流程的平台。

Bytebase 提供了一整套完整的企业级变更协同工作流，包括基于 Web 端的查询访问控制，一系列自动化的变更审核能力，多种灵活应对各种研发产品的发布能力，变更失败可以快速回滚，以及对变更 Schema 的版本管理和变更历史记录。

Bytebase 提供了一套完整的解决方案，目前基本上对主流的数据库都实现了支持，包括下图未列出的 Redshift, MariaDB, SQL Server。

开发者友好的变更管理工具

对开发者友好的变更管理平台，是好用的，易用的，能够提升开发效率的，而非简单的提供一个管控平台，从而大幅度牺牲了效率。当前业务面临非常激烈的竞争，如果发布流程不够敏捷，或者说因为管控影响了我们业务研发效率，可能带来的损失也是非常大的。所以我们希望既能够保证我们的安全管控，又能够进一步提升研发的效率，这是 Bytebase 想要做到的。

那如何才能打造一个开发者友好的变更管理工具呢？

1. 基于 Web 端， Bytebase 针对 DBA 和开发者的协同作为核心来设计，而不是简单的管控。
2. Bytebase 集成了开发者常用的工具，比如代码仓库 GitLab, GitHub, Bitbucket，还有自动化部署工具 Terraform 等。
3. 针对研发在真实生产环境中，设计了各种各样的灵活场景和强大的发布方案。

4. 以风险视角为中心的全局的管控操作流程。它的优点在于可以按照风险去定义不同的安全策略，避免用一套策略应对所有的场景，导致研发效率的大幅度下降。

基于项目的管理体系设计

Bytebase 把所有的库和相应的人员按照不同的项目进行划分，这个项目可能是一个产品线，一个部门，一个研发组织等等。在项目内部，研发团队可以自助在此发起一系列的变更，而 DBA，SRE 团队在全局进行一个策略的制定和管控，然后这些策略就通过产品落地。只要你不违反我的策略，那么在项目内部，所有的变更审批管理流程，可以由研发团队自助式的完成，而 DBA 更多是作为管理者以及兜底的角色。由此，可以释放出 DBA 大量的时间去做一些更高价值的工作，比如 Schema 设计，好的 schema 方案可以将很多运维问题提前解决。

以项目为管理边界，进行自助化的管理，这是实现 DevOps 的一个前提。

基于安全协同理念设计的 SQL 查询客户端

Bytebase 会把所有 SQL 访问收口，以提供安全的 SQL 开发能力。在客户端中实现数据库的查询访问控制与数据脱敏。

GitOps 实践方案

基于脚本

这是我们最常用到的变更模式，由多个变更脚本组成，按顺序执行。这种方案最大的好处就是，非常清楚的知道这次变更做了什么，过程透明可控。并且因为它是基于 SQL 的，所有的数据库都能够支持。缺点也很明显，就是需要维护大量的脚本和执行顺序，还要解决冲突问题，假设是多个甚至跨国团队，如果 Schema 有多个版本，对应好几个应用版本，这时候要维护多脚本的执行情况，会出现顺序出错或者遗漏的情况，进而严重影响了整个发布效率。

基于终态

这是 Bytebase 提供的一种新型的变更模式。你不再需要写变更脚本，只需要编辑存在代码仓库里的唯一一份 schema 文件，改成什么样子，Bytebase 就把目标库变成对应的样子。

这种模式的优点就是不再需要写 SQL，不需要管理执行顺序，而是声明式的。当然也有些局限性，比如说不支持 DML，不支持 RENAME。以及需要支持的数据库引擎，目前 Bytebase 优先实现了针对 MySQL 的基于终态变更，后续我们会首先加上对于 PostgreSQL 的支持。

这种模式特别适合集成 GitOps，只需要单一事实来源文件 (SSOT, Single Source of Truth) 在代码仓库里，利用代码仓库的能力，就能保证这个文件的一致性和唯一性，那么库里就不会出现偏差或者脱离管控的对象这些情况。

在 Google 内部，所有针对数据库的变更都是用利用这种模式来完成的。

强大的 SQL 审核能力

Bytebase 强大的 SQL 审核能力，目前优先支持了 MySQL, PostgreSQL, TiDB, Oracle 以及 OceanBase。并提供了多种审核方案，包括在 UI 界面可以调接口来审核。最特别的是 Bytebase 也跟代码仓库做了集成，可以在代码仓库里面实行审核，比如在 GitLab 或 GitHub 里面提交一个 PR 或 MR，只要这里面包含 SQL 脚本，或者说是大家常用的 MyBatis 里的 XML 文件，都能帮你识别到，然后就在代码仓库里面够触发对应的审核，只有通过审核了，才能够合并到指定的分支。

这种模式的优点是：

• 特别符合开发团队的工作习惯，再也不用把 SQL 粘贴到多个工具了。

• 把整个审核流程左移了，在 CI 阶段就触发了审核流程，而不需要到发布那一刻再审核了，增加了容错的时间。

多种发布模式

Bytebase 支持多种发布模式：

1）单库发布

2）批量发布 一般来说 SaaS 公司，有大量的多租户库，分库分表，还有一些工厂管理系统和 ISV 有多个用户的环境要部署。这种批量发布的库其实都是同构的，使用这种发布模式能够方便的进行发布。

3）分阶段发布 也就是流水性的发布模式，可以应对多种情况，比如从开发 > 测试 > 预上线 > 生产流水发布，只要一个 SQL 工单，避免开发阶段提交的变更通过了，但是生产的时候漏发或错发。再比如说有大量多租户业务，可以先挑部分做灰度上线，先把应用发布给几个客户，没有问题再发布到其余的去。

4）跨环境发布 一般来说对于物理隔离的场景，或者说把变更发布到用户的私有化环境中去，可以把脚本导出，再发布到其它环境。

风险驱动的数据库变更管理流程

Bytebase 把所有的数据库操作，都按照不同的规则定义了风险等级。比如当生产环境影响的行数超过一万行，操作类型是 UPDATE 或 DELETE 的时候，可以把它标记为高风险的操作，Bytebase 会根据风险等级去关联自定义的审批流程，之后的流程会触发对应的审批和发布流程。

通过给所有数据库操作定义不同的风险，可以灵活关联不同的审批流，比如研发的测试或预上线环境，风险等级就可以低一些，用一些比较简单的审批流；一些比较高危的操作，可以指定一个复杂的审批流，比如要求 DBA 的参与；再有，一些开发环境可以跳过审批，自动化执行就可以了。通过这种方式可以把所有的变更，进行非常灵活的管控，进一步提升整个研发效率。

与 IM 集成

Bytebase 所有的变更都可以跟 IM 集成，随时把控进度。目前 Bytebase 集成了主流的 IM，用户可以收到所有的变更状态改变的通知。针对飞书实现了基于飞书的移动端审批，如果说这个工单没有任何报错，可以直接进行审批；如果有报错，还是建议到控制台仔细的检查。

基于时间点的恢复 + 闪回

如果变更失败了， Bytebase 有一系列的手段去解决，目前内置了基于时间点的快速恢复（PITR），针对 MySQL 可以做好备份，一旦出了问题可以按照库级别实现一个时间点的恢复。另外还可以针对 DML 的语句级别实现一个快速闪回，MySQL 和 Oracle 都支持这种模式，比如写了一条 DELETE 语句，一不小心多删了很多行，Bytebase 可以一键生成对应的 UNDO SQL 和对应的工单，可以快速找回数据，这是 Bytebase 提供的一个变更失败的兜底保障。当然，Bytebase 内部还集成了很多这样的高级能力，比如针对 MySQL 的大表变更，基于 gh-ost 的 Online DDL 能力等等，这些都确保能更好更高效地完成整个变更流程。

变更完成后,Bytebase 会把所有的变更记录记下，包括变更历史，以及每一次变更前后完整的结构快照和差异。这样的好处，一来可以快速的追溯和审计，二来可以在每一次变更版本中，直接找到当时的 Schema。比如说要还原某个版本做一些测试，不再需要跑一堆脚本了，可以直接找到当时工单完成后的 Schema 快照，通过这种方式我们可以管理一系列的变更版本。

场景示例

1. 一个完整的 Database CI/CD 的流程

最早 CI/CD 只能做到应用代码的 CI/CD，后来有些工具比如 Flyway, Liquibase 可以把数据库脚本打到应用镜里面一起跑，但对 DBA 来说，一旦数据库大，变更流程就可能出错，一旦出错，整个应用的发布就挂在那里，必须重新修改脚本，又要重新打包整个应用镜像。所以需要将应用发布和数据库发布解耦：应用自动化发布，数据库手动发布，这样整个过程是割裂的。如果沟通不畅，可能应用发出去，数据库变更还没有跑完，应用就各种报错了。

Bytebase 是怎么实现 CI/CD 流程的呢？

首先，在代码仓库里同时提交应用的代码和数据库的脚本，这会自动触发在代码仓库内的审核，Team Leader 确认没有问题后，才允许合并到指定分支。此时，应用代码就会触发应用的 CI/CD 的流程，先 build 再 test，然后会有个节点，这个节点会读取此次变更的版本号，通过 API 去 Bytebase 的控制台查询此任务的状态。同时，数据库的变更脚本就会在 Bytebase 生成内部的执行工单，应用会不断查询状态，这时 Bytebase 会进行数据库的审核和变更流程，如果有问题，可以在数据库侧处理，直到把问题解决；如果没问题，就会自动发布，完成后，应用的 CI/CD 流程的 pipeline 会接收到这个信息，触发应用下游的发布，全流程可以打通串联起来。最后，Bytebase 会把这次变更完成后完整的 schema 再回写到代码仓库。

1. 多租户数据库的变更管理流程

Bytebase 有个金融行业的 SaaS 用户，已经在生产环境中用上了。新进客户的时候，业务同学会新建个租户，这个租户包括应用和业务侧，后台会自动创建新的数据库。这个新的数据库会调用 Bytebase 的接口，被自动化纳管，由 Bytebase 把它的结构同步到最新。用户的账号和密码由 Terraform Vault 管理，应用代码会去 Vault 获取账号密码，再把初始化数据写入。如此，SRE，应用开发人员可以基于 Bytebase 管理整个变更流程。

总结

目前 Bytebase 正处于高速发展阶段，在这个领域中，是全球唯一同时入选 CNCF 以及平台工程组织 (platformengineering.org) 推荐目录的产品。同时 Bytebase 面向全球化运营，现支持中文，英语以及西班牙语。