面向多租户的门户资源管理框架

高 蕾，杨 燕，钟 华，于谨维

（中国科学院 软件研究所 软件工程技术研发中心，北京100190）

0 引 言

平台即服务 （platform as a service，PaaS）是一种重要的云计算服务类型［1］，为应用服务提供一个可伸缩的运行和管控环境，以及支撑多个共存应用程序的中间件。其典型代 表 包 括 Force.com、Google App Engine、Microsoft Azure等。基于多租户技术的PaaS平台，面向的租户是应用开发者或业务系统，使之能够共享相同的开发框架和技术平台。

多租户技术的关键在于平衡资源复用所带来的收益和风险，比如资源共享、安全隔离、定制以及管理复杂性等问题［2］。尽管资源共享机制能够有效地提高系统的资源利用率，通过规模效益降低每个租户的软硬件和运行管理的成本，但是由于共享应用实例和系统资源，同时也会带来一定的资源管理问题。

在高度共享的多租户平台中，汇聚了多种类型的数据资源和应用资源。这些资源不仅种类繁多，使用和管理方式各异，而且来自不同的租户，具有不同的共享和访问控制策略。为了更好地利用系统中的逻辑资源，比如数据资源、应用组件资源等，需要通过统一的资源管理框架进行集成和管理。

在多租户环境下进行逻辑资源的管理，在通过共享提高资源利用率的同时，必须在不同租户间进行安全隔离。不仅需要考虑如何向各个租户和应用屏蔽关键的系统资源和逻辑资源，限制不同租户之间的资源可见性，而且要在对租户屏蔽内部逻辑资源的前提下，允许租户应用同系统基础设施服务之间进行交互。针对上述问题，本文在门户应用场景中，结合门户资源具有多样性、规范性和聚合性的特点，提出了面向多租户的资源管理框架，重点从资源共享和隔离的角度，探索多租户环境中门户资源的管理问题。将各种资源聚合为一个虚拟资源集，使不同租户通过逻辑上相互独立的虚拟门户，来访问共享的中间件平台。

1 相关工作

对于多租户的实现技术，目前国内外存在许多相关研究。文献 ［2］利用操作系统级别的虚拟化技术，通过在共享的硬件实例上运行多个操作系统的虚拟实例，由每个虚拟操作系统实例执行不同租户的应用。尽管虚拟化技术比较成熟，在面对大量租户使用同一类型应用时，若每个租户的应用都运行在单独的虚拟机上，会重复占用大量系统资源，增大虚拟机的管理难度和性能开销。

随着软件即服务 （software as a service，SaaS）的成功，在多租户框架方面已经有了很多的研究工作［3］，但大部分的研究侧重于数据管理层。然而，在PaaS平台中，租户需要运行整个应用或服务栈，因此需要提供多层次、完备的多租户解决方案。

文献 ［4］提出了多租户应用的四级成熟度模型，成熟度等级越高表示资源的共享程度越高。比如，第一级为每个租户分别提供一个应用实例；第二级允许多个租户共享相同的代码库，但每个租户提供一个可定制的应用运行实例；第三级通过一个运行的应用实例为多个租户提供服务；第四级通过负载均衡等技术，来提高应用系统的伸缩能力。本文将讨论符合第三级成熟度模型的多租户PaaS平台中的资源共享问题。

文献 ［5］分析多租户技术的业务需求和特点，提出多租户SaaS应用的设计策略和体系架构。文献 ［6］采用代理机制，通过黑盒方式实现任务集合与资源的绑定，并在此基础上进行准入控制和请求调度。黑盒方式的中间件资源管理方法的资源管理能力有限，无法控制平台内的各种资源，难以适应负载的动态变化。因此需要根据特定应用的体系结构和资源的运行状态，有针对性地进行资源管理。

在提高共享资源的可用性方面，文献 ［7］在租户高度自治和动态变化的情况下，通过预测资源的可用性，动态地增加或减少资源的副本数目。但该方案需要在不同租户域内维护多份资源副本，存在难以同步资源状态并保证其一致性的问题。

文献 ［8］Force.com通过元数据驱动的软件体系结构，来支持多租户应用。向企业用户提供按需、灵活的资源使用模式。

