云计算多租户体系构架技术的探讨

1、云计算多租户体系构架技术的探讨【摘 要】互联网下云计算多租户体系架构有多种实 现方式，每种实现方式都有其优缺点，通过对文献研究、开 源项目、科研课题研究，和基于构件的开发方法和经典构件 模型的研究，针对多租户容器平台与业务平台中的关键技术 问题开展相关研究， 对多租户个性化定制、 多租户性能隔离、 多租户信息管理技术、统一权限控制、数据库隔离及路由等 关键技术点进行探讨研究，解决其中的技术难点，突破技术 的瓶颈。【关键词】互联网 软件服务 技术研究1 关键技术分析1.1 面向研发管理领域的构件模型COM/DCOM、COBRA .NET Assembly、EJB等经典构件 模型都是针对通用领域进

2、行定义的，一方面能够适应所有的 业务领域，另一方面对于特定的领域需要将进行进一步的领 域化处理。为解决软件危机，软件工程提出并发展了 40 多 年，针对软件研发管理已经形成一系列的标准、 理论、方法、 理念，其中的业务领域已经相对稳定了，因此可以针对该领 域建立领域特定的构件模型。该构件模型中将包含预定义的 业务领域活动、 行为、数据等，比如需求管理领域中需求项。 基于这些预定义业务元素，能够进一步提高基于构件的设计 和开发的效率，降低缺陷率。因此，面向研发管理领域的构 件模型技术的攻关将是软件服务管理平台技术的关键。1.2 多租户统一权限控制 研发管理平台业务逻辑复杂，涉及到多个部署构件、多

3、 个系统模块、 多种用户角色交互等， 需要对系统用户从链接、 菜单、方法、数据等层次来提供立体的全方位访问控制，保 证系统的安全性。在几种控制对象中，数据的控制是最困难 的，也是最重要的，其本质原因是因为对数据的权限控制在 很大程度上是业务逻辑的体现，而业务逻辑是很难有一个统 一的方式来进行描述和控制的。因此，如何提取一种统一的 模型来对数据对象进行控制就是要解决的关键技术点。统一 权限模型的建立，将对系统提供全面的防护措施，严格控制 数据的访问。1.3基于Qos的请求分配与资源调度技术采用高资源共享度的云计算软件服务模式提高了资源的利用率，降低了系统的运维成本，但是当系统的并发访问量增大时，

4、就必须采取一种措施来保证高服务级别（SLA）租户的访问顺畅执行，同时进行计算资源的横向扩展，来保 证整个系统的稳定运行。2 管理平台的技术路线分析 基于云计算软件服务模式的管理平台的技术路线可初步分为：技术调研与选型关键技术研究、架构设计、测试驱动开发、系统测试、 部署实施等环节，如图 1。图13 软件服务的隔离模式选型 多租户模式的一个关键技术是提供对不同租户请求访 问的隔离。隔离分为物理级别的隔离、虚拟机级别的隔离和 应用级别的隔离。物理级别的隔离方式表现为一对一模式，即一个单独的 应用实例对应一个单独的租户，能够很容易的满足每个租户 的个性化需求，同时每个租户的应用和数据存储都是物理隔

5、离的，每个租户都独自拥有计算和存储物理资源。这种隔离 方式使得租户彼此之间基本不会产生相互影响，具有较高的 安全性，是多租户的三种实现方式中隔离级别最高的。但是 在这种模式下，应用开发商投入的软件开发、维护、培训、 实施等成本和硬件成本比较高，软硬件的共享性相应的也是 多租户技术实现的三种方式中最低的。传统的应用服务提供 商（Application Service Provider , ASP 就是这种隔离方式。虚拟机级别的隔离方式是指通过虚拟机技术共享各种 物理资源，即利用虚拟机模拟物理机器，在模拟的物理机中 满足租户的个性化需求，提供租户间的逻辑隔离。这种方式 下，租户间的隔离性就相对降低

6、了，但是资源的共享利用率 相对来说有所提高，同一台物理机器可能对应多个虚拟机同 时可以支持多个租户，支持的租户数量有所增加。目前国内 的大多数SaaS服务提供商都是采用这种模式， 比如国云在线、 风云在线、品高云在线等。应用级别的隔离方式表示为单实例多租户模式，即通过 共享一个应用实例，为多个租户提供服务。应用实例通过应 用程序级的租户定制方式满足租户的个性化需求，并通过多 租户的数据存储设计、性能隔离等方式，使所有租户能够共 享存储系统和硬件设备资源，从逻辑上实现租户的隔离。在 这种模式下，资源的共享程度达到了最高，软件和硬件的成 本下降。 Saleforce 的 F 平台就是采用这种应用级

7、别 的隔离方式，实现了资源的最大程度共享，获取了更高的利 润，但是背后的技术却更加复杂。综上所述，应用级别的多租户模式的资源共享度最高， 这使得采用该种方式能够带来更大的利润。与此同时隔离性 低带来的相关需要突破的技术问题，包括多租户基础管理、 应用实例的个性化定制、多租户统一权限控制和性能隔离技 术等。4 研发管理领域业务分析与架构设计4.1 业务流程分析项目管理是最核心最基础的业务模块。根据 Qone 的实际业务积累和 CMMI 标准过程域，将其分为售前管理、项目 启动、项目初始化等六个关键活动，覆盖项目研发中的主要 流程和主要参与角色。资源管理不属于 CMMI 的过程域，但 是在 Qon

