巧房SaaS数据治理实践

体验【开源中国】全新APP，一站式掌握开源技术动态，即刻下载，开启您的开源技术探索之旅！

导读

巧房SaaS系统，作为业界领先的一站式房产中介解决方案，提供全面的运营管理支持，以适应多样化和复杂的业务需求。该系统为员工提供了一个集成平台，用于执行一系列关键作业，包括房客跟进、客户带看、房源实勘、交易订单管理、营销房源发布、业绩查询、行程量数据统计、财务结算等。

巧房的业务版图已覆盖全国300多个城市，拥有上万家合作客户。系统每日处理的访问量上亿次，管理客户公司的核心数据总容量达TB级，整个SaaS系统包含上百个服务、几千个服务实例，管理着上百套数据库集群和上万个数据库。

面对庞大的数据库资源及库表模型频繁升级，如何系统化的治理以确保数据的安全性和系统的稳定性成为我们面临的主要挑战。

本文旨在深入探讨巧房SaaS系统在建设与落地过程中针对租户数据资源管理一些独特的设计理念和实践细节，而非全面介绍整个系统的架构和设计。我们将聚焦于以下几个核心领域：

数据库架构模式
租户数据库管理
多分区服务设计
开库系统的设计

通过这些深入的分析，我们希望能够揭示巧房SaaS系统在发展过程中积累下来的一些设计理念，以及它是如何满足现代房产中介业务的复杂运营的。

数据库架构模式

SaaS产品平台，本质上是多租户订阅使用的服务模式，因此在技术架构实现层面，需要对不同租户的数据库存储进行隔离和划分。那具体怎么设计，既能确保数据安全性、隔离性和高效访问，又能符合未来更多客户、更多海量数据增长，同时易于对数据进行管理？我们将几种架构比较下：

架构	隔离方式	粒度	优点	不足
多实例多租户	独立应用实例和数据库实例	粗	数据隔离性好，技术实现相对简单，数据迁移方便	成本高、资源利用率低，数据库管理维护复杂、系统升级迭代对库表维护复杂
单实例多租户	共享数据库，独立表	中	数据隔离性较好，资源利用率高	数据管理复杂，系统升级迭代对库表维护复杂
单实例多租户	共享数据库，共享表	细	资源利用率高，管理和维护相对简单	数据隔离性较差，安全性要求高，数据量大时会容易产生慢查询

表1. 数据库架构模式

巧房SaaS从一开始就采用多实例多租户模式，多个或者一个(特殊)公司共用一个数据库实例(Database Instance)、每个公司独立数据库(Database)，同时在数据迁移至58私有云时又在一司一库的基础上扩展成一司多库，最终采用模式如下：

图2. 巧房SaaS数据库模式

究其原因，有以下几点

房产数据相对于其他场景数据，对数据的隔离性、安全性要求高；
单司或单表数据规模都比较大，如单个公司的跟进表发展到后来有达亿及规模的情况，采用分库分表访问方式应对未来数据的增长维护难度也特别大；
鉴于中介房产司的受市场政策影响比较大，不停的会有公司退出或者进入，对退租公司的数据会根据策略进行备份和清理，以释放资源供新租户使用，同时也节省了成本，多实例模式对数据的备份和清理更简单高效；
事实上也得益于这种模式，巧房SaaS数据库在从阿里云迁移58私有云过程中能采取按司迁移、在线迁移、逐步验证的策略，将迁移过程对客户的影响降到最低。

03
04

租户数据库管理

这里说的管理是针对SaaS所有公司数据库的统一管理，对于多实例多租户模式，数据库的操作管理是一大难题，尤其是在版本升级中一次需要对数以万计的公司库表进行批量变更操作。主要从以下三个方面来介绍：

数据库操作
数据库清理
数据库监控

4.1 数据库操作

巧房自研了一套对应的数据操作平台（DMS），旨在简化和规范对公司库和通用库的所有操作。该系统实现了操作的集中化管理，确保所有数据库修改都必须通过提交DMS工单并遵循严格的审批流程。

为了增强安全性和用户体验，DMS系统设计了信息隐藏机制，仅对外展示公司标识或数据库的业务名称。当用户操作特定公司数据库时，只需输入相应的公司标识，即可轻松访问和操作。这种设计不仅简化了用户的操作流程，降低了操作复杂度，同时也提高了数据管理的安全性和效率。通过这样的设计，确保了数据操作的合规性、透明性和可控性。

系统具备的一些基础能力列举：

