企业级SaaS的多租户设计_多租户设计架构

 

 

导读

      现有企业级SaaS市场在每个细分领域都涌现出了一批玩家，从技术角度看，在不同的领域不同的SaaS产品必定有着同样的架构内核，其中最关键的就是多租户的支持。简而言之，SaaS的成熟度高低，很大程度取决于如何实现多租户模式的支持。

 

多租户技术的核心关注点

 

多租户在技术实现层面目前并没有既定的规范，不仅细节多，每处细节的实现方式也多种多样。

 

如何落地，一方面取决于当前研发团队现有的技术储备、技术选型、团队资本实力、所处行业或客户特点（比如金融行业对数据安全会有更高要求），另一方面也与当前的技术发展息息相关，云厂商的崛起和云原生时代的到来，也深刻影响着包括SaaS在内的软件构建的方法。

但常规来说，真正的SaaS应用往往需要满足以下两点：

• 单实例

• 多租户

单实例意味着系统资源层面的共享，多租户意味着应用逻辑层面的隔离。所以如何平衡好这两点，才是SaaS应用多租户设计的核心关注点。

 

经典的分布式服务架构天然解决了互联网应用的三高问题（高并发、高性能、高可用），这也是企业SaaS发展中后期即将面临的问题，下面我们来分析下如何在该架构下去设计与实现多租户SaaS应用。

 

多租户的实现

 

从资源共享的层面看，从share nothing到share everything，在天平的任何一个点上都可以支撑多租户。

 

但正如我们前文所说，SaaS架构首要考虑的目标便是单实例，只有单实例才能将成本尽可能降低，产品才会有规模效应。所以所谓共享和隔离，在经典架构下又会聚焦为一点，即如何对不同租户进行资源层面的隔离。

 

 

关于资源

 

谈到资源，我们可能会想到CPU、内存、磁盘、网络带宽等，但如此多类型的资源，从其特征上又可以归为两类，即存储资源和计算资源。

 

换句话说，SaaS系统在技术本质上也可以认为就是分布式存储和分布式计算的融合。

 

在多租户的实现中，往往更关键的是对于存储资源的处理，计算资源一般只在必要情况下才会考虑，我认为这主要是和存储的“有状态性”有关。下面我们以一些典型场景为例，具体分析一下多租户的设计该如何着手。

 

 

存储资源的隔离

 

隔离存储资源概括来说可以用一个词来解决：命名空间。以数据库为例，我们只需要在每条租户的记录上，记下对应租户的标识即可。

 

一般来说，不考虑分库分表的情况下，我们逻辑上会在同一个Schema中，存储所有租户的数据。这就要求每张表都会有一个tenant_id字段，也即每条记录都携带了它的“命名空间”——租户标识。

 

 

再以常用的NoSQL方案Redis为例，一般来说也是在同一个分布式集群中存储所有租户数据，那么很明显在key上携带租户标识即可。

 

所以无论何种存储，思路都是相通的，而且处理起来相对简单粗暴。但这里我想着重强调的是，在工程层面我们应当将这种约定在底层框架里做统一处理。

 

比如在租户上下文中的所有SQL语句，应当都要携带where tenant_id=?这个条件，才能保证逻辑正确，我们很难想象在代码从零到十万、百万行的过程中，所有人都自始至终都牢记这个规则。

 

那么类似场景下，我们就可以通过AOP技术将多租户相关的逻辑切出来进行统一处理，比如在Java中，我们可以定义@TenantContextAware注解，以声明而非编码的方式在需要的地方做对应的租户信息获取及传递处理。

 

那么又如何保证开发者也牢记这个规则呢，由于多租户是SaaS的天然属性，我们可以反其道而行之，默认支持多租户逻辑，同时定义@TenantContextUnaware注解，在不需要多租户的地方进行例外声明，这就大大降低了开发团队的负担。

 

同理，类似Redis Key的维护，也建议定义统一的KeyGeneratePolicy来维护。

 

计算资源的隔离

 