8、e 的实际业务中发现，对于中大型软件企业，人员 的计划、监控、高层统计等业务需求是广泛存在的。因此， 资源管理也作为一个关键的业务模块。其核心管理涉及到三 个方面，包括人员基础数据的维护、资源计划与变更、资源 分析及成本统计。需求管理是 CMMI 3 级的标准过程域，对需求管理的成 功与否在很大程度上也决定了项目的成功与否。需求树中包 含需求项的集合，可以将一部分需求项生成快照编程需求基 线，需求基线是软件设计、开发、测试的基础。需求之间以 及需求与任务和工作产品之间需要建立需求跟踪矩阵，用来 验证需求是否已经实现，以及控制需求变更。4.2 领域内模块间依赖设计 从以上流程可以看出项目管理是核

9、心模块，资源管理与 需求管理都需要与其交互。从架构设计的角度来说，希望能 够实现各业务模块的分离，又能实现各业务模块的集成，以 及与外部的业务系统的集成，因此需要实现领域内构件的协 作交互机制。该机制将根据构件模型的定义，从领域层、 UI 层、服务层来进行拆分。 领域的内聚性使得很难将 一些功能和模块进行拆分，比如项目计划与用户报工模块。 这是因为用户报工主要就是针对制定的项目计划而进行的， 它们在概念上就存在依赖关系。如果按照面向服务的方式将 其拆开，将会导致功能执行效率的降低。因此，内部模块的 协作一般不采用松耦合服务调用的方式，而是在实体中直接 引用。比如项目管理与售前管理有关联关系，这

10、是由于外部 项目需要与售前的活动进行关联。但是对于内部项目来说， 是不需要知道售前活动的。因此，项目管理模块可以拆分为 外部项目管理和内部项目管理两部分，涉及到售前的外部项 目信息需要提取出来作为新的构件，该构件依赖于项目管理 核心构件与售前管理构件。当不需要外部项目管理功能时， 则不加载外部项目管理构件即可实现；当需要外部项目管理 功能时，只需要加载外部项目管理构件与售前管理构件。4.3 与外部系统依赖设计 与第三方外部系统之间的协作需要采用面向服务的方 式进行，通过领域特定的接口服务进行交互。与社会化服务 的交互主要是体现在用户信息和工作内容的实时交互上。研 发管理平台与 OpenId 方

11、案进行集成，可以实现社会化服务 中的用户登陆。在平台中产生的工作进展、工作总结、疑问 等内容可以输出到微博等服务，同时相关的研发管理的内容 可以推送到平台。5 平台的创新点5.1 领域特定的构件模型经典的 COM/DCOM、COBRA NET Assembly EJB等构 件模型是通用的模型，没有领域针对性。本项目中提出了面 向领域的构件模型，采用领域驱动设计思想进行了构件模型 的类型、层次、粒度等的定义，并且对研发管理领域中的核 心概念采用构件的方式进行了领域封装，形成了领域特定的 构件模型( Domain specific component model )。5.2 微内核的多租户容器构件

12、架构 多租户容器借鉴了操作系统中的微内核体系结构设计 的思想， 形成了以 core 构件为核心的容器系统。 这种架构设 计使得能够任意的更换和组装内核之外的构件，形成具有不 同功能的容器。 比如将其中 Tenant 多租户构件去除， 在其中 运行的应用系统就不具有多租户的能力。5.3 广泛的协作集成 基于面向研发管理领域的构件模型，对领域内构件的集 成以及与外部系统的协作进行了定义。通过在平台中进行业 务扩展点和服务的开发接口，从而能够支持与其他模块、系 统和服务的协作集成。5.4 基于 Qos 的多租户性能隔离 针对多租户高并发访问的情况，提出了相应的机制和算 法，对访问请求进行了调度，同时

13、引入了资源横向扩展的方 式，实现了对多租户性能的隔离， 保证了整个系统的可用性。6 结语 利用云计算技术搭建的多租户体系架构，获取软件研发 管理应用的多租户支持，负载处理动态能力将得到很大的提 升。平台若部署 5个租户，每个租户系统可并发访问 100 人， 初始并发访问人数为 20 人，数据总量为 20 万条， 每增加 20 人并发访问，负载处理响应时间在 2-5 秒。基于云计算技术实现多租户体系构架研发管理平台的 高度可定制性、可配置性等特性，根据自己的需要修改系统 已有表单的布局，增删表单中的字段，提交完成的表单具热 部署能力。当多个租户用户的访问请求造成资源紧张时，将 自动启动基于 Qos 性能隔离，使得整个系统能够持续可用。 能够通过多租户容器的 Tenant 构件的加载与否， 决定整个平 台是否采用多租户的服务模式。参