IBM ［9］采用中间件实现SaaS解决方案，提出了单一实例多租户应用程序中资源共享的设计模式。重点从多租户身份验证和授权机制，以及数据层的设计模式，研究多租户的隔离和定制。通过在一台服务器上创建多重虚拟门户，提供独立的逻辑分区。

2 面向多租户架构的门户中间件平台

在传统的企业信息门户中，尤其是对于地理位置分散的大型企业来讲，通常需要为不同分公司或部门安装独立的门户应用系统。不同的门户系统之间相互独立，没有软硬件、数据等资源的共享和交互，不仅使整个企业IT基础设施的运行和维护成本较高，而且为企业内部信息的交流与传递造成不便。

随着云计算的发展，多租户作为其关键特性之一，通过宿主在云平台上的一个或多个应用和服务实例，为来自不同组织 （租户）的并发用户请求提供服务，有效地提高资源利用率，并降低软件实施和管理的成本。

文献 ［3］将基于资源共享的多租户启用模式分为两类：①多个应用实例；②单个应用实例。前者为每个租户提供专用的应用实例，后者通过单个共享的应用实例为多个租户提供服务。本文针对门户中间件平台提出的解决方案将采用共享应用实例的多租户架构，能够支持较高的租户密度，更有效地降低软件管理和维护的成本。如图1所示。

图1 面向多租户架构的门户中间件平台

在面向多租户架构的门户中间件平台中，不同租户通过逻辑上相互独立的门户应用系统，即虚拟门户，来访问共享的门户中间件和底层基础设施提供的软硬件资源。资源管理框架将各种门户资源聚合为一个虚拟资源集，来满足来自不同虚拟门户的资源请求与分配。

3 资源管理框架

本文研究的企业信息门户中间件采用基于组件的体系结构，由应用服务器、组件容器、组件应用资源、数据资源和基础服务资源组成。通过资源管理框架管理的资源包括数据资源、应用资源和基础服务资源。其中，数据资源包括租户的组织结构数据、用户偏好、页面主题与布局等。应用资源是指封装了各种后端业务系统及外部数据源的portlet应用。基础服务资源包括门户系统运行所需的各种服务，如日志服务、访问控制服务、用户管理服务等。

在多租户环境下研究门户资源的管理问题，首先需要考虑资源及其相关操作的独特性。门户资源具有以下特性：

（1）多样性：企业信息门户中的资源来自于不同的业务系统和信息源，资源类型多种多样，尤其是在租户动态变化的情况下，为了在多个租户之间进行有效地资源共享和隔离，就必须考虑各类资源的访问特性。

（2）规范性：Portlet2.0规范［11］和 WSRP规范［12］的提出，促使门户资源的统一和规范化，针对这类规范化的资源的访问控制，可以抽象出一套统一的控制规则和操作集合。

（3）聚合性：门户需要将资源和应用整合起来提供给用户，使用户能够在一次会话中实现对多个资源对象的访问，因此需要根据资源请求的上下文信息进行租户和可访问资源的映射。

结合门户中间件平台的体系架构和门户资源的特性，本文提出了面向多租户技术的门户资源管理框架。目标是从逻辑上耦合各类门户资源，通过一致的共享和访问控制策略，向用户提供统一的访问接口，屏蔽对租户敏感的资源访问的细节问题，有效地提高资源利用率。如图2所示。

资源管理的基本功能是接受来自租户的资源请求，并将特定资源分配给资源使用者。合理地调度相应的资源，使请求资源的任务得以运行。为了实现上述需求，资源管理框架主要由资源注册、资源发现、资源调度、状态监控和资源存储5个基本服务组成。

资源管理的基本功能是接受来自租户的资源请求，并将特定资源分配给资源使用者。合理地调度相应的资源，使请求资源的任务得以运行。为了实现上述需求，资源管理框架主要由资源注册、资源发现、资源调度、状态监控和资源存储5个基本服务组成。

为了实现资源管理框架中的各种功能和服务，需要描述资源的静态特征和动态行为。我们通过建立资源模型来描述资源的静态特征，定义资源、资源使用者以及资源管理者之间的关系。而资源管理的动态行为则采用资源管理过程来描述。

3.1 资源模型

P资源模型用于描述资源管理框架的研究对象，定义各个实体、角色以及相互之间的关系。其中，建立资源使用者与可访问资源之间的映射关系，对系统中可用的资源进行分类管理，是实施资源管理策略的前提和关键。