隔离计算资源的方法也可以用一个词来概括，那就是亲和性，简单来说就是租户与集群计算资源的亲和性设计。

 

计算与存储除了“状态”方面的差异外，还有一个非常重要的区别，计算的财务成本往往远高于存储，比如我们一台虚拟主机上可能只允许数百个线程同时处理请求。

 

正因为如此，宝贵的计算资源在非必要的情况下一般不会再进行细粒度的隔离，例如我们一般不会在运行时只允许某租户的请求只提交给指定工作线程处理。

 

另外一方面，计算资源发生倾斜的后果，往往比存储要严重的多，如同木桶效应般，直接且显著地影响整个集群的服务能力。

 

但特定场景下较粗粒度的隔离，有时候还是非常必要的。比如为了减少系统故障时租户的影响范围，我们可能会将租户的请求哈希后提交给不同的线程池处理，因为这种情况下，反压将会产生全局的影响。

 

另外我们也可能在特定场景下进行进程、集群层面的隔离。总的来说，对计算资源进行隔离，没有既定的模式与套路，而且往往需要高超的资源操作水平，一般不到万不得已不建议实施。

 

同样地，如果一定要实施，那么也应当以组件化的方式进行，保证业务逻辑的纯粹性。

 

通过上述对存储和计算资源的隔离处理，我们的SaaS架构整体看起来将会是下图这个结构。

 

 

 

在这里用一个表格就一些要点对两种手段做个简单的对比，便于大家更直观地理解↓

 

 

单实例架构的扩展

 

面向企业的SaaS服务往往还有一些特点可能会引出一些高阶需求，而独立的单实例架构有时候并不能完全满足这些高阶需求。

 

此时就需要对原有架构进行扩展，以实例级别的整体隔离，配合租户级的请求分流手段，为SaaS带来资源、软件版本等多方面的隔离。

 

但需要注意的是，对单实例架构的扩展，并没有降低其架构成熟度，与我们文中一直在强调的单实例架构理念并不冲突。

 

比如我们往往会根据企业客户的规模和特点对其保障等级进行分级，那如何进一步合理地隔离资源，保障不同级别客户的使用体验，也是一个无法逃避的问题。

 

这种情况下，我们就可以考虑将这类客户的某些资源实施特殊的保护性隔离，或者干脆将单实例架构扩展成为多实例架构，将客户分流到不同保障级别的资源池。

 

如果有个别客户体量远超其他客户，那么在成本允许的情况下，我们甚至可以考虑为其建设专属资源池，对其进行重点保障，这种级别的保护并不意味着牺牲了小体量客户的体验，相反，往往大体量客户才更容易发生一些影响稳定性的突发事件，所以可以认为是一种多赢的操作。

 

另外，SaaS往往能给客户带来更快的特性交付，但这种快速交付很可能带来不佳的使用体验，比如严重BUG的存在。

 

那么这个时候，如果我们的系统是多实例架构，那么就可以很轻易地实现灰度发布，从而使得特性交付的过程更加稳健，也是对品牌形象的一种保护。

总结

 

在实际开发中，我们往往容易忽视早期对类似多租户等基础层面的系统性规划与设计，导致后期研发、维护成本持续增加，甚至在面临一些新的商业机会的时候，无法灵活应对。

 

好的架构则能将这些本质的特征透明化，做到业务层无感，从而提高研发效率。

 

在企业SaaS的多租户架构设计环节，我们无法罗列或预判所有可能，在不同的技术选型下的多租户实现也有很大差异，我们应当着重去发掘其技术本质，从计算与存储资源的隔离层面，系统地规划与架构，做好基础组件的建设与沉淀。

 

只有抛开现象去归纳总结相关本质方法，才能以不变应万变。

 

关于作者

张晋。网易智慧企业架构师，负责旗下多款SaaS产品的架构、基础设施建设等相关工作，有丰富的C端、B端产品研发经验。目前主要关注企业级产品的技术架构、研发管理等方面。