什么是多承租，其优缺点是什么？
从软件的单个共享实例将软件交付给多个客户端组织（或承租者）的能力是 Web 交付解决方案的重要要求。例如，假设有一个由银行服务提供者作为服务提供的简单银行应用程序。本上下文中的多承租 是指从银行应用程序的单个共享实例向多个银行提供银行服务的能力。图 1 说明了从共享的应用程序服务器、数据库、操作系统和物理服务器向两个银行（北卡罗来纳州第一银行和加拿大第二银行）提供的多承租银行服务。
图 1. 使用共享中间件和硬件为银行业务构建的示例 Web 交付的多承租服务
多承租的主要优点是具有成本高效性。在承租者之间共享软件、硬件、应用程序开发和维护成本可以降低每个承租者的成本。而且，在承租者之间共享应用程序的单个实例可以提供其他好处，例如，当升级应用程序时，所有承租者可以同时升级。
不过，多承租也会带来潜在的问题，如：
- 隔离：因为承租者共享软件和硬件的同一实例，所以一个承租者可能会影响其他承租者的软件的可用性和性能。例如，如果共享的软件没有充足的安全保障措施，则可能会发生因一个承租者关闭共享软件而导致对共享该实例的所有承租者拒绝服务。
- 安全性：如果共享软件没有充分的安全保障措施，则一个承租者的用户可能会访问属于另一个承租者的数据。
- 自定义能力：因为软件是在承租者之间共享的，所以各个承租者不可能自定义该软件。例如，在没有充足的扩展点的情况下，一个承租者不可能为业务流程提供自己的实现。
- 应用程序升级将为承租者带来问题：同时升级共享的软件可能并不是所有承租者都希望的。
- 恢复：在承租者之间共享数据库使得很难为每个承租者单独备份和恢复数据。
虽然可以使用多种方法构建多承租体系结构，但本文主要介绍能够共享中间件和数据库的单一实例以及在多个承租者应用程序之间进行共享的技术。
多承租的其他方法包括操作系统 (OS) 级别的虚拟化。例如，VMWare、Xen 或 OpenVZ 允许操作系统的多个虚拟实例在共享的硬件实例上运行。每个虚拟操作系统实例可以执行不同承租者的软件。另一种方法是为每个承租者建立操作系统级别的边界。例如，每个承租者的应用程序可以在 IBM WebSphere® Application Server 的新实例（不同的操作系统进程）中运行。
多承租技术面临的挑战
可以根据面临这些挑战的主要组织和角色对多承租应用程序的技术挑战分类：解决方案开发人员和服务提供者。
解决方案开发人员面临的技术挑战包括：
- 访问控制：如何在承租者之间共享应用程序资源（例如，虚拟门户、数据库表、工作流、Web 服务和 Java™ 2 Platform Enterprise Edition (J2EE) 构件），以便只有属于承租者的用户可以访问属于该承租者的实例？例如，如何确保其他银行（如北卡罗来纳州第一银行）的用户不能访问加拿大第二银行的资源（如虚拟门户）？
- 自定义能力：
- 数据库：在一个承租者不影响其他承租者的情况下，如何自定义共享的数据库模式？例如，在不影响北卡罗来纳州第一银行的模式定义的情况下，加拿大第二银行如何将新的数据字段引入客户概要的共享数据库表？
- 用户界面：如何仅通过配置来自定义网站外观（即，在不更改代码的情况下）？例如，如何确保北卡罗来纳州第一银行和加拿大第二银行的银行管理员可以配置不同的设计，并在其客户概要 Portlet 中显示其他字段？
- 业务逻辑：在不进行代码更改的情况下，如何允许为每个承租者自定义业务逻辑？例如，北卡罗来纳州第一银行如何使用不同于加拿大第二银行的最小信用记录自动拒绝贷款申请？
- 工作流：您如何让承租者银行在共享的工作流中自定义人工任务和其他有条件任务的分配？例如，北卡罗来纳州第一银行如何确保将共享工作流中的贷款审批任务仅分配给北卡罗来纳州第一银行的员工？
- 承租者预置：如何自动执行新承租者的预置？例如，如何使用非常少的手动步骤（即如何自动化创建新的 LDAP 子树或数据库、创建新的虚拟门户、部署 portlet 的新实例和注册新的 IBM DB2® XML 模式之类的步骤）引入新银行（例如 Fairfield Trust 第三银行）？
- 基于使用情况的测定：如何记录服务的使用情况，以便仅根据服务使用情况向每个承租者收取服务使用费？例如，银行服务提供者管理员如何测定承租者北卡罗来纳州第一银行和加拿大第二银行的服务使用情况，以及他们的客户调用贷款申请服务的次数？
服务提供者面临的技术挑战包括：
- 数据库共享、自定义、备份和特定于承租者的数据的恢复：服务提供者如何基于性能、管理和可扩展性标准在不同的数据库划分模式之间进行选择？例如，服务提供者如何满足从多个承租者之间共享的表仅备份自己数据的加拿大第二银行的灾难恢复要求？
- 快速支持现有 Web 服务的多承租：如何在很少或不进行代码更改的情况下使单个承租者的 Web 服务支持多承租？例如，在不对 Web 服务接口和实现进行代码更改的情况下，如何使单个承租者的信用审核服务支持多承租？
- 在大型企业中管理大量的第三方服务提供者和部门服务客户之间的连接性：在 Web 交付的应用程序中，大型企业中的业务部门 (LOB) 表现了承租者的许多特征。同一企业中不同的业务部门可以使用来自不同的第三方或内部服务提供者的服务。在企业中，大量的此类服务提供者可能导致中心 IT 部门的管理问题。例如，银行服务提供者企业中的不同业务部门（如信用额度和抵押贷款部门）可能使用不同的信用审核服务提供者。中心 IT 部门如何监视、授权和测定企业中不同业务部门的多个信用审核服务的使用。
- 可伸缩性改进了硬件使用情况和特定于承租者的服务质量 (QoS)：服务提供者如何改进在不同承租者之间共享的硬件使用和提供可绅缩性？服务提供者如何为不同的承租者提供不同的服务质量？例如，您如何满足有别于加拿大第二银行的服务质量需求，以便使用专用硬件承载其服务并收取较高的服务使用费用？
解决多承租技术问题的模式
您可以应用多项 SOA 技术解决与多承租相关的技术问题。
面向解决方案开发人员的模式
- 从小处入手，使用基于标准的入门级中间件：本系列的后续文章将介绍如何使用 IBM 的入门级中间件开发 Web 交付的多承租应用程序。此入门级的中间件产品组件包括 IBM WebSphere Application Server Community Edition、IBM DB2 Express-C 和 OpenLDAP。为入门级产品组件开发的解决方案可以向服务提供者提供从 IBM 购买支持的选项。观看演示和下载示例代码，获取使用入门级产品组件构建的应用程序。图 2 描述了示例多承租应用程序的不同功能层。本系列的后续文章将介绍如何将入门级产品组件与一些企业级产品组件（如 IBM Tivoli® Usage and Accounting Manager 和 WebSphere Application Server, Extended Edition）合并，以支持测定、可伸缩性和隔离。
图 2. 使用 IBM 中间件构建的示例多承租应用程序中的功能层
- 提升为企业级中间件：虽然从入门级产品组件着手非常容易，但是通常不能够很好地解决高级功能、可伸缩性、性能和集成等问题。因此，要构建任务关键型 Web 交付应用程序，最好使用企业级中间件。在记录的一系列演示（您可以从 SaaS 演示系列访问）中，我们描述了用来开发 Web 交付的多承租解决方案的企业级 IBM 中间件产品组件的多个功能和技术。每个演示的其他技术细节包括在参考资料部分列出的一系列文章中。演示系列中的主题包括：
图 3 显示了入门级产品组件和企业级产品组件中的不同 IBM 中间件产品如何处理这些功能层。
图 3. 用于实现使用 IBM 中间件构建的示例多承租应用程序中的功能层的 IBM 中间件产品
本系列文章基于上面的文章和演示，描述了使用 IBM 中间件构建多承租应用程序的一些高级技术。例如，其中一篇文章将演示如何在 WebSphere Process Server 中隔离共享的多承租工作流中的人工任务。另一篇文章将描述如何使用 Tivoli Usage and Accounting Manager 提供基于使用情况的测定和计费解决方案。
面向服务提供者的模式
- 选择适当级别的数据层隔离，以获取自定义能力和方便地进行承租者数据管理：服务提供者可以选择：
- 将每个承租者的数据隔离到不同的数据库。
- 将每个承租者的数据隔离到独立的表和模式。
- 在所有承租者之间共享一组相同的表和模式。
在承租者之间共享模式时，自定义每个承租者的数据字段是一项难以应对的问题。本系列的后续文章将评估一组从许多方面解决这些问题的模式，其中包括性能、管理和可伸缩性。IT 还演示了一些改进可管理性的技巧，例如，介绍在所有承租者之间共享模式时，如何适应特定于承租者的数据的备份和恢复。
- 使用 IBM WebSphere Enterprise Service Bus、IBM WebSphere Business Services Fabric 或 IBM WebSphere DataPower® SOA Appliances 为现有 Web 服务快速启用多承租： 服务提供者可能需要为现有 Web 服务快速启用多承租。为从头启用多承租，在现有实现中进行代码更改可能需要进行大量的工作。然而，可以构建基于中间件的中介层，使不同承租者的服务请求支持不同的 Web 服务端点。在本例中，不需要修改现有 Web 服务实现。本系列的后续文章将演示如何使用 WebSphere Business Services Fabric、WebSphere Enterprise Services Bus 和 WebSphere DataPower SOA Appliances 实现此模式。
- 在大型企业中，通过中心中介层路由第三方 SaaS 服务调用：企业 IT 部门可以使用中心中介层从组织中的不同部门路由所有第三方服务调用。此类中介层可提供其他功能，如对服务使用的授权、监视和测定。本系列的后续文章将演示基于企业服务总线 (ESB) 的中介模式如何支持此类需求。
- 使用 IBM WebSphere Application Server, Extended Edition 扩展入门级中间件，并改进硬件的使用：在开始时，通常没有充分考虑可伸缩性需求。当这些需求变得日益重要时，服务提供者通常使用大量的低成本小型服务器进行扩展。不过，扩展可能会带来其他问题。例如，此方法可能会产生以下任一问题：
- 为支持个别承租者少有的峰值负载导致提供过多硬件。
- 由于大量的中间件实例，增加了管理的复杂性。
- 隔离不同承租者的应用程序，并使用 WebSphere Application Server, Extended Edition 支持特定于承租者的 QoS 需求：通过利用 IBM WebSphere Extended Deployment 中的服务器隔离策略，在共享硬件中运行其他承租者的应用程序时，服务提供者可以将承租者的应用程序隔离到专用硬件中。此外，解决方案开发人员可以利用 WebSphere Extended Deployment 中的 WebSphere Partitioning Facility 功能的编程模型构建支持多承租的应用程序。后续文章将演示如何使用 WebSphere Extended Deployment 支持特定于承租者的 QoS 需求和用于多承租的分区应用程序。
 |