图2 面向多租户架构的资源管理框架

首先，我们对资源、资源使用者和资源管理者进行形式化描述，并给出了在门户中间件平台中的相互关系。其次，针对多租户环境中资源管理的特点，建立租户与资源的映射关系模型。接着，根据门户系统中资源的特点进行分类，进而为不同类型的资源提供不同的管理策略。

3.1.1 形式化定义

定义1 （资源）用五元组表示，R＝ （O，T，S，A，P）。其中，O表示资源的提供者。T表示资源类型，满足T∈｛App，Service，Data｝，即属于应用资源、服务资源或数据资源中的某一类。S表示资源的共享策略，可以是私有资源或可共享资源。可共享资源将提供相应的访问权限列表A。P表示资源使用者在访问资源时，提供的参数列表。

定义2 （资源管理者）资源管理者是管理资源的实体，扮演资源提供者的角色，包括资源管理策略和机制。根据资源类型，提供资源的内容、描述信息和共享策略，便于其他租户发现和共享该资源。同时，通过设置一定的安全控制策略，来限制其他租户的访问权限。

定义3 （资源使用者）资源使用者是虚拟门户应用中的业务逻辑实体，通过统一的资源访问接口，提供自身所属的租户信息，向系统发出资源访问请求。通常，资源使用者是指来自不同分公司或部门的租户，以及租户域内的用户。应用资源也可作为基础服务资源和数据资源的使用者。

如图1所示，在面向多租户的门户中间件平台中，资源使用者为虚拟门户应用，它作为平台服务的提供者，通过向资源提供者请求资源，为各个租户提供虚拟资源集和平台级服务。

3.1.2 映射关系模型

在多租户环境中，将来自不同租户的并发资源使用请求映射到相应的可访问资源是资源管理的关键。

租户与资源的映射关系模型如图3所示。资源管理者作为管理资源的实体，根据各种类型资源的特点，通过不同类型的资源池来进行管理。资源使用者具有特定的租户上下文信息，包括租户ID、配置参数和运行时状态信息。资源使用者和资源管理者之间的映射关系通过元模型进行映射和绑定。

图3 租户与资源的映射关系模型

在门户应用场景下，由于面向多租户的资源管理不是Portlet规范［11］的一部分，相关的元模型描述和配置信息不能写在规范定义的部署描述文件portlet.xml中。因此，我们引入了Tenant＿ResList.xml来描述租户与资源的映射关系。在Tenant＿ResConfig.xml中，描述资源的具体配置信息。对资源配置的描述包含如下信息：

表1 资源描述文件的schema定义

3.1.3 资源分类

由于门户系统中的资源具有多样性和聚合性，我们需要针对各种类型资源的特点，进行资源的分类和管理，从而提供相应的资源共享和隔离机制。

根据资源的用途，我们可以将门户系统中的各种可用资源划分为3种类型，即数据资源、应用资源和基础服务资源。其中，数据资源包括租户的组织结构数据、用户偏好、页面主题与布局等。应用资源是指封装了各种后端业务系统及外部数据源的portlet应用。基础服务资源包括门户系统运行所需的各种服务，如日志服务、访问控制服务、用户管理服务等。

根据资源的执行能力，我们可以将资源分为主动资源和被动资源。具有主动执行能力的资源称为主动资源，包括应用资源和服务资源。被动资源主要是指数据资源。资源使用者将通过主动资源来访问和操作其他资源。

根据资源的访问特性，又可以将主动资源进一步细分为有状态资源和状态无关资源。有状态资源包括了资源使用者的状态信息，需要为每个租户维护一份资源副本，并采用相应的隔离机制来避免租户间的相互影响，主要是指基础服务资源。状态无关资源是可重用的软件组件，可以由多个资源使用者共享同一个资源实例，通过租户上下文进行区分即可，在门户中主要是指portlet应用组件资源。对系统中资源的分类如图4所示。

图4 资源分类

为了便于从全局角度来发现和调度系统中的可用资源，提高资源访问的效率，可以建立一个资源注册中心，采用集中的资源组织方式进行持久化存储。资源注册中心作为各种资源的统一存储目录，将管理资源的状态，发布资源信息，是整个资源管理框架的信息集散地和发源地。根据资源的不同类型，系统需要在资源注册中心建立多棵资源树。

