破解分库模式下Schema变更难题--来自金融SaaS服务商长桥科技的管理实践

长桥科技（Longbridge Whale）是一家专注券商数字化发展的金融科技公司，为券商提供新一代的一站式互联网证券交易云服务解决方案，其核心团队由来自新加坡及香港的资深金融管理者，以及来自阿里巴巴、字节跳动等科技公司技术专家组成。

SaaS 应用的数据库管理模式

SaaS 应用的数据库管理模式可以根据不同的需求和业务模式进行灵活配置，但基本可以归纳为两种模式：

• 单一数据库模式（Multi Tenancy）

在单一数据库模式下，所有的客户数据都存储在一个数据库中。这种模式的优点是简单易用，管理成本较低，但缺点是数据库扩展能力较弱，且无法对不同租户间的数据进行有效的隔离。

• 分库模式（Multi Single Tenancy）

在分库模式下，不同的客户数据存储在独立的数据库或独立的实例中，甚至分布在不同地域的数据中心。这种模式易于扩展，能够应对更大的业务压力，更关键的是能满足各类合规要求，但也让数据库的日常管理难度大幅上升。

分库模式下变更管理的主要难点

对于金融类应用而言，租户间的数据隔离是一种很常见的诉求，因此多会采用分库模式作为 SaaS 应用的数据库架构。如果一个租户对应一个独立的数据库，随着租户数的增加，单个应用管理的数据库会轻松的突破百个甚至更多。这上百个数据库在 Schema 上是要求强一致的，但实际的变更管理过程中，难免会遇到如下问题：

多库的批量发布

一次性需要变更上百个甚至更多数据库，手工执行几乎不可能，最常用的应对方法就是编写脚本进行批量执行。然而脚本需要人工编写维护，编辑或执行疏忽都可能造成严重的后果，当有人员流动需要交接工作时大量的“私人订制”脚本难以共享，甚至新员工需要重新编写一套自己的管理脚本。

数据库 Schema 差异管理

租户数据库理论上要求同构，但实际工作中因为开发团队手工管理变更脚本，或是一些临时性的紧急情况，部分库总会出现或多或少的 Schema 差异，导致后续的统一变更经常在部分库上发布失败，排查过程费时费力。

新租户库的 Schema 同步

新业务租户的创建一般是由业务侧发起。在很多 SaaS 企业中，这一过程并不会第一时间通知管理团队，导致新租户库的纳管存在少则数小时多则数天的时间差，这一时间差足够产生大量的 Schema 差异。

基于 Bytebase 变更管控能力破解 Schema 一致性难题

作为金融 SaaS 服务商，长桥天然选择了分库模式，伴随着其业务的快速增长，数据库数量快速增加，Schema 管理问题随之凸显，若不尽快解决，每一次变更轻则影响发布时效，重则影响业务运行。与许多科技公司类似，长桥基于开源方案建立了基础的数据库审核发布平台，但此类平台普遍欠缺 Schema 变更管理能力，无法应对现阶段面临的困境。为了从根源上解决此类问题，长桥引入了 Bytebase。

批量解决已有数据库的 Schema 差异

一次比对多个数据库

由于业务已经运行了一段时间，已有的租户库已经存在部分 Schema 差异，靠人工肉眼比对上百个库是不可能完成的任务。而一些 Schema 比对工具只能对两个库之间或是若干表进行比对分析，同样难以适应大规模比对需求。

Bytebase 提供了一套批量 Schema 比对方案，通过指定基准库，可以一次性将所有库进行比对，并一键生成变更工单，快速将已有数据库的 Schema 差异抹平。

杜绝未来变更产生 Schema 差异

解决了历史遗留问题，需要在后续的变更中尽可能确保不再产生新的差异，或一旦发生差异能快速发现，快速解决。

Bytebase 从预防、告警、修复三个层面切入，提供了过程管控，自动检测与偏差修复等一系列功能来应对。

• 变更一致性管控

变更将一次发布到所有的目标库

杜绝偏差的关键是做好变更管理工作，管理团队要求所有变更必须通过 Bytebase 进行。Bytebase 利用项目来组织数据库，对于同一个业务下的所有同构租户库都将被纳入同一个项目，并由业务开发团队自助完成变更。利用批量变更管理模式，原则上每一次变更都将应用到该项目下的所有数据库，任意一个目标库执行成功，在同一次变更中将不再允许对脚本进行任何修改。

当然，实际的业务场景总是复杂多变的，某些变更确实只需要发布到部分库，例如业务数据的临时后台修复，配置数据初始化等，因此仍然允许在批量变更模式下挑选部分库进行发布。

• 自动偏差检测 (drift detection)

实际的生产环境中偏差 (drift) 的产生仍然难以避免，例如访问权限未完全收回时业务开发同学通过其他客户端执行了变更，或是一些紧急情况直连数据库发布了某些脚本。偏差一旦产生往往难以及时发现，当未来的某个时刻这个偏差诱发错误时，往前回溯可能已经很难找到偏差产生的原因，给修复带来了困难。Bytebase 提供了自动偏差检测能力，定期扫描数据库的 Schema，从而第一时间发现脱离管控的变更并给出告警。

• 差异快速修复

一旦发生了差异，即可利用 Bytebase 库表同步功能快速比对差异，并自动生成变更工单修复差异。

新租户库的自动化纳管

另一个容易产生 Schema 偏差的点在于新租户库的供应。在此前的方案中，当业务人员在前台创建一个新的租户，程序可以自动创建租户数据库并同步到某个版本的 Schema，并完成数据初始化工作，很多 SaaS 公司也采用了类似方案。但随之而来的问题是，如果技术团队采用脚本或者其他独立工具进行变更管理，新租户库将无法做到自动纳管，需要发起方主动通知或是技术人员定期被动扫描，再手动将其纳入管理。这一过程短则数小时，长则数天，足以产生新的 Schema 偏差，导致每一个新租户库总是与其他数据库存在一定的差异。为了解决这一问题，需要将整个供应流程与纳管流程打通实现完全的自动化，Bytebase 提供了 两种方案：

• API 方案

应用调用 Bytebase API 创建新数据库并自动纳管，由 Bytebase 完成数据库的 Schema 同步工作，应用完成后续的数据初始化工作。

• Terraform 方案

应用调用数据库实例供应商的 Terraform Provider 创建新的数据库，再调用 Bytebase Terraform Provider 自动纳管，Bytebase 完成数据库的 Schema 同步工作，应用完成后续的数据初始化工作。

自动纳管的过程需要注意一个小细节，如果新租户库创建过程中正好有新的变更在发布，可能导致缺失了这个新变更，Bytebase 将自动检测此类特殊情况，并确保新纳管的租户库与基准库保持 Schema 的完全一致。

长桥基于 Bytebase 的多租户库变更管理流程

在长桥的实践中，基于 Bytebase 构建了租户数据库从创建到纳管的全流程：

1. 每当有新租户需要创建，业务管理系统（SCM）就会调用 Bytebase API 创建一个新的租户库。

2. Bytebase 自动将新租户库的 Schema 同步到最新。

3. 应用基于 Vault 获取到数据库访问权限，并初始化租户数据。

4. SRE 与业务开发团队基于 Bytebase 完成租户库的日常变更。

目前，长桥仍在进一步将 Bytebase 能力融入研发流程中去，在确保安全稳定的前提下，不断赋能研发实现自助式、自动化的变更管理，后续我们也将邀请相关负责人给大家做一个正式的分享，敬请期待🥳。