在SaaS产品平台，本质上是多租户订阅使用的服务模式，因此在技术架构实现层面，需要对不同租户的数据库存储（甚至包括文件存放）进行隔离和划分。那具体怎么设计，既能满足前期快速MVP版本迭代，又能符合未来更多客户、更多海量数据增长而不是系统崩溃卡顿呢？
从2017年研发果创云PaaS低代码接口开发平台开始，在对不同开发者、不同应用、不同服务客户的数据，我们已经有一套很完善的数据存储、数据库变更、数据迁移、数据清理和释放体系。所以，在经历从几个开发者用户到几万个开发者用户，从一开始几十张表到现在十几万张表和几十万个表字段，乃至从最初几百条数据到现在已经在过亿条数据存储，我们PaaS平台都做到了很低的维护、很高效的交付速度和极高的API响应速度（平均在100ms以内）。
当然，SaaS产品和PaaS平台，又有些区别。SaaS产品更多是面向直接的使用用户、不懂技术的用户、直接开通账号，然后按订阅的方式就可以使用产品功能，解决他们在特定业务场景的软件需求，例如：招聘、项目管理、ERP、客户管理、营销推广等。
下面，结合过往我们在PaaS平台以及目前正在设计的YesDev SaaS研发协同工具产品，一起来给技术负责人、老板介绍一下，怎么设计SaaS数据库才不会掉坑。
一、SaaS数据库设计是什么？
简单来说，SaaS数据库设计是由技术人员实现的具体存储方案。
但如果作为老板或者技术负责人，没有规范好和提前了解清楚技术实现的思路和方案，到后期发现有不合理再去调整就会成本非常大。
对于SaaS数据库的设计，核心就是要区分好每个租户、每个团队、每个用户的数据。在数据库技术层面的体现就是在数据库、数据库表、数据库表字体上的设计和实现。
站在SaaS平台的角度去俯视，就是要把每个租户的数据清晰划分出来，做到“高内聚、低耦合”。每个租户的数据，要高内聚，放在一起；另一方面，平台又要能容易看到汇总后的各个维度的全部租户数据。
二、SaaS数据库隔离有哪几种策略？
SaaS数据库隔离有三种，从粗到细，分别是：
- 1、【粗】物理存储隔离方式：按整个数据库进行隔离
- 2、【中】技术存储隔离方式：通过表前缀区分隔离
- 3、【细】业务存储隔离方式：通过表字段划分租户数据
- 4、【混合】混合的隔离方式
下面分别介绍，再来对比，看哪种方式更合适。
1、【粗】物理存储隔离方式：按整个数据库进行隔离
简单、粗暴、直接的方式，就是给每个开通的租户都分别创建一个数据库，单独隔离。
好处是：对于技术实现相对简单，只要在用户访问时，进行数据库的绑定和切换就可以了。数据迁移、导入导出方便。
不足是：需要给每个新租户动态创建一个数据库，并且后续随着产品版本迭代要变更追加新的数据库表很复杂、很麻烦。
2、【中】技术存储隔离方式：通过表前缀区分隔离
第2种折中的方式是，按年份月份或服务的区域进行数据库划分，然后再针对每个不同的租户通过表前缀的方式进行划分。
好处是：有同一个数据库中，可以集中进行管理和维护。
不足是：针对每个新开通的租户，依然要动态创建一系列的系统基础数据库表；后续有数据库变更，也要批量进行变更和调整。
3、【细】业务存储隔离方式：通过表字段划分租户数据
第3种就是在业务层面，通过表字段来进行区分。例如有一个app_key表示不同的企业、不同的团队、不同的客户。
好处是：数据库表结构可以只维护一份。
不足是：数据量大时会容易产生慢查询，后续客户需要迁移到私服环境，数据拆分和清理需要更多的处理工作。
4、【混合】混合的隔离方式
第4种混合模式，适用于区分存储平台数据和客户数据。尤其是当你的SaaS产品允许用户动态自定义字段时，就更加需要采用混合的隔离方式。一方面，把平台的系统表、基础表、全局数据、平台自主的数据，进行集中管理。另一方面，针对用户自定义添加的字段，进行单独隔离存储。
三、SaaS数据库要考虑哪些技术的坑？
如前面有介绍，SaaS产品的升级迭代和服务是一个动态的过程，所以在最初构建数据库存储方案时，就要结合现有的客户以及未来的服务模式进行设计。不然，一旦成形，再来调整，就不是三天两头的事，而是伤筋动骨的大重构了。
你要考虑到SaaS客户会转移迁移到私有部署环境的数据迁移问题；你要做好底层的数据库表设计，不然技术后面就整天和你说“以前这样的数据库设计根本就不合理，现在想要扩展添加新功能，根本做不了，除非重构！”。
还要结合到具体开发的编程语言和后端技术栈，要能很好满足API接口开发、功能开发、管理后台报表查询汇总统计、定时任务、脚本工具等的配套落地开发。
原则1：尽早使用配置文件来显式维护租户的数据库存储策略
例如PHP开发语言的PhalApi开源接口框架，就可以直接通过数据库路由配置表，实现分库分表的配置。
return array( 'tables' => array( 'demo' => array( // 表名，不带表前缀，不带分表后缀 'prefix' => '', // 当前的表名前缀 'key' => 'id', // 当前的表主键名 'map' => array( // 当前的分表存储路由配置 array('db' => 'db_master'), // 单表配置：array('db' => 服务器标记) array('start' => 0, 'end' => 2, 'db' => 'db_master'), // 三张分表的配置：array('start' => 开始下标, 'end' => 结束下标, 'db' => 服务器标记) ), ), ), );
可以灵活配置数据库路由，支持分库分表，也可以支持表前缀的配置，当然也是可以支持整个数据库的切换。
数据库分库分表策略 - PhalApi 2.x 开源接口框架 开发文档 http://docs.phalapi.net/#/v2.0/database-multi
原则2：尽早封装统一的领域数据基类
每次只处理一个租户的数据，并且通过全局唯一的标识来区分不同的租户。在代码实现和UML建模时，尽量抽取和通用业务相关的字段和数据库表基类，支持租户身份的灵活切换。
尤其是在ERP、CRM、项目管理这类的系统管理工具中，尽量封装好数据库基类，减少代码的开发量和善用代码自动生成技术，可以极大提升系统的优雅性和强大性。
参考PhalApi框架推出的DataModel是比NotORMModel更新推出的数据基类，比NotORMModel功能更强大，并且开发使用更友好。
原则3：支持租户身份的灵活切换
不同的租户是有不同的数据存储位置，那么平台方在处理不同租户数据时，就要能快速进行切换。包括：代码层面的切换和鉴权、API接口和页面访问的横向鉴权、计划任务和MQ和异步通知的区分、脚本命令工具的手动指定等。
可以参考领域驱动设计的模型，从外到内，都要始终能区分租户的数据。
原则4：尽早统一维护SaaS系统的数据库完整变更记录
SaaS平台，难免会同时存在多个不同的环境，除了自己使用的开发环境、测试环境、正式环境；站在商用系统的交付维度，也会有多态环境，譬如：演示环境、正式SaaS环境、不同客户的私有部署环境、定制开发的环境、渠道版。
既然有那么多不同的环境，又有多种不同的数据存储策略，那么两者一结合，那就是乘数倍级的复杂度！
曾经就有位SaaS老板和我们说，“哎！现在很痛苦！明明昨天在开发环境还是好好的，今天在正式环境给客户一演示汇报就打不开了！！”。
后来一问，发现既没有预发布环境，又没有完整的数据库变更记录。很多时候代码发布到正式环境了，要么就是表字段忘加了，要么就是表忘建了。
多么初级和错误啊！
原则5：尽早统一业务数据语义
不同的业务字段，不同的值，在行业有不同的称呼，在不同的客户内部也有不同的理解。需要尽量针对SaaS场景服务的行业和目标客户对象，明确好每个业务字段的数据语义。
在内部、在研发团队、在外部宣传和客户沟通过程中，统一通用语言。
四、总结
经验总结，就是：设计简单、调整很难。
在前期设计良好很简单，但如果一开始设计混乱，到SaaS产品发展中后期再来调整，就会成本很高、难度很大、而且很多技术人员都不喜欢维护这些烂摊子。客户也不会给内部的数据迁移、系统重构来埋单。最后痛苦的就是做SaaS产品的创业者老板。
专栏作者
黄禅宗 dogstar，果创科技创始人，YesApi果创云亿级流量PaaS平台创始人、YesDev研发协同SaaS创始人； 前唯品会高级开发工程师，千万级架构经验； 前MobVista高级工程师、前租租车技术经理； 10年以上互联网经验，对软件领域有独特见解；PhalApi开源框架作者，著有《良质!》等电子书；退役士兵，华南师范大学软件工程专业，喜欢交流分享。