3.2 资源共享和隔离机制

在共享应用实例的多租户系统中，为了在提高资源利用率的同时，防止未授权用户对资源的非法访问，必须对提供对资源访问的共享和隔离。

从共享策略的角度而言，我们将系统中的可用资源分为租户私有资源和可共享资源。私有资源只能由租户域内的用户请求来访问，存储在租户独占的资源池中。在任意时刻，系统中之多只有一份私有资源的内存副本。对于可共享资源，由资源提供者在资源配置文件中显示地声明其他租户对它的访问权限。由于可能存在多个内存副本，因此具有该共享策略的资源的共享粒度是提高整个系统资源利用率的关键。为了解决可共享资源的共享问题，目前有以下两种通用的解决方案。

（1）在所有允许访问该资源的租户资源池中存放一份该资源的内存副本，各租户可以独立访问私有资源池中的资源副本。该方案具有较高的租户隔离度，但内存利用率低，且存在多个租户分别修改资源副本时产生的一致性和同步问题。

（2）仅在资源提供者所在的租户资源池中存储一份该资源的内存副本，其他允许访问该资源的租户资源池中将持有一份该资源副本的引用。该方案可以有效地提高共享资源的利用率，并且通过一定的并发控制机制，也可以解决多个租户同时修改资源副本带来的同步与互斥问题。

但是由于多租户系统中租户的添加与删除具有高度的动态性，而且租户对资源的申请与释放也相互独立。因此，当实际具有资源副本的租户处于离线状态，或释放该资源时，其他租户将无法再访问该资源，造成资源的不可用。

综上所述，通用的解决方案并不能有效地解决特定应用场景下的资源共享和隔离问题。本节根据门户资源的特点和资源模型中对资源的分类，利用租户与资源的映射关系模型，对具有不同执行能力和访问特性的资源提供相应的共享和隔离机制。

对于有状态的主动资源，以日志服务为例，不同租户对日志相关的配置可能完全不同。从安全和管理的角度而言，各个租户的日志记录需要存放在不同的文件或数据库中，其路径和内容都必须是相互独立的。因此，日志资源管理者为多个租户维护一个日志资源池，在不修改原有日志服务接口的情况下，通过隐式地获取租户与日志资源的映射关系，将资源使用者对日志资源的访问映射到正确的路径，避免租户之间数据的相互影响。如图5所示。

图5 日志资源管理的共享和隔离

对于状态无关的主动资源，以portlet应用组件为例。作为可重用的软件组件，资源使用者的状态信息记录在资源请求的上下文中。因此可以通过建立租户上下文，使多个资源使用者共享同一个资源实例。如图6所示。

图6 应用资源管理的共享和隔离

针对不同类型资源的特点，我们将系统资源池划分为公共资源池和租户资源池两部分。公共资源池用于存放状态无关资源的唯一内存副本，以及各个租户对它的访问权限、引用计数等状态信息。在租户资源池中存放私有资源和有状态资源的内存副本，以及对公共资源池中共享资源的引用。通过系统统一管理和控制公共资源池中共享资源的生命周期，使资源的申请、释放与资源提供者所属租户的运行状态无关。因此，该方案能够从全局角度进行监控与调度。在保证资源利用率的同时，更提高了资源分配与访问的灵活性。

基于上文所述的资源共享和隔离机制，相应的资源分配算法描述见表2。

表2 资源分配算法

3.3 资源管理过程

面向多租户的资源管理框架向资源使用者提供资源注册、资源发现、资源调度、状态监控和资源存储5个基本服务。资源管理过程的核心是将用户请求与目标资源进行匹配，将合适的可用资源提供给用户。如图7所示。

图7 资源管理的过程模型

首先，资源提供者通过资源管理器，将需要部署的资源实体注册到资源注册中心。资源提供者声明资源的类型以及资源之间的依赖关系，通过资源注册服务，将其存储在相应资源树的适当位置。

当资源使用者的资源请求到达时，资源请求管理器负责接收请求，进行租户识别、身份认证以及权限检查，并通过系统资源池获取可用资源的内存副本。对于尚未实例化的可用资源，将检索资源注册中心，创建相应的内存副本。在系统运行过程中，资源管理器将进行资源的状态监控，对当前资源的服务能力进行综合评价，为用户请求匹配最合适的资源服务，完成资源调度。

