多租户技术的跨部门和虚拟团队的解决方案

1 前言

        通过多年的企业信息化建设，Office系统逐步造成有9营业场所的分部门、9专业应用子系统、20独立的信息模块、330一种方法。这些系统或模块内置于Microsoft IIS、Apache Tomcat、Weblogic、Cordys BOP上，相互彼此独立、互不影响。

        在不考虑反复投资、资源共享、便于运维的状况下，仍存在一些长期很是难解决的问题：

        （1）、各个系统的组织、帐号不统一。维护困难。
        （2）、在一些系统或模块中。对于人员跨部门的状况。仍以两个及以上帐号的方式处理，不只业务不直观。而且操做性比較差。
        （3）、虚拟团队支持都是经过开发编码处理。实施周期较长，缺少灵活性。

        由于云计算议题的发烧，在IaaS虚拟化资源池和共用的数据中心内，怎样以单一系统架构与服务提供多数client一样甚至可定制化的服务，并且仍然可以保障客户的数据隔离。让多租户技术成为上述需求提供一套解决方式。

 

 

2 多租户技术概述

2.1 多租户技术概述

        參考百度百科的定义，多租户技术（英语：multi-tenancy technology）或称多重租赁技术，是一种软件架构技术。它是在探讨与实现怎样于多用户的环境下共用一样的系统或程序组件，并且仍可确保各用户间数据的隔离性。

 

        多租户技术源于1960年代。不少公司为了要使用不少其它的运算资源，向持有大型主机（Mainframe）的供应商租用一部份的运算资源，而这些用户经常会用到一样的应用程序，当时会以用户在登陆系统时输入的数据来决定用户的账户ID。基于这个ID，Mainframe的供应商就能够利用此ID来计算运算的资源使用量，包括CPU。存储器与软盘或磁带等，这个做法也被SAP公司用在其R/1到R/3的产品线。

        到了1990年代。应用程序服务提供者服务（application service provider）模式出现，它的做法与运做模式与租用大型主机时一样，只是租用的资源是在软件上。除了操做系统之外也包括了其上的应用程序，好比ERP系统或是CRM等应用，系统可能会执行在数台不一样的机器上。或是在一样的主机但共享不一样的数据库，以区分并计算客户的资源使用量，藉以做为计费的标准，而此技术也有效的缩减供应商的实体机器成本（因为可以在一台电脑上同一时候执行多个用户所租用的应用程序进程)。到了现代，受欢迎的消费者导向Web应用程序（如Hotmail或Gmail等）也是以单一应用程序平台来支持所有的用户，这已是多租户技术的天然演化的结果，多租户技术也可以让客户中的一部份用户得以进一步定制化他们的应用程序。

 

        在虚拟化（virtualization）技术的成熟与应用性的扩张之下，多租户技术可以驾驭虚拟化的平台。更强化在用户应用程序与数据之间的隔离，让多租户技术能更加发挥它的特点。

        在功能上，SaaS应用需要完毕应用需求中的功能要求。这与传统应用之间是没有不论什么分别的。除此以外，SaaS应用最重要的一个特性就是支持多租户。

这一点尤为对面向企业的SaaS应用来讲是必须的。

2.2 Gartner提出的7种多租户模型

        如下，咱们就来看看在SaaS应用搭建过程当中。可以採用什么样的多租户模型。

从而能较为清晰地了解将来使用PaaS平台开发的SaaS。可以为用户提供哪些多租户的服务。
        Gartner提出了7种多租户的部署和实现方式模型。该模型可以做为不论什么多租户环境的參考模型。在详细的实施中以及大型企业中。可以依据自身的需要来决定採用Gartner提出的何种多租户模型，或者几种多租户模型可以并存在一个云环境中。
        咱们首先来看一下Gartner提出的这7种模型。而后再依据本次项目的实际状况。提出使用工做流引擎产品搭建何种多租户模型设计。
        首先。Gartner依照4个层次对多租户模型进行划分，即基础设施层（主要是指各类server）、数据层（即数据库层）、应用平台层（即应用执行的容器，一般也称为应用server）、以及应用逻辑层（即应用功能）。

例如如下图所看到的：

        第一种模型称为“Shared Nothing”，即不共享不论什么资源。在这样的模型中。从最底层的基础设施层。一直到最上端的应用逻辑层，每个租户均独享。这样的模式也是传统的IT开发和部署模式。

        另一种模型称为“Shared Hardware”，即共享硬件资源，所有硬件server会造成一个硬件资源池，所有租户依据需要来共享这些资源。这样的模式就是现在比較常见的IaaS模式。

        第三种模型称为“Shared OS”，即共享操做系统。

在这样的模型中，所有硬件资源均安装有一样的操做系统。经过在租户间切分和分配操做系统的进程来实现对计算资源的共享。与另一种模型同样，这样的模型也主要集中在对底层计算资源的共享和分配上，而更高层次的内容均是各个租户独享的资源。需要单独购买和部署。

 

        第四种模型称为“Shared Database”。即共享数据库。

