1 前言
经过多年企业信息化建设，逐步形成的办公系统中还有9个部门业务网站子系统、9个专业应用子系统、20个独立信息模块、330个流程。这些系统或模块分别搭建在Microsoft IIS、Apache Tomcat、Weblogic、Cordys BOP上，相互彼此独立、互不影响。
在不考虑重复投资、资源共享、便于运维的情况下，仍存在一些长期很难解决的问题：
（1）、各个系统的组织、账号不统一，维护困难；
（2）、在一些系统或模块中，对于人员跨部门的情况，仍以两个及以上账号的方式处理，不仅业务不直观，而且操作性比较差；
（3）、虚拟团队支持都是通过开发编码处理，实施周期较长，缺乏灵活性。
由于云计算议题的发烧，在IaaS虚拟化资源池和共用的数据中心内，如何以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离，让多租户技术成为上述需求提供一套解决方案。
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个层次对多租户模型进行划分，即基础设施层（主要是指各种服务器）、数据层（即数据库层）、应用平台层（即应用运行的容器，通常也称为应用服务器）、以及应用逻辑层（即应用功能）。如下图所示：
第一种模型称为“Shared Nothing”，即不共享任何资源。在这种模型中，从最底层的基础设施层，一直到最上端的应用逻辑层，每个租户均独享。这种模式也是传统的IT开发和部署模式。即每个客户均要采购硬件设备，然后在自己的硬件设备上部署其他三层。
第二种模型称为“Shared Hardware”，即共享硬件资源，所有硬件服务器会形成一个硬件资源池，所有租户根据需要来共享这些资源。在这种模型中，主要采用底层虚拟化的技术将硬件服务器虚拟出多份，分配给不同的租户使用。但是其他层次上的内容就需要租户自己采购和部署了。这种模式就是现在比较常见的IaaS模式。
第三种模型称为“Shared OS”，即共享操作系统。在这种模型中，所有硬件资源均安装有相同的操作系统，通过在租户间切分和分配操作系统的进程来实现对计算资源的共享。与第二种模型一样，这种模型也主要集中在对底层计算资源的共享和分配上，而更高层次的内容均是各个租户独享的资源。需要单独购买和部署。
第四种模型称为“Shared Database”，即共享数据库。在这种模型下，所有租户会共享一个数据库，各个租户自己的应用服务器以及运行于其中的应用会使用共享数据库中为该租户划分的数据资源。
第五种模型称为“Shared Container”，即共享容器。注意，在这种模型下，各个租户只是共享应用的运行容器，而应用对应的数据库都是各个租户独享的，这一点与第六种模型是根本性的区别。在这种模型中，要求应用运行的容器是支持多租户访问的，即容器本身可以智能化的区分来自各个租户的请求。虽然不同租户可能都调用同一个功能，即发送同一个API请求给该容器，由于容器本身可以分辨出租户的上下文，因此各个租户调用的请求不会互相混淆，而是会送到租户指定的数据源中，返回正确的数据，绝对不会出现数据泄露的问题。
第六种模型称为“Shared Everything”，即全共享。在这种模型中，所有租户自顶向下共享所有资源。对于提供服务的一方来讲，可以最大限度的利用各种资源，并且依托支持多租户的应用容器，也可以只开发一套程序，部署一次，便可满足所有租户对公共应用的需要。
第六种模型具有最理想的伸缩性，对于公共应用是不二选择。而第五种模型具有比较好的数据隔离效果，因此对于租户特有的应用便是比较理想的部署方式。而其他几种谈到的模型由于没有使用支持多租户的应用容器，因此对于应用层面来讲就是传统的开发和部署方式。即便是公共应用，在这几种模型中，也需要给每个租户部署一遍，而且每个租户必须购买和部署对应的应用容器，无形中对资源也是一种不太合理的划分。
第七种模型称为“Custom Multitenancy”，即定制化的多租户。在这种模型中，实现多租户的方法是在应用逻辑中改造已有的API，增加租户的维度。但是这种模式仅仅是对某一个应用起作用，由于没有使用支持多租户的应用服务器，但是又想让各个租户共享应用容器，所以不得不在应用逻辑中做文章。但是弊端也很明显，如果应用很多，那么每个应用都需要进行相应的改造，对于开发人员来讲，将要付出很多的重复性劳动，使得开发费用攀升。
在信息平台建设中，应当根据具体客户的需要，来构建恰当的多租户模型，为其提供所需的不同服务级别的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
这种模型下，软件服务提供商为每个客户定制一套软件，并为其部署。每个客户使用一个独立的数据库实例和应用服务器实例。数据库中的数据结构和应用的代码可能都根据客户需求做过定制化修改。（多次开发）
（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模式