企业级SaaS的多租户设计

导读
      现有企业级SaaS市场在每个细分领域都涌现出了一批玩家，从技术角度看，在不同的领域不同的SaaS产品必定有着同样的架构内核，其中最关键的就是多租户的支持。简而言之，SaaS的成熟度上下，很大水平取决于如何实现多租户形式的支持。
多租户技术的核心关注点
多租户在技术实现层面目前并没有既定的规范，不只细节多，每处细节的实现方式也多种多样。
如何落地，一方面取决于当前研发团队现有的技术贮藏、技术选型、团队资本实力、所处行业或客户特点（比如金融行业对数据安全会有更高要求），另一方面也与当前的技术开展息息相关，云厂商的崛起和云原生时代的到来，也深化影响着包括SaaS在内的软件构建的方法。

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

单实例
多租户

单实例意味着系统资源层面的共享，多租户意味着应用逻辑层面的隔离。所以如何平衡好这两点，才是SaaS应用多租户设计的核心关注点。
经典的分布式效劳架构天然处置了互联网应用的三高问题（高并发、高性能、高可用），这也是企业SaaS开展中后期即将面临的问题，下面我们来分析下如何在该架构下去设计与实现多租户SaaS应用。
多租户的实现
从资源共享的层面看，从分享 nothing到分享 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端产品研发经历。目前主要关注企业级产品的技术架构、研发管理等方面。