在IT在系统中使用多租户技术的跨部门和虚拟团队的解决方案为员工提供（草案）
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）虚拟团队管理
从运营平台的角度，统一的、系统的管理虚拟团队。包含团队成员管理、权限管理，这样也存在多角度交叉的问题。都须要在设计时考虑全面。
关于运维管理，限于文档篇幅和主题，就谈到这里，以后的文档中再讨论。
最后，希望本文的讨论，对基于云计算技术进行企业信息化建设起到抛砖引玉的作用，因为时间匆忙，文字及逻辑欠缺的地方。方便时帮着指点一二。
參考文献：
百度百科：多租户技术
百度百科：SaaS模式
