长桥科技（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 构建了租户数据库从创立到纳管的全流程：
- 每当有新租户须要创立，业务管理系统（SCM）就会调用 Bytebase API 创立一个新的租户库。
- Bytebase 主动将新租户库的 Schema 同步到最新
- 利用基于 Vault 获取到数据库拜访权限，并初始化租户数据
- SRE 与业务开发团队基于 Bytebase 实现租户库的日常变更
目前，长桥仍在进一步将 Bytebase 能力融入研发流程中去，在确保安全稳固的前提下，一直赋能研发实现自助式、自动化的变更治理，后续咱们也将邀请相干负责人给大家做一个正式的分享，敬请期待😚。