从业务数据库到元数据,SaaS 架构设计经验全总结

未来社会模型中 SaaS 的位置与分量

上图是一个从连接这个透视角度抽象出来的社会模型，其中的家庭、人、组织、物都是相互连接的，它也是一个从软件架构抽象出来的社会模型。SaaS 是对软件的获得和使用方式的革命，早在 2004 年就已有端倪（当时称为 ASP，Application Service Provider）。笔者认为，可以将 SaaS 放在社会运行机制、发展趋势这样的大格局中定位其社会作用。SaaS 企业也需要这样的格局与信念，虽然在中国还没有出现非常成功的 SaaS 企业，但终究会出现的，信任、习惯、规范、与能力都需要进化，需要时间。

在没有电之前，人们就有传递信息的需求，这也是为什么微信能够存在的本质根由。同理，各种组织都离不开软件，而且软件的渗透越来越广泛与深入，因为整个世界的数字化是不可阻挡的趋势。而 SaaS 在大部分情况下是必选之路，会越来越成为标配，除非特殊原因，或者不在乎成本、或者已经拥有某种等效的软件、或者其他原因。只要这种本质性的需求存在着，社会的发展终究会以越来越先进的方式来满足它。

这里分享一个关于云的小故事，笔者曾经算过一笔账，如果在云上订购托管机房中约 500 台机器的同等算力，每年需要支出 5000 万，相当有悖于流行认知，其实对于稍微有些规模的 IT 资源诉求，云相对是更加昂贵的，但来的快、方便，两方面都是事实。

这里只想传递一个观点，长远来看，SaaS 有它存在与发展的必然性。结构上讲，它是社会运行机制中不可或缺的一部分。同样或者类似的软件，显然没有必要每个人、每个组织都各买一套或各自开发一套，这是社会资源的极大浪费，有悖于社会发展的基本规律——既然是必需的，必然选择物美价廉。而且组织支出比个人支出更理性、更注重实用价值，有利可图的需求终究会达到稳态的、某种主流服务的满足。

从架构角度看 SaaS 面临的挑战

如果说 SaaS 在大部分情况下将会成为必选之路，那么它面临的最大挑战又是什么呢？概括来讲，SaaS 面临的最大挑战是满足客户的个性化需求。从架构角度看，它体现在如下图所示的几个方面：

其中最有挑战性的又要属多变的后台逻辑与数据模型。对于 SaaS 供应商而言，这种需求显然不能通过项目的方式来定制满足，而只有通过提供灵活的自服务平台才能满足，这种灵活性就需要用 PaaS 来生产客户想要的软件。这一点笔者在2013 年做一个 SaaS 项目的架构工作时就深有体会：一开始的目标也是做 SaaS，但是后来还是走上了 PaaS 的道路，不过是专为生产 SaaS 而自用的 PaaS，而不是定位于 PaaS 供应商。

如果一个 SaaS 企业从一开始就只是聚焦某个业务，而没有着手 PaaS 的建设，那说明它在满足个性化需求的道路上一定是在某个局部、某个层面解决问题，而不是系统、全面、可复用地解决问题。同时，从中国 SaaS 市场现状来看，它的成长比较慢，环境的综合成熟度还不够高，聚焦单一业务成长的加速度不够，因此企业后续很可能会从最开始聚焦的核心业务向外扩展，到时候又要面临种种个性化需求问题。因此，一个成功的 SaaS 企业必然要去寻求 PaaS 的支撑。从这两个意义上讲，PaaS 可能也是 SaaS 企业提高生产力的必经方向。据有关数据

表明，在企业弃用 SaaS 的原因中，无法满足个性化需求占了 23%，可见 PaaS 的支撑多么重要。

如何做好 SaaS 架构？

1 业务数据库

SaaS，特别是 To B 的时候，业务数据库必然是存储的核心，这里笔者针对业务数据库总结了一些架构层面的建议。

建议一：对于任何 mission critical 的场景都要使用 RDBMS

企业应用与 To C 的使用场景有一个明显的区别是，绝大部分情况下，它对正确性、准确性的要求更高，而且 SaaS 提供方需要对此承担相应的责任。因此，支撑一线黄金业务流程的数据库目前来看还是得使用关系型数据库。目前来看有两个开源可选项，分别是 MySQL 和 PostgreSQL。

建议二：分库

支持多租户可以有多种方式，这里所说的分库并不是指每个租户一个独立的库（当然产品销售时可以作为套餐的一个选项），而是指多个数据库实例，每个实例包含多个租户的完整数据。

说到多租户，需要提个醒，通常大家都会想当然地认为租户之间是隔离的，但是事情都有另一面，对于大集团客户，在某些业务上，它的分公司、子集团之间可能还是有连接的。另外，人员组织机构建模上，也要考虑一个人任职多个子集团或公司的可能。

建议三：Partitioning

即使是一个数据库实例，也可以再继续分区，MySQL 和 PostgreSQL（至少版本 11 以上）都支持在一个实例内部分区。对租户进行 Partitioning 可以在一定程度上提高性能，因为把一个查询限制在更小的数据范围内进行，而非全量数据空间，效率自然会更高。

建议四：元数据驱动，Salesforce 不是标杆

一个民族、一个国家如果没有非权威精神，是不会有根本性创新的。动则大厂是如何做的，好像大厂总是做的最好的，那是不行的，盲目崇拜只能是 follower，不可能是 creator，当然也不能盲目忽视，最要紧的是把业务架构搞清楚、明确定义到底要什么。心里要有谱，但是技术本身绝对不是谱，而仅仅是可选的手段。

以下是根据 Salesforce官网资料整理的的核心数据模型：

其业务数据表本身是没有物理索引的，真正的索引主要在MT_Indexes 中，但是这有点让人困惑，为什么不在MT_Data 上直接建立物理索引呢？难道列和索引太多了会影响性能？而反范式地单独以列的方式、按数据类型建立很少的索引就好？为此，笔者动手做了验证。

1）实验条件

为了聚焦在问题本身，图 3 中只采用了绿色的两张表，而省略了红色的字段，本实验所使用的字段名和图 3 不一样，但是思路是一样的。

OS，Windows 10；

DB，MySQL 5.7；

两张业务表，有物理索引的 =bizdata，没有物理索引的 =bizdata2，结构如下：

bizdata 和 bizdata2 都灌入了 10 万条数据，字符型长度为 4，它的值基于给定的一个长度为 10 的字符串随机生成，数值型的则为 100 以内的随机数；