通用能力	公司库专用能力
权限管理、审批管理支持指定数据库(通用库)的DDL、DML操作支持脱敏查询及敏感字段管理支持对修改数据涉及表的自动备份支持数据的导出；支持对托管数据库配置管理支持查看表结构	支持按公司查询对应的业务库支持对指定的单个或多个公司指定业务数据库操作支持对指定分区所有公司指定业务数据库操作支持对多个公司的库的操作并发执行，提高执行效率支持批量导出多家公司执行结果数据支持对公司所在分区进行切换

表3. 系统基础能力列举

4.2 数据库清理

包含两部分：备份表清理和过期公司库清理，主要目的是保障集群稳定、释放空间、节省成本。

4.2.1 备份表清理

主要针对DMS工单产生的备份表以及定期关键表的备份进行清理，这部分表的量不小，我们设定一套数据库集群上放2000个公司库，备份表保存1个月，每个公司库单条业务线的表在300张左右，正常这个集群上业务表数量在60w左右，结果有一天某个集群备份失败告警了，原因是备份时该集群的表数量超100w，备份表居然是正常表的2/3还多，后面不得不缩短备份表保存周期。

其实产生这么多备份表并不奇怪，大部分是一些元数据表备份，比如某次版本升级的一条DMS工单需要对某张配置表的10条属性值分别做修改，对应了10条操作SQL，就会产生10张备份表，对应到2000个库就是2w张备份表，周期内修改次数多，备份表量就暴涨了，因此针对这类表必须有清理机制。

巧房针对备份表清理采用的手段是：先扫描、后重命名、最后删除的策略。

扫描阶段：备份表大都是DMS系统自动备份生成的，表名有规律包含备份日期，根据配置的保存周期，将周期之前备份表收集保存起来。
重命名阶段：这部分其实就是将扫描出来的表名加上后缀“_x”，但这个操作是调用集团CDB平台的接口完成的，因为所有的数据库都托管集团CDB平台上。
删除阶段：将重命名后带后缀“_x”的表进行删除，也通过调用集团CDB平台的接口完成。

图4. 巧房备份表清理流程

4.2.2 过期库清理

主要针对长期未续租公司数据库清理和体验库清理。

长期未续租公司数据库清理：当前采用人工确认手动清理的模式，主要是删库动作非常敏感，一般会由实施人员跟客户确认后才执行，且删库过程也是将其先备份到存储型机器上再删除，这样保存的代价也只是存储成本。

图5. 长期未续租公司数据库清理流程

体验库清理：相对来说简单一些，采用自动清理的机制，因为体验库生命周期比较短，而且不会有真实数据，但我们还是采用标准的删除过程如下：

图6. 体验库清理流程

软删除：该阶段将公司状态置为逻辑删除状态，禁止公司登录访问，该状态会同步到Saas系统的所有服务上；
重命名： 将公司数据库重命名，该阶段如果客户续租可以快速将公司上线(主要针对非体验库)，另外还能发现一些不规范服务并及时加以改造，因为整个SaaS经十年多的发展系统中不乏一些很老的服务的调度任务没有通过正确途径同步公司下线状态而继续在访问数据库，这也是重命名阶段存在的意义；
硬删除： 将重命名后的库直接删除，将公司状态置为硬删除状态，此操作对体验库是不可恢复的。

该流程其实完全可以应用到正常到期公司库的清理流程，只需在硬删除阶段加入备份机制，并将各个阶段执行间隔调整到合理范围，这也是我们下阶段准备去做的。

4.3 数据库监控

SaaS系统上有上万家公司，意味着几万个数据库、上百个数据库集群，如何进行统一监控和信息管理也是一大挑战。集团的数据库管理平台CDB只支持在集群维度的管理，这在数据库本身管理上没有任何问题，但针对SaaS系统来说缺乏一个全局视图，因此我们基于CDB的开放能力上搭建了一套专用于SaaS公司数据库的监控系统，提供针对SaaS数据库的统一的视图，目前系统具备的一些基本能力和框架如下图：

图7. 巧房SaaS数据库系统架构图

集群负载监控视图

图8. 集群负载监控视图

系统部分功能界面

图9. 系统部分功能界面

多分区服务设计

巧房SaaS的线下环境跟正常软件开发环境使用定义基本一致，线上环境有所不同，分为BETA、灰度、全量三套环境，我们习惯称之为分区，各个分区会分配独立的服务分组(也可以理解成不同的集群)、归属公司, 同时也分配了三套不同的域名，三个分区的服务版本在平时版本保持一致，只是服务版本升级过程中会存在不一致的情况，其采用技术架构如下图：

图10. 巧房SaaS技术架构图

从上图可以看出，支持多分区服务模式的核心组件是全局路由，他能根据公司所在的分区转发到对应的分区域名上。这个架构其实是单IDC多集群(服务在各个分区是一套独立的集群)的架构，由于各个集群之间在接入层就通过域名做了隔离，在这个基础上比较容易演变支持多IDC的架构。下面介绍下各个分区的用途。