在这样的模型下，所有租户会共享一个数据库，各个租户本身的应用server以及执行于当中的应用会使用共享数据库中为该租户划分的数据资源。

        第五种模型称为“Shared Container”，即共享容器。注意，在这样的模型下。各个租户仅仅是共享应用的执行容器，而应用相应的数据库都是各个租户独享的，这一点与第六种模型是根本性的差异。

在这样的模型中。要求应用执行的容器是支持多租户訪问的，即容器自己可以智能化的区分来自各个租户的请求。

        第六种模型称为“Shared Everything”，即全共享。在这样的模型中，所有租户自顶向下共享所有资源。对于提供服务的一方来说，可以最大限度的利用各类资源，并且依托支持多租户的应用容器，也可以仅仅开发一套程序。部署一次。即可知足所有租户对公共应用的需要。

        第七种模型称为“Custom Multitenancy”，即定制化的多租户。在这样的模型中，实现多租户的方法是在应用逻辑中改造已有的API，添加租户的维度。但是这样的模式不过对某一个应用起做用，由于没有使用支持多租户的应用server。但是又想让各个租户共享应用容器，因此不得不在应用逻辑中作文章。

 

        在信息平台建设中，应当依据详细客户的需要，来构建恰当的多租户模型，为其提供所需的不一样服务级别的SaaS应用服务。对于需要更为经济型SaaS应用的客户群。可以提供第六种多租户模型的应用，而对于需要更高数据隔离和计算资源需要的客户群。则可以提供第五种多租户模型的应用。

 

 

2.3 多租户应用特色

        （1）用户定制
        用户可依据本身的需要自行定制应用程序；
        应赞成多个版本号同一时候执行。

        （2）共享实例
        方便部署与管理；
        易扩展；
        为数据集成提供便利。

        （3）应用隔离、数据隔离

 

2.4 多租户使用场景

        下图为多租户使用目标场景，应用及其部署隔离、数据库隔离并採用不一样的数据库。

        好比，市场经营部门，租用业务流程和专业应用两个业务应用。

那么。市场经营人员登陆系统后。就可以见到业务流程和专业应用两个应用菜单。有对应权限进行业务操做，业务权限由业务应用管理员进行配置。

 

 

 

3 使用多租户技术实现人员跨部门及虚拟团队功能

3.1 引言

        在信息系统设计中。系统人员存在跨部门状况，也属于常见的现象，一般经过组织管理、角色管理来解决，而当系统逐渐庞大起来后。这样的解决方式将更趋于复杂，灵活性减小的状况。

 

        如本文開始所描写叙述的多个独立系统，也是Gartner第一种模型所称为“Shared Nothing”的状况，这是逐个解决的。

 

        而如今信息化普及状况下，信息系统愈来愈庞大、复杂，早期的内容需要整合到统一平台上，採用“发烧级的”云技术架构，这时，人员跨部门、虚拟团队的解决方式就比較突出了，怎样解决更合理呢？

 

3.2 使用多租户技术的解决方式

        使用多租户技术的解决方式，严格的来讲。不不过技术方案。而且还包含管理方案。

这样。先从技术方案提及。

 

        （1）在目标业务运营平台上。应存在统一用户帐户服务、统一待办任务服务、租户服务。

        统一用户帐户服务。是业务运营平台上所有应用的仅仅有一套用户帐号和标准组织机构。

        统一待办服务。是针对流程应用的，所有流程应用的待办。都由统一待办服务提供。

        租户服务，是需要平台提供的租户租赁开通管理。

        （2）例如如下图所看到的，在租户内容部署应用，假设某个租户有个性化需求。则在原应用版本号上个性化新版本号，在新的租户上使用。

        按此原理，业务应用一般包括一个基础版本号，其它的为拓展个性化和版本号，而不是一个大而全的版本号。这样，相关的人员跨部门、虚拟组织的功能，作为服务，在应用内解决。        

        假设，从管理方案上说。

        （1）跨部门、虚拟组织。每每是暂时性的，或者有期限的，这样，从管理角度。新建租户，为暂时组织提供相关服务；

        （2）对于特殊的多重身份、职能的结构和我的，则创建专用租户，用于解决跨部门、虚拟组织的需求。

 

 

3.3 多租户使用举例

        （1）用户使用应用的过程

        例如如下图所看到的。用户经过统一组织文件夹登陆系统，获取用户基本信息和权限（应用菜单入口）。经过菜单进入开通的应用，这时，可以获取此应用下的角色权限（用于处理虚拟组织），按虚拟组织角色起草公文。

 

        （2）用户处理待办任务的过程

        例如如下图所看到的，用户经过统一组织文件夹登陆系统，获取用户基本信息和权限（应用菜单入口）。经过统一待办读取待办任务。在待办任务中包括租用应用信息。由此直接定位到详细应用功能点，进入开通的应用时，可以获取此应用下的角色权限（用于处理虚拟组织），按虚拟组织角色审批公文。

 

        综合上述使用过程分析。虚拟组织、人员跨部门，可以进行统一管理。统一管理的概念仅限技术层面，便于在统一业务运营平台上应用。

