本系列的第
1 部分讨论了多租户是什么，介绍了构建和部署多租户 Web 交付解决方案的一些技术困难。在本文中，我们将介绍在
Web 交付解决方案（也称为 software-as-a-service）中启用多租户的五种代表性方法，并比较它们的成本和收益。
在为现有或新的多租户服务设计 web 交付时，服务供应商常常面对许多设计选择。图 1 显示了五种主要方法。方法
1 是所有租户共享单一应用程序实例，也就是相同的服务器、中间件和应用程序。方法 5 是租户在单独的服务器上运行自己的应用程序实例（当前许多
Application Service Provider [ASP] 采用这种方法）。在这两种方法之间，还有至少三种主要方法，它们具有不同的资源共享程度和开发复杂性。每种方法提供不同的收益（在可伸缩性和运营效率方面），需要不同的成本（在开发复杂性和投入市场的时间方面）。
图 1. 启用多租户的五种主要方法
在本文中，我们将使用多种角色描述启用多租户的不同方法：
- 服务供应商：负责以 web 交付模型提供服务/解决方案
- 服务开发人员：服务/解决方案的开发人员
- 租户：服务供应商的客户
- 最终用户：租户可能有一个或多个服务/解决方案用户
服务供应商可以使用以下五种主要方法：
- 包含单一应用程序实例的共享中间件
- 包含多个应用程序实例和共享地址空间的共享中间件
- 包含多个应用程序实例和单独地址空间的共享中间件
- 用与租户相关的虚拟映像实现虚拟化
a). 用中介层实现虚拟化
- 在单独的服务器上运行多个实例的 ASP 模型
下面几节详细描述这五种方法。在决定采用哪种方法时，了解每种方法的成本和收益会有帮助。我们在后面的一节中提供成本/收益分析。
方法 1、2 和 3 都在多个租户之间共享中间件和应用程序组件，只是程度不同。下面看看每种方法的示例。
方法 1：包含单一应用程序实例的共享中间件
所有租户共享操作系统、服务器以及中间件和应用程序的单一实例。实现的方法是用租户标识参数对应用程序的单一实例进行参数化。例如，如果应用程序有
web 服务接口和实现，那么在接口中的操作和数据对象中添加租户 ID 参数。如果应用程序使用数据库表，那么在每个数据库表中添加一个表示租户
ID 的新列。在这个模型中，有一些配置元素对于每个租户是独特的。例如，虚拟门户为每个租户提供不同的外观和感觉以及独特的数据库模式元素。
图 2. 方法 1 的拓扑示例（在多个租户之间共享应用程序和中间件的单一实例）
图 2 中显示一个使用这种方法的拓扑示例。这里有三个租户：A、B 和 C，他们共享 Application
1 的相同代码。Application 1 使用在 Blade 服务器上的 Windows 上运行的 Tomcat
和 DB2，以及在另一台物理服务器上的 Linux 上运行的 Apache HTTP 服务器。所有租户共享中间件、操作系统和服务器。可以从
“Building
Web delivered SaaS applications on open source and entry
level IBM middleware” 下载一个使用这种方法的多租户示例应用程序。当一个租户出现时，为他创建相关的配置（例如
CSS 文件），但是只有一个应用程序实例，由所有租户共享。在使用这种方法时，应用程序必须能够把每个租户的数据和配置隔离开。本系列的第
3 部分和第 4 部分讨论在使用这种方法启用多租户时重要的体系结构考虑因素（使用 IBM WebSphere
Application Server）。
方法 2：包含共享地址空间中的多个应用程序实例的共享中间件
租户使用应用程序的不同实例，这些实例部署在中间件的单一实例中，共享单一操作系统进程（地址空间）。租户共享操作系统和服务器。在图
3 中，租户 A、B 和 C 使用这种方法共享一个示例应用程序。
图 3. 方法 2 的拓扑示例（对于不同的租户，在中间件的单一实例中运行应用程序的不同实例）
当新的租户出现时，创建一个单独的应用程序拷贝，指定一个包含租户标识符的名称，把它部署到应用服务器的共享实例中。例如，复制
Application App 的 ear 文件 (App.ear) 并分别命名为 App1.ear 和
App2.ear。同样，在数据库层，对于租户 A 和 B，把应用程序表 App_table 分别复制为
App1_table 和 App2_table。与租户相关的定制（例如 CSS 文件和表模式）添加到与租户相关的应用程序和表拷贝中。这个模型要求在中间件层维持租户隔离。
方法 3：包含单独地址空间中的多个应用程序实例的共享中间件
租户使用应用程序的不同实例，这些实例部署在中间件的不同实例中。租户共享操作系统和服务器。因为中间件实例是不同的，所以每个租户有自己的操作系统进程（地址空间）。因此，这个模型要求在操作系统层维持租户隔离。这种方法在相同的物理服务器上支持的租户数量比方法
1 和 2 少。在三种共享中间件方法中，这种方法提供最强的租户隔离。但是，在操作系统和服务器层仍然有隔离问题，例如一个租户的用户有可能占用物理服务器中的所有
CPU 和内存。
图 4. 方法 3 的拓扑示例（对于不同的租户，在中间件的不同实例中运行应用程序的不同实例）
在图 4 中的示例中，每个租户（A、B 和 C）运行自己的应用程序物理拷贝（分别为 App1、App2
和 App3），这些拷贝部署在自己的中间件物理拷贝中（分别为 M1、M2 和 M3）。租户 A 和 B
在 Windows 上运行应用程序，而租户 C 在 Linux 上运行应用程序。在三种共享中间件方法中，这种方法需要对现有应用程序做的修改最少，这有助于加快部署速度。在
SaaS Blueprints 系列即将推出的一个演示程序中，会给出一个采用这种方法的示例，它使用 WebSphere
Smash 和 MySQL 作为中间件，运行一个租户 phpBB 公告牌应用程序。
使用虚拟化技术在共享服务器上运行多个操作系统分区，对于每个租户分配专用的应用程序和中间件实例。
方法 4：用多个
VM 映像实现虚拟化
租户使用不同的虚拟映像以及不同的应用程序、中间件和操作系统实例，但是共享物理服务器。在近几年，服务器虚拟化技术在基于
x86 的服务器上得到了广泛应用，正在迅速地成为一种低成本的日常技术。
与共享中间件方法相比，服务器虚拟化不需要为启用多租户进行大量代码开发。在物理服务器（主机）上安装服务器虚拟化之后，对于每个租户，服务供应商实例化一个虚拟服务器（访客），它包含与这个租户相关的软件，包括中间件和应用程序。
多租户的技术困难之一是供应新的租户。为了供应新的租户，服务供应商必须执行可能漫长且复杂的安装和配置步骤。可以采用
Virtual appliances（例如，VMWare Virtual Appliance for WebSphere
Application Server Network Deployment V7.0 Open Beta），在其中包含预先配置的与租户相关的操作系统和中间件，这有助于解决供应问题。
图 5 给出一个采用这种方法的示例，其中在物理服务器上安装了本机系统管理程序（比如 VMWare ESX™
或 Xen）。在这个示例中，底部绿框中的物理 blade 服务器 A 有两个频率为 2 Ghz 的 CPU，它被分为两个虚拟
blade 服务器（黑框中的 vBlade 1 和 vBlade 2），每个虚拟服务器各有一个 2 Ghz
的 CPU。虚拟 blade 服务器 vBlade 3 包含整个服务器 B，有 4 个 2Ghz CPU。虚拟服务器还共享物理服务器的其他资源，比如内存、磁盘空间和网络连接。应用程序
App4 和 App5 部署在 vBlade 1 和 vBlade 2 中，为两个租户服务，App6 部署在
vBlade 3 中。注意，租户可以使用不同的操作系统。
图 5. 通过基于本机系统管理程序的服务器虚拟化启用多租户
方法 4a：用中介层实现虚拟化
服务供应商在一个中介代理层中集中地执行通用的多租户功能，比如路由、访问控制和度量。中介层可以与虚拟化方法相结合，把它与在单独虚拟映像分区中运行的租户相关服务实例集成起来。中介代理层位于应用程序的最终用户和应用程序中的服务之间，它动态地把来自租户的用户的服务请求绑定或路由到与租户相关的服务实例，见图
6。
图 6 描述一个中介方法示例，其中服务供应商使用 WebSphere DataPower SOA appliance
(WDP) 实现中介代理层。在这个示例中，在 WDP web 服务代理中配置路由规则，这些规则把两个租户（A
和 B）的用户的请求路由到相应的应用程序实例。另外，通过集成 Tivoli Access Manager
和 Tivoli Usage and Accounting Manager 等其他中间件组件，添加了度量、访问控制和审计等多租户功能。
图 6. 中介方法的示例（使用 WebSphere DataPower
SOA appliances 启用多租户）
在本系列的第 5、6、7 和 8 部分中，我们将介绍实现这种方法的三种方式，使用以下产品组合：
- WebSphere Business Services Fabric
- WebSphere DataPower SOA appliances 和 Tivoli Access
Manager
- WebSphere Enterprise Services Bus 和 WebSphere Service
Registry and Repository
方法 5：在单独的服务器上运行多个实例的
ASP 模型
租户只共享数据中心的基础结构（比如供电和制冷），但是使用应用程序、中间件、操作系统和服务器的不同实例。在图
7 所示的示例中，租户 A、B 和 C 使用三个不同的应用程序实例 AppA、AppB 和 AppC，它们在与租户相关的中间件实例、操作系统实例和物理服务器上运行。这种方法最适合那些要求为不同的租户提供充分隔离和定制的工作负载和场景。
图 7. ASP 模型的示例（通过在单独的服务器上运行多个实例启用多租户）
本节从服务供应商和服务开发人员的角度考虑成本-收益分析。
对于服务供应商来说，在为大量租户提供服务时，方法 5（即 ASP 方法）的成本是最高的。在其他四种方法中，随着资源共享程度的提高，经济有效性和规模效益会依次提高，见图
1 中的两个黄色箭头。ASP 方法会导致以下与租户相关的成本类型：
- 物理服务器：每个租户需要专用的服务器、磁盘空间和辅助设备。
- 管理：服务器和某些软件需要连续维护，比如安装安全补丁、升级操作系统和中间件、用户账号管理等等。必须在每个租户的基础结构上单独地执行这些任务。
- 运营：运行数据中心需要与电力、制冷和房地产相关的许多成本，在增加租户时成本会显著增加。
但是，对于服务开发人员来说，这种方法的成本是最低的，因为不需要为启用多租户修改应用程序。另外，这种方法为与租户相关的实例提供最强的隔离和定制能力。
方法 1 到 3（即共享中间件方法）的运营成本是三种共享模型中最低的，因为随着资源共享程度的提高（服务器、中间件和操作系统），要管理的组件数量会减少。这些方法还提供规模效益，因为驻留在单一物理服务器上的租户数量最高。对于服务开发人员，方法
1（单一应用程序实例）的成本最高，因为它可能要求重新设计现有的应用程序，需要很长的开发时间和很大的成本。另外，它要求了解高级的应用服务器特性和技术，需要非常有经验的开发人员。
对于服务开发人员，方法 4（即多个虚拟映像）的成本比共享中间件方法（方法 1-3）低，因为需要的应用程序修改很少，甚至不需要。这样就可以更快地把服务投入市场。在虚拟化方法中添加中介层（方法
4a）也会降低复杂性，减少集成其他多租户功能（比如访问控制和度量）所需的时间。
表 1 提供共享中间件方法（方法 1-3）和虚拟化方法（4 和 4a）的成本收益对比。
表 1. 共享中间件方法和虚拟化方法的成本收益对比
| |
共享中间件方法 |
虚拟化和带中介的虚拟化 |
| 收益 |
- 能够快速扩展，支持更多的租户
- 经济有效，因为所有租户共享基础结构
- 与虚拟化或中介方法相比，开销低
|
- 不需要重新设计 应用程序
- 只需修改少量集成代码，即可高效地启用更多通用的多租户特性，比如：
- 访问控制
- 度量
- 处理和转换与租户相关的应用程序中协议和接口方面的差异
- 加快 投入市场的速度，降低 前期成本
- 良好的租户隔离，提供更好的安全性 和可用性
- 与共享的环境相比，提供更高的硬件和操作系统定制 程度
- 支持租户应用程序使用不同的 操作系统和硬件
- 比较容易把应用程序重新定位 到另一个平台
- 比较容易为每个租户执行备份 和灾难恢复
|
| 成本 |
- 在方法 1 中，需要对现有的租户代码进行重新设计 或修改代码
- 重新设计应用程序会影响多租户投入市场的时间
- 如果需要修改代码，前期成本会比较高
- 实现方法 1 需要经验丰富的程序员
- 为每个租户提供定制的备份和恢复等特性会增加复杂性
|
- 可伸缩性低，每个服务器支持的租户数量少
- 性能开销比较大
- 运营成本 和管理成本比较高，因为需要虚拟机器映像的多个实例
- 在部署到中介层时，部署成本比较高
|
从传统的应用程序服务供应商模型迁移到 web 交付模型有多种方法，这些方法对于服务供应商和服务开发人员有不同的成本和收益。我们讨论了五种主要方法，它们具有不同的资源共享程度和开发复杂性。这个迁移过程的目标是提高经济有效性和降低总拥有成本。本文讨论了各种方法的优缺点，有助于您选择合适的方法并准备适当的体系结构，从而逐步实现这些目标。
作者要感谢 IBM Research 的 Ajay Mohindra 和 Suresh N. Chari，他们为描述主要多租户方法的图
1 做出了贡献。
学习
获得产品和技术
| 