结束语
可扩展的多承租是 Web 交付 (SaaS) 解决方案的重要需求。不过，构建多承租解决方案还需要解决若干技术难题。使用 IBM 中间件，解决方案开发人员和服务提供者可以构建和部署可扩展、可自定义和可管理的成本高效的多承租解决方案。本系列的文章将介绍几个相关的 IBM 中间件功能和技术，并描述如何应用它们，以解决上述的技术难题。请继续关注！
参考资料
学习
获得产品和技术
讨论
作者简介
|
|
|
|
German Goldszmidt 博士是 IBM 软件部的一位杰出工程师，其研究重点是用于交付、自定义和部署 SOA 组合应用程序来支持业务服务的集成平台的体系结构。之前他曾在 IBM T.J. Watson Research Center 担任研究人员，并曾带领团队进行多种技术的设计和实现工作，包括 Océano（自主计算 eUtility 的第一个原型）和 Network Dispatcher（WebSphere 产品的负载平衡组件）。
|
|
|
|
|
Indrajit Poddar 是一位顾问软件工程师，现在是 IBM 软件部策略与技术团队的一名成员。他感兴趣的是采用面向服务的体系结构和 IBM Software Group 产品组合（WebSphere Application Server、Process Server, Portal Server 和 Tivoli and Rational 产品）来设计复合应用程序的体系结构。他获得了宾夕法尼亚州立大学的计算机科学与工程学士学位，以及位于印度坎普尔市的印度科技大学计算机科学与工程硕士学位。
|
|