BETA分区：服务发布正式环境之前的验证环境，软件版本在正式发布生产之前，会打包服务正式版本发布到该分区，随之还需将当次版本对应的库表变更发布到该分区对应的公司库上，这样能在该分区验证时发现并修正服务版本及库表数据变更脚本存在的问题。
正式环境分区：包含灰度分区、全量分区, 灰度分区只包含一些体量小的公司，其他公司都分布在全量分区，下面重点说下灰度分区的由来。

巧房SaaS因为要满足不同经纪公司的业务诉求，因而是一个支持功能定制化非常高的系统，这也导致某些功能点在特殊的场景或流程在线下或者BETA环境很难被触发而漏了验证，然后发布到生产一旦出现问题，就可能影响上万家公司的正常作业，因此我们就想是否能先让小范围客户试用一下本次升级的版本，灰度分区环境应运而生。

我们将某些体量比较小的公司或者自营司切换到该分区，每次发版在BETA分区验证通过之后，将要升级的版本发布到该分区，版本会在该分区停留两天供该分区上的客户公司员工使用，在此期间如果有反馈问题我们可以及时修正此次发布版本，两天后我们才将修正后的版本发布到全量分区，实践证明这种服务分区策略发挥着不小的作用，是极其正确的。

当然，这套环境下我们需要支持对公司所属分区的进行调整，以便将公司在灰度分区和全量分区之间灵活切换，同时升级时对数据库表的变更也需支持按分区发布，这个能力是由数据库管理系统DMS提供的。

开库系统设计

主要介绍客户跟巧房签约之后，如何帮客户在SaaS系统上开设租户、创建和初始化公司系统，这里介绍模板化定制公司和公司开库择库策略的一些设计。

5.1 公司定制模板化

巧房SaaS系统对新租户(公司)的系统的定制很大程度是通过公司模板实现的。

我们按公司类型、规模等维度事先创建一批模板公司，并由运营人员对这些模板公司进行配置，对功能、业务流程等进行定制和初始化。

实施人员在给客户开通系统的时候就可以通过页面选择的条件自动匹配到对应的模板公司，后台以对应模板公司的数据库复制成客户的公司库，这样就完成了新公司系统的开通，大概的流程如下：

图11. 新公司系统开通流程

5.2 公司选库策略

巧房SaaS采用多实例多租户模式数据库架构，每给客户新开通一家公司就需在某个数据库集群上去创建该公司对应的数据库，如果该集群剩余资源不足就需要新建一套集群再在上面创建库，这个是最早我们采用的方式，这种方式存在的弊端是：

评估集群资源利用率难：集群当前负载水平只是在短时间内的状态，会随集群上的公司续租/退租、业务发展、系统使用情况等的变化而改变；
集群资源利用率不均衡：新建集群资源刚开始肯定是最空闲的，最早创建的集群很可能是最忙的；

因此我们设计了一套自动选库(选集群)的流程，把所有数据库集群到放到一个候选池，当有新的公司需要建库，就会筛选候选池中剩余配额(端口数)满足新公司购买端口数且资源占用最低的N个中再随机选定一个集群在上面建库，如果不足N个则需新申请一套集群并加入候选池后再进行，这里有两个有意思的点：

怎么评估集群资源的占用：我们使用的是集群上的所有公司库的对应公司的购买端口总数来评估。类比使用云上ECS一样，平台是根据购买的资源规格计费，同时分配给你对应的配额，至于你购买后使用情况他其实不需要关注。同理，我们也是按端口数来评估给公司创建的数据库的资源占用情况；
最低N个里面随机一个而非最低一个：假设总是在最低的那套集群上去建库，可以想象这会发展成跟最早采用的方式一样，新集群总是很空闲，运行的都是新建的公司库，如果是N个就会在这N个之间均衡。

具体的选库流程比上面描述的要复杂，选库参考的维度除端口数还包含集群类型、状态、总端口数阈值、公司数阈值等。

图12. 选库流程

总结与展望

本文探讨了巧房SaaS系统在房产中介业务中的针对租户数据治理一些实践和创新，展望未来，巧房SaaS系统将继续优化和升级，以适应不断变化的市场需求。通过技术创新，巧房SaaS系统将为房产中介业务提供更加智能化、自动化的服务，帮助房产中介公司更高效地管理业务，提供更加精准和便捷的服务。我们期待业内同行的批判指正和互相交流切磋，共同推动房产中介行业的数字化转型和升级。

本文分享自微信公众号 - 58技术（architects_58）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

表1. 数据库架构模式