对于 SaaS 产品多租户设计，某些和平台相关的业务数据到底该放在平台侧还是租户侧才是最合适最稳妥的呢？这篇文章，我们来看看：

前天在 SaaS 架构设计交流群有群友提出来一个问题，他们的 SaaS 平台有一个对所有商户开放的门户，门户中有一个商品中心模块，这个模块允许所有商户发布商品，并且发布的商品允许其他商户查看。同时允许商户自己在商品中心订购商品，他纠结的是这里涉及两部分数据，一部分数据是商户私有的订购数据，一部分是平台所有商户共享的商品数据，这两部分数据要不要做租户间的隔离？

对于 SaaS 产品多租户设计，确实会经常遇到如何界定数据边界的问题，典型的案例是做数据库隔离设计的方案中（即每个租户独享一个数据库，参考：讲讲 SaaS 平台的多租户设计），某些和平台相关的业务数据到底该放在平台侧还是租户侧。本篇分享一下个人对这种多租户设计的数据边界的个人理解。

一、基本原则

先说一个基本原则，这个也应该是 SaaS 产品划分数据边界的首要原则，那就是“以不影响租户业务运行为首要原则”。听起来比较难理解，我们来看一般 SaaS 产品的数据和应用支撑形式。

如上图所示，通常 SaaS 产品会分为租户应用和平台侧应用，其中租户应用也就是租户日常使用的各类业务应用，平台侧应用主要是给 SaaS 企业自己运营使用。平台侧应用通常只会使用平台数据，如果需要租户数据（比如对租户的日常使用进行埋点分析）也应该是将这些数据放到平台侧来存储。租户应用则主要是使用租户自有的数据库，但是也有可能会使用部分平台数据，比如一些整个平台通用的数据（例如字典数据）。

这里平台数据通常会是单独的数据库服务器存储，这就会产生一个问题，如果平台数据库服务器出现故障，就有可能导致租户的业务受影响。因此，我们应当尽可能降低这种风险，而降低这种风险最有效的手段就是尽量让租户应用少依赖平台数据，甚至是不依赖。

二、实际案例

我们来看一个具体的案例，在涉及在线支付的业务中（例如电商 SaaS，商户可以在线销售商品给 C 端用户），每个租户都会有自己支付参数（如支付渠道、商户号、密钥等等）。系统自然会对接多家支付渠道，因此会有一个支付中心（技术上叫支付网关，参考：接一个第三方支付，开发说要2个月？）。在租户支付的时候，从简化支付中心设计来说，可以将每个租户的支付参数存储在平台数据中，这样就不需要分租户从不同的数据库读取支付参数。然而，这里有个问题，就是如果平台数据库出现问题，意味着整个 SaaS 平台的所有租户的在线支付业务都会受影响。这种事情出现的概率虽然低，但是只要出现一次都会造成无法挽回的损失 —— 大家可以想象一下，假设支付宝出现故障，会给淘宝的交易额带来多大的损失。

所以说，虽然我们说要追求简洁的设计、降低成本，但是也要考虑风险，尤其是那种可能导致所有租户业务受阻的重大风险。这也是我之前在一篇文章中说过的，SaaS 产品要追求稳定性。

那么像上面这种情况怎么处理呢？我们说“不要将所有鸡蛋放到1个篮子里”，这个原则对于 SaaS 产品同样适用。我们可以将这些支付参数分别放到租户数据中，虽然支付中心的设计开发变得复杂了，但是单个租户数据库出现问题只会影响该租户自身，而不会影响其他租户。这样的话，实际上就是将大的风险给分化了，可以降低整个 SaaS 平台的风险，提高稳定性。

三、如何划分数据边界

通过前面讲的原则和例子，我们在具体设计 SaaS产品数据层的时候，就可以判断该如何划分数据边界了。当数据可放在租户侧也可放在平台侧的时候，我们要考虑是响应数据库出现故障的风险，选择风险低、出故障后影响面小的方案。

再回到开篇讲的问题，实际上这个问题和数据隔离并没有太大关系，因为商品中心和商户订购数据（即订单）本质上其实是平台为租户提供的撮合交易服务。这种情况下，平台其实就类似闲鱼，而商户就是闲鱼的用户。闲鱼的用户发布的商品数据自然是统一放到平台侧的，这样平台才方便对所有其他用户展示和筛选。对于用户自己购买的商品订单，平台开放订单管理功能供用户查看即可。

这个问题里，实际上要搞清楚的是两个问题：平台商户能查看哪些数据？能管理哪些数据？比如商品中心的数据允许所有商户查看，比如商家自己发布的商品允许管理（编辑、上下架、删除等），比如可以管理自己的订单（取消、支付、评价等）。

四、总结

SaaS 产品因为是服务于企业客户，也就意味着我们平台上面的企业的日常业务运转依赖于我们的产品。一旦我们的产品出现了问题，有可能大面积地影响到客户的业务运转。因此，追求产品稳定运行是 SaaS 产品应该优先追求的目标。对于数据边界的划分，同样也应该遵循追求稳定、降低风险的原则。