为了提高系统资源的利用率，资源管理器将采用一定的预定义策略，对访问频率较低的资源副本进行持久化操作。

4 多租户门户资源管理框架的实现

OncePortal［13］是由中科院软件所软件工程中心研发，基于J2EE平台的企业门户中间件，提供了企业门户的基本运行框架和支撑服务。根据面向多租户技术的资源管理框架，我们在OncePortal中实现了资源管理框架，其组件结构图如图8所示。

图8 资源管理框架的组件结构

其中核心的资源管理组件实现了资源分配算法，并依赖于租户识别与验证组件，以及资源封装组件的实现。经过访问控制模块进行资源请求的过滤后，资源调度器根据资源状态监测的结果，调用生命周期管理单元。资源注册模块将管理资源注册中心和系统资源池，向上层请求返回资源调用的结果。

资源封装组件对不同类型的资源进行统一的描述，封装了资源的属性、方法、数据接口和元数据。元数据解析器将通过读取相应的配置文件，提供给资源工厂进行统一的创建与管理。其核心类图如图9所示。

图9 资源封装模块的核心类图

5 结束语

本论文基于企业信息门户中间件平台，从多租户技术的业务需求和技术挑战出发，提出了面向多租户架构的门户中间件平台。结合门户资源具有多样性、规范性和聚合性的特点，提出了多租户门户平台中的资源管理框架。从逻辑上耦合各种资源，通过一致的共享和访问控制策略，向资源使用者提供了统一的访问接口。在建立资源模型的基础上，通过元数据描述租户与资源的映射关系，并针对不同类型的资源，提供相应的资源共享和隔离机制。在共享平台资源的同时，在各租户之间对数据资源、应用资源以及基础服务资源进行逻辑上的相对隔离。从而有效地提高资源利用率，并降低软件实施和管理的成本。

在未来的研究工作中，我们将在资源管理框架的基础上，进一步细化概念和规则，给出该框架中实际应用中的功能和性能分析。

［1］Armbrust M，Fox A，Griffith R，et al.Above the clouds：A berkeley view of cloud computing［R］.University of California at Berkeley，2009.

［2］Chang Hao Tsai，RUAN Yaoping，Sambit Sahu，et al.Virtualization－based techniques for enabling multi－tenant management tools ［C］.Dalian：International Federation for Information Processing，2007：171－182.

［3］GUO C，SUN W，HUANG Y，et al.A framework for native multi－tenancy application development and management ［C］.Tokyo，Japan：International Conference on Enterprise Computing E－Commerce and E－Services，2007：551－558.

［4］WANG Wei，HUANG Tao.Qos－driven resource management in web application hosting platform ［D］.Beijing：Institute of Software Chinese Academy of Sciences，2010 （in Chinese）.［王伟，黄涛.服务质量驱动的Web应用宿主平台资源管理研究 ［D］.北京：中科院软件所，2010.］

［5］GAO Bo.Study of multi－tenancy technologies in SOA environments ［D］.Tianjin：Tianjin University，2006 （in Chinese）.［高波.面向SOA的多租户技术的研究与实现 ［D］.天津：天津大学，2006.］

［6］Juan D，Xiaohui G，Douglas S.Highly available component sharing in large－scale multi－tenant cloud systems ［C］.Chicago，Illinois：High Performance Parallel and Distributed Computing，2010.

［7］Salesforce.Com ［EB／OL］.http：／／salsesforce.com，2010.

［8］IBM ［EB／OL］.http：／／www.ibm.com／developerworks，2010.

［9］Azeez A，Perera S，Gamage D，et al.Multi－tenant SOA middleware for cloud computing ［C］.Miami，Florida，USA：IEEE 3rd International Conference on Cloud Computing，2010：458－465.

［10］LV C，LI Q，LEI Z.PaaS：A revolution for information technology platforms ［C］.Qinhuangdao：International Conference on Educational and Network Technology，2010：346－349.

［11］JSR286：Portlet specification2.0 ［S］.Java Community Process，2008.

［12］WSRP：OASIS web services for remote portlets TC ［S］.OASIS Open，2003.

［13］OncePortal［EB／OL］.http：／／www.once.org.cn，2007.