典型场景 | PolarDB-X 如何支撑 SaaS 多租户

SaaS多租户背景

很多平台类应用或系统（如电商CRM平台、仓库订单平台等等），它们的服务模型是围绕用户维度（这里的用户维度可以是一个卖家或品牌，可以是一个仓库，等等）展开的。因此，这类型的平台业务，为了支持业务系统的水平扩展性，业务的数据库通常是按用户维度进行水平切分。 可是，当平台类应用的一些用户慢慢成长为大用户（比如大品牌、大卖家、大仓库等）后，这些大用户由于其数据量或流量明显要比其它用户多得多，容易导致以下的现象

• 大用户所在分片会成为业务系统的热点，占用大量的数据库资源，其服务质量容易因资源受限导致不稳定；
• 其它小用户容易受到大用户资源消耗的影响，服务质量也受到影响。

最后就整个平台的业务系统的热点频现，数据库访问不稳定，业务服务受影响。 SaaS多租户模型作为一种应用的架构，常用来解决业务的上述问题。在SaaS多租户模型中，业务系统会需要服务多个用户，每个用户（或每批用户）可以被视为一个租户。 这些不同的租户在业务系统内会使用共同的基础设施及其平台进行运行，但来自不同租户的数据仍将被独立隔离，因此，通常租户拥有自己物理资源来单独存储与管理数据。所以，SaaS多租户解决业务系统稳定性问题以及租户资源弹性定制的核心思路，就是租户间的资源隔离及数据隔离。 在实际的不同应用场景下，常见的 SaaS 多租户方案有两种：

Schema 级 SaaS 多租户

• Schema 级 SaaS 多租户，是指一个租户对应一个包含多个Table定义的Schema（或一个Database，在MySQL, Schema概念等同Database）, 不同租户的Schema会分布在不同的机器上（如下图1所示），实现资源隔离，该方案适用于不同租户需要使用独立Schema运行的场景；

Partition 级 SaaS 多租户

• Partition 级 SaaS 多租户，是指一个租户会对应一个Table的一个或多个的分区（或是一个Table的一部分 rows)，不同租户的Parittion会分布在不同的机器上（如上图2所示），以实现资源隔离，该方案比较适用于不同租户需要使用统一Schema运行的场景。

从隔离程度来看， Schema 级 SaaS 多租户比 Partition 级 SaaS 多租户要隔离得更彻底，但前者因为要维护众多的Schema，会比后者会带来更高的运维成本及查询分析成本。 不过，Partition 级 SaaS 多租户通常要依赖中间件分库分表或分布式数据库分区功能（不然单机数据库无法做到资源隔离）才能运作，而Schema 级 SaaS 多租户则不需要，用户自己搭建几个单机MySQL也可以运作起来，准入门槛更低。

业务的问题

业务多租户场景

只说应用架构可能有些抽象，为了方便读者更容易地理解 SaaS 多租户是如何帮助业务解决问题， 本文将以一个真实的案例来进行阐述。 正马软件的班牛平台是国内领先的提供电商全周期客户服务的卖家订单管理平台（以下简称B公司）。它的业务系统需要维护多个不同品牌的众多卖家。通常一个品牌会有多个卖家（比如，一个品牌可能会开通多个线上店铺），所以，品牌与卖家是一对多的关系。 目前，B公司的订单管理平台管理着超过50T的订单数据，日QPS 近 3W+，不同品牌的订单量差异会比较大（大品牌的订单可能是小品牌的订单量的近百倍或更高）。 一些大品牌除了订单量比其它品牌的大很多之外，还会使用更高级的付费VIP服务：比如，要求订单数据独占资源与数据隔离、允许独立地统计分析自己品牌的订单数据等。 B公司为了解决不同品牌的数据的资源使用及其服务差异，就会对它的卖家按品牌划分（相当于一个品牌是一个租户）：

• 大品牌诉求：
  • 订单量大（比如，订单数据存储的大小超过 1T 或 2T ），数据存储量大
  • 独占一组的存储资源、有独立访问分析数据的需求
  • 该品牌的所有商家都必须同一组的存储资源
  • 大品牌的大卖家150+，后边还会陆续增加
• 小品牌诉求：
  • 订单表小，商家数目大（6W+卖家）
  • 共用一组存储资源
  • 要求所有卖家数据在存储上均衡分布

现在的核心问题是，B公司的订单管理平台的数据库应该如何设计，才能满足上述众多不同品牌及其大卖家对于不同资源使用与数据隔离的诉求？