多租户的共享与隔离

在上一篇文章《多租户是一种技术》中提到，多租户是云计算服务供应的模型。本文将继续探讨云服务供应商所提供的资源、技术栈和应用实例在不同租户之间的共享与隔离。

【本期主要内容】

1. 用户视角的多租户

2. 全栈隔离模型

3. 资源池模型

4. 桥接模型

在云计算的服务模式中，共享和隔离是共存的。用户通过自服务的方式直接访问到对应租户范围内隔离的业务对象、数据或资源，对其进行操作和管理；租户共享云服务提供者所提供的资源和服务，响应用户的操作，满足面向用户的 SLA。

用户视角的多租户

在多租户模型中，用户对云服务的访问范围是由其对应服务/子服务的租户控制的。因此，从用户的视角，共享与隔离与用户所使用的服务并无直接关联，且用户通常是无感知的（或者说，用户“自以为”使用的是独立的资源）。例如：在政务云中，云服务商按照各个委办局划分基础设施的租户，为每个租户分配隔离的资源池（VPC）；访问各委办局的云计算资源部署业务系统的运维人员使用共享的统一身份认证服务登录其可管理的资源池对业务系统进行管理，业务人员通过统一身份认证服务访问部署在委办局租户范围内的业务系统。在使用过程中，无论是运维人员或是业务人员，都无需关注所使用的服务和资源与其他租户之间是否隔离或共享，仅关注自身业务即可。在这个过程中，运维人员作为共享统一身份认证服务和政务云管理服务的租户，实现身份认证和指定管理范围内的资源池管理；业务人员则作为共享统一身份认证服务的租户完成身份认证，并登陆到与其他委办局隔离的资源池中部署的业务应用，处理日常事务。上述样例的共享与隔离模型如下图所示。

政务云中的租户

从上述案例不难看出，在云服务供应的内容只有共享和隔离两种方式，即，非共享即隔离。因此，本文将以隔离为主线，讨论共享与隔离模型。根据云服务隔离的粒度与架构方式，多租户的隔离模型可分为全栈隔离模型、资源池模型和桥接模型。

全栈隔离模型

全栈隔离意味着在当前的服务模式之上，云计算提供者为服务的租户提供的服务内容是一组隔离且完全独立部署的实例。全栈隔离模型下，租户间除了可能共享服务模式底层的资源，通常还会共享计量计费、服务部署、身份验证、运维分析等服务。例如，在 PaaS 的服务模式之上，全栈隔离模型的租户服务内容是一套独立部署的应用运行环境，不同租户之间的应用运行环境之间不存在关联，且包含了支撑应用运行所需的全部技术栈。如下图所示。

全栈隔离模型（PaaS）

全栈隔离模型下，租户间除了可能共享服务模式底层的资源，通常还会共享计量计费、服务部署、身份验证、运维分析等服务及设施，通过上述服务或设施的共享，云服务提供者能够达到节省云服务运营成本以及提升运营水平等目的。

全栈隔离模型适合对业务系统间隔离的合规性要求严格的场景，例如前文提到的政务云中的不同委办局，通常采用全栈隔离模型。在全栈隔离模型下，云服务提供者为每个租户提供专有的环境，不会受到其他租户影响。然而，全栈隔离模型下的每个租户都会占用相对固定的资源，且云服务提供者对其管理的复杂度也更高，因而云服务提供者可管理和提供的租户数量是有限的。同时，全栈隔离模型下，每个租户的开销更大。由于租户独占了资源，因而云服务提供者无法根据资源的利用率动态分配和调整资源（即使一个租户在某个时段有大量的空闲资源，也无法“挪用”），带来较低的云计算资源使用效率。另外，全栈隔离模型要求每个租户部署完整独立的资源、技术栈以及软件实例，导致新租户环境的上线时间较长。

资源池模型

资源池模型将当前服务模式下的服务内容进行统一部署和管理，在租户间共享服务内容和实例，通过数据字段和命名空间（namespace）等方式，实现对租户在业务和数据上的逻辑隔离。在资源池模型中，租户间的所有服务内容的部署实例都是共享的，这些部署实例构成资源池，可能会在不同租户间切换，或同时服务多个租户。例如：在 PaaS 模式下，云服务提供者维护了 Web 容器、数据库和服务网关的资源池，不同的租户共享资源池中的实例，编排为 Runtime，部署业务应用。实例按租户的 namespace 隔离租户的业务，按照 TENANT_ID 隔离租户的数据。如下图所示。

资源池模型

资源池模型的隔离最大程度上共享了通过云服务提供的基础设施、技术栈和软件，被很多公共 SaaS 供应商采纳。资源池模型能够带来资源使用效率和运维效率的提升，由于租户间共享基础设施模型和技术栈，服务供应的过程变得简单，流程的敏捷性也得到提升。云服务提供者可以在为不同租户提供服务时，复用在相同技术栈的内容和实例上管理、扩缩容和操作上的经验，在服务的维护、升级和变更时，也可以实现批量、统一操作。资源池模型采用逻辑隔离的方式，由于租户间资源和技术栈的共享，使用户之间的影响的机会增大，在某些时候，租户对资源的滥用或误操作甚至可能会波及其他用户的正常使用。因此，在资源池模型下，云服务提供者需要为用户操作设定规则和边界。例如，谷歌在其最初版本的 PaaS 平台 GAE 中，限定了用户在编码中不允许创建线程，以避免用户通过线程操作占用额外的资源，降低资源分配管理上的难度。

桥接模型

桥接模型是混合了全栈隔离模型和资源池模型的方案。桥接模型将用户对租户资源访问的入口抽象为共享服务层，以资源池模型提供服务，同时，连接底层全隔离模型的环境。例如，在 PaaS 的服务模式下，租户共享服务网关，服务网关通过路由的 namespace 给每个租户分配空间，并将用户的访问转发至相应租户专有的 Runtime 实例。通过桥接的方式，租户能够获得相应隔离的环境，租户间的业务可以做到互不打扰；同时，云服务提供者可以通过统一的入口对租户的流量、负载进行统一管理，尤其在隔离环境基于微服务架构构建时，通过服务网关实现的服务治理可以更大程度上提升全隔离模型的可管理型。桥接模型如下图所示。

桥接模型

以上介绍了云服务供应过程中，多租户的共享与隔离模型。在实际的应用中，云服务提供者可能会根据用户的订阅和部署方式不同，提供分级的多租户模型。例如，对于隔离性需求较高的高端客户，提供全隔离模型；对于隔离性需求不高并追求性价比的客户或业务领域，提供资源池模型；对于业务系统之间隔离性要求较高，且对集中管控有较高要求的客户或业务领域，提供桥接模型帮助用户提升资源使用的效能，提升管理效率。

在后续的文章中，我们将继续探讨不同多租户模型的实现方式，以及服务模式对多租户的影响。