在业务应用是为虚拟团队服务的视角下。应该为虚拟团队开通租户，为虚拟团队部署相关业务应用。在虚拟团队可以使用某应用的视角下，在应用里创建虚拟团队的角色组。

        当中，虚拟团队的角色组（权限群集），应进行统一管理，分配给对应的应用里。

 

4 关于使用SaaS模式开发的思考

4.1 关于SaaS模式

        按百度百科的定义：SaaS是Software-as-a-service（软件即服务）。SaaS在业内的叫法是软件运营，或称软营。

是一种基于互联网提供软件服务的应用模式。

一种随着互联网技术的发展和应用软件的成熟，在21世纪開始兴起的全然创新的软件应用模式。是软件科技发展的最新趋势。

        SaaS不是云计算，云计算也不等于SaaS。SaaS是云计算上的应用表现。云计算是SaaS的后端基础服务保障。

云计算将弱化SaaS门槛。促进SaaS发展。云计算应用直接剥离出去，将平台留下，作平台的始终作平台，作云计算资源的人专心作好资深的调度和服务。

SaaS服务商仅仅需要关注本身的软件功能表现，无需投入大量资金到后端基础系统建设。

        依据SaaS应用是否具备可配置性，高性能，可伸缩性的特性。SaaS成熟度模型被分红四级。

每一级都比前一级添加三中特性中的一种。

 

	可配置	高性能	可伸缩
Level1	N	N	N
Level2	Y	N	N
Level3	Y	Y	N
Level4	Y	Y	Y

 

 

       （1）定制开发—Level1
        这样的模型下。软件服务提供商为每个客户定制一套软件。并为其部署。

每个客户使用一个独立的数据库实例和应用server实例。

数据库中的数据结构和应用的代码可能都依据客户需求作过定制化改动。

（屡次开发）

       （2）可配置—Level2
        经过不一样的配置知足不一样客户的需求，而不需要为每个客户进行特定定制。以减小定制开发的成本。
但是。软件的部署架构没有太大的变化。依旧为每个客户独立部署一个执行实例。

仅仅是每个执行实例执行的是同一份代码，经过配置的不一样来知足不一样客户的个性化需求。
可配置性的比較通用的实现方式。就是经过MetaData（元数据）来实现。（一次开发屡次部署）

       （3）多租架构—Level3
        多租户单实例（Multi-Tenant）的应用架构才是一般真正意义上的SaaS应用架构，它可以有效减小SaaS应用的硬件及执行维护成本。最大化地发挥SaaS应用的规模效应。（一次开发一次部署）

       （4）可伸缩架构—Level4
        将第三级的Multi-Tenant SingleInstance系统扩展为Multi-Tenant MultiInstance。终于用户首先经过接入Tenant Load Balance层，再被分配到不一样的Instance上。经过多个Instance来分担大量用户的訪问，咱们可以让应用实现近似无限的水平扩展

        SaaS2.0模式要求服务运营商能够提供具有灵活定制、即时部署、高速集成的SaaS应用平台，能够提供基于web的应用定制、开发、部署工具，能够实现无编程的SaaS应用、稳定、部署实现能力。

4.2 使用SaaS模式的思考

        SaaS2.0模式正式企业用户所但愿的目标系统。

        例如如下图所看到的，经过软件组件（信息公布、信息交互、信息展示、信息统计、UI复合）组装市场竞争信息应用。组装后的市场竞争信息应用提供给市场经营部门租户使用。这种方案，最好使用SaaS2.0模式，先从架构功能说说。

        （1）应用展示界面可配置或者按规则调整，比較简易的方式是提供信息专栏模版。模版上栏目可配置。

        （2）功能组件按界面接口规范、服务接口规范（Webserice）设计、开发，便于适配组装；

        （3）功能组件粒度应该适中。便于管理和组装，可以这样定义原则： 业务完整性、界面展示模块化、技术服务专业性。

 

 

5 在运维管理中的思考

        採用多租户技术的平台及软件，系统势必复杂、灵活、多样。给运维管理带来必定的挑战性。所以，在设计时规划出运维管理，针对人员跨部门、虚拟团队的管理，可以从人员的运维管理入手。

        （1）人员变更

        调整部门、调整岗位、转入到不一样公司是常见的运维工做。这样。环绕人员的调整。管理其相应的租户、应用模块（应用清单）、角色、权限，以人为视角进行资源调整，从原资源信息到目标资源信息调整。并作好变更日志。

 

        （2）虚拟团队管理

        从运营平台的角度，统一的、系统的管理虚拟团队。包含团队成员管理、权限管理，这样也存在多角度交叉的问题。都需要在设计时考虑全面。

        关于运维管理，限于文档篇幅和主题，就谈到这里，之后的文档中再讨论。