企业级SaaS近年来，市场出现在每个细分领域。从技术角度来看，不同的领域，不同的领域SaaS产品必须有相同的结构核心，其中最重要的是多租户（Multi-Tenancy）支持。对于广大企业，引进SaaS产品本质上就是对互联网服务的租赁，因而多租户便必然是SaaS其自然属性之一也是其与传统互联网应用架构设计的重要区别之一。SaaS在架构成熟度演进过程中，其核心路线是如何实现多租户，即，SaaS成熟度在很大程度上取决于如何支持多租户。

一 多租户技术的核心重点

目前，多租户在技术实现层面还没有既定的规范，不仅细节多，实现每个细节的方式也多种多样。一方面，如何实施取决于当前研发团队现有的技术储备、技术选择、团队资本实力、行业或客户特点（如金融行业对数据安全要求较高），另一方面也与当前的技术发展密切相关，云制造商的崛起和云本土时代的到来，也深刻影响包括SaaS软件构建的方法。

但传统上，真的SaaS应用程序通常需要满足以下两点：

单实例多租户

单个实例意味着系统资源共享，多租户意味着应用逻辑隔离。因此，如何平衡这两点是SaaS应用多租户设计的核心重点。

经典的分布式服务架构自然解决了互联网应用的三个高问题（高并发性、高性能、高可用性）SaaS在发展的中后期，我们将分析如何设计和实现多租户SaaS应用。

实现二 多租户

从资源共享的角度来看，share nothing到share everything，多租户可以在天平的任何一点上得到支持。但正如我们前面所说，SaaS架构的主要目标是单个实例。只有单个实例才能尽可能降低成本，产品才能具有规模效应。因此，所谓的共享和隔离将集中在经典架构下，即如何在资源层面隔离不同的租户。

关于资源的三

说到资源，我们可能会想到CPU、内存、磁盘、网络带宽等。，但这么多类型的资源可以分为两类，即存储资源和计算资源。

换句话说，SaaS本质上，该系统也可以被视为分布式存储和分布式计算的集成。

在多租户的实现中，更重要的是存储资源的处理。计算资源通常只在必要时考虑。我认为这主要与存储的状态有关。让我们以一些典型的场景为例，分析如何开始多租户的设计。

隔离四 存储资源

一般来说，隔离存储资源可以用一个词来解决：命名空间。以数据库为例，我们只需要在每个租户的记录中写下相应租户的标志。

一般来说，如果不考虑分库分表，我们逻辑上会是一样的Sche ** 中，存储所有租户的数据。这就要求每个表都有一个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端产品研发经验。目前主要关注企业级产品的技术结构、研发管理等。

欢迎更多技术干货关注网易智能企业技术 。CTO讲前沿观察，看最有价值的技术干货，学习网易的最新实践经验。网易智能企业技术 ，陪你从思考者成长为技术专家。