简介：
作者们分享了他们将单租户 SOA 应用程序转换为多租户云应用程序的过程中获得的经验；这些最佳实践共包含
7 个重要的技巧。
作为专业技术人员，我们的目标之一就是分享我们的经验和教训，在本例中，这些知识来自构建可以在
IBM? SmartCloud Enterprise 产品上运行的多租户应用程序所涉及的相关工作。尤其值得一提的是，我们将介绍用于将现有单租户
SOA 应用程序转换为多租户软件即服务 (SaaS) 应用程序的一些技术。
我们最终还是希望有人能够开发出一些工具，帮助开发人员自动完成从单租户应用程序向多租户应用程序的复杂转换。
首先，我们来测试一下来自 IBM Perspective（我们对此相当熟悉）的一些传统解决方案。
IBM 行业解决方案
IBM 提供了包含丰富功能的广泛而又深入的软件产品组合。此外，根据客户的反馈，我们可以确信，IBM
是惟一一家能够将这些功能组合起来，提供帮助客户解决特定业务问题的开箱即用行业解决方案的公司。这样，客户就能减少所花费的时间，并通过集成
IBM 提供的软件产品来满足其特定业务需求。
很多此类解决方案在开发过程中都遵循 IBM SOA Reference
Architecture。例如：
1.可以使用门户将应用程序的组件整合到一个单独的视图中，这样，人们就能够基于其角色，与公司的业务或者
IT 服务进行协作与互动。
2.当集成并连接服务时，企业服务总线可以提供较好的灵活性。
3.一些安全规则（比如身份、身份验证、授权、审计和合规性）可应用于整个面向服务生命期。
4.对关键性能指标进行实时监测，这样，解决方案就能获取预防、隔离、诊断和修复问题所需的信息。
5.业务分析可用于发现微妙的关联，帮助解决方案制定正确的决策。
6.通过集成的门户来设计、定制和使用报告。
试想一下，通过组合包含了 WebSphere? Portal、Lotus?
Sametime、Cognos Business Intelligence WebSphere MQ、WebSphere
Message Broker、Business Process Management、Tivoli? Asset
Manager、DB2?、Rational? 等产品的软件产品提供的功能来创造新的、开箱即用解决方案的情形。
那么，接下来的挑战是...
如何利用现有的、没有自己的租户概念的企业产品来创建一个多租户 SaaS
应用程序，尤其在需要扩大规模来支持解决方案中的越来越多的租户的时候？
最近，我们正与我们的 Industry Solutions 团队一起进行开发工作，工作内容就是将单租户
SOA 解决方案转换为多租户 SOA 解决方案，从而能够真正地将该解决方案作为 SaaS 解决方案部署到
IBM SmartCloud Enterprise 中。尽管一个 SOA 解决方案可以采用很多 IBM
中间件产品，并且将其转换成多租户可能令人生畏，但是 IBM 中间件产品的可扩展性确实将这一转换变得相当简单。
如果您想将现有的单租户解决方案转换成多租户 SaaS 解决方案，本文描述的技术和见解对您可能很有用。
我们先来了解一下多租户的概念。
多租户的概念
大大小小的公司，包括 ISV，都花费越来越多的精力来探索基于云的解决方案和
SaaS，将它们作为其交付模式。在 IBM 软件产品组合内部，有多个用于创建新的 Saas 产品的方法。
方法之一是从头创造新的产品，将它作为 SaaS 解决方案来提供；例如，IBM
Blueworks Live。还有一个方法是将原有的内部、企业级产品 “转化” 为 SaaS 解决方案；例如，Commerce-as-a-Service、Cognos
和 IBM SmartCloud for Social Business（以前的 LotusLive?）。
对于第一种方法，往往需要从头开始构建多租户。对于第二种方法，原有的内部产品可能不包含租户的概念，但可以通过采用自定义配置来实现多租户。
我们来看几个常见的多租户场景，以加强我们对租户基本概念的理解。
常见多租户场景
我们已经在前面的文章中讨论过了多租户的一般概念（请参阅 参考资料）。我们需要知道一个关键概念，就是关于资源共享有多种多样的可能性。
图 1 定义了云环境中有关多租户的技术堆栈。
图 1. 依据资源共享级别来定义的多租户
正如您所见，多租户场景包括：
- 不共享资源。
- 共享硬件资源。
- 共享操作系统。
- 共享中间件。
- 共享应用程序
我们来看一下每一项的细节。
场景 1：不共享资源。每个租户都有自己一套完整的应用程序、中间件、操作系统和基础架构（硬件）。每个租户与其他租户完全隔离，惟一的例外是它能够在相同的物理数据中心中运行。
场景 2：共享硬件。租户开始共享一个数据中心的基础架构。例如，租户可以共享数据中心中的服务器（比如，Intel?、Power）、存储（SONAS?、NetApp?）和网络（Juniper、Cisco）。
场景 3：共享操作系统。租户现在共享基础架构和操作系统。KVM 与 VMware?
之类的管理程序通常用于硬件虚拟化，以便实现在硬件上运行多个操作系统。租户之间仍然保持相当程度的隔离，因为每个租户可以拥有各自版本的应用服务器、数据库服务器和及应用程序。这个级别的共享还叫做基础架构即服务
(IaaS)。
场景 4：共享中间件。租户现在开始共享一系列运行在共享的操作系统和基础架构之上的中间件服务；例如，安全服务、门户、数据库服务、监测服务，等等。各种应用程序都能够构建在这些共享的中间件组件之上。这一级别的共享还叫做平台即服务
(PaaS)。
场景 5：共享应用程序。租户现在与其他租户共享相同的应用程序。基于这种共享，租户之间还可以共享相同的中间件，包括用于实现该应用程序的版本。虽然租户之间共享相同的底层资源，但他们彼此之间仍然是独立的。一个租户看不到其他租户的资产（比如存储在数据库服务器或者文件服务器中的数据）。这一级别的共享还叫做软件即服务
(SaaS)。
通常，多租户所指的级别越高（意思是在场景 5 中，共享应用程序），创建新租户时所需做的工作越少，因为已经共享了更多的底层堆栈。对于任何计划向越来越多租户提供的业务来说，在扩大规模时不需要增加大量技术和业务资源，这是首要考虑的问题。对于厂商和租户来说，共享相同的代码库能够缩短实现价值的时间，并能使新的创意在几周之内（而不是几月或几年之内）完成部署。
我们前面曾提到过，有些单租户软件解决方案在其设计之初不包含本地租户的概念；在正式介绍
7 项技术之前，我们先来讨论一下如何解决将单租户软件转化为多租户解决方案的问题。
隔离能够变相地创建一个租户
虽然我们提到的软件中都没有明确的租户概念（或者，租户当中用户的概念），每个产品都包含内建的、有关隔离的概念，这就可能运用到多租户解决方案中。
例如，在关于利用 Rational Asset Manager 来获取协作多租户最佳实践的文章（“Best
practices for cloud-based asset-centriccollaboration”，参阅
参考资料）中，描述了如何利用 Rational Asset Manager 中的资产社区的概念来获取资产隔离，并在租户之间共享资产。可以为租户创建资产社区，而来自租户的用户可以在该社区中发布资产；但是，默认情况下，来自其他租户的用户看不到也不能访问这些资产。
对于前面提到 IBM 产品的剩余部分而言，可以应用类似的方法来处理它们。因为
IBM 软件具有可扩展性，所以可以采用产品的 API 来实现自定义。
基于这一概念，我们现在来看一下用来转换租户的 7 项技术。
用于转换为多租户的 7 项技术
在转换 SOA 解决方案的工作当中，我们确定了 7 项技术，在将单租户应用程序转换成为构建于
IBM 中间件产品之上的完整多租户 SaaS 应用程序时，这些技术可能非常有用。这些技术包括：
1.共享 LDAP
2.单点登录
3.共享数据库服务器
4.共享企业服务总线
5.租户特定报告
6.租户特定日志文件
7.基于 WebSphere Portal 的统一用户界面
详细看一下每一项的内容
共享 LDAP
想要创建多租户环境，首先要部署的就是共享 LDAP，这样就有了一个专门用来对用户和组织信息进行持续管理的区域。IBM
Tivoli Directory Server 是较常用的 LDAP 实现技术。所有 IBM 软件产品都已提供了与
Tivoli Directory Server 的集成能力，所以，目前很多现有的安装资产都可以使用。
还有几个地方需要注意。通常，每个产品都有自己的默认 LDAP 目录结构和属性，这些结构和属性针对专用于产品的搜索过滤器结构进行了优化。在许多产品之间共享这
LDAP 时，就需要进行一些标准化处理并调整这些默认设置。
例如，注意大小写：有些产品会忽略大小写，有些则不然，具体体现在以下方面：
cn=users, o=ibm, c=us
与：
cn=Users, o=IBM, c=US
单点登录
单点登录 (SSO) 允许租户登录一次，就可以访问所有的系统，而不必在每个系统中都登录一次。由于很多中间件产品都构建在
WebSphere Application Server (WAS) 之上，因此，可以采用 IBM Lightweight
Third-Party Authentication (LTPA) 技术，并且在能够在基于浏览器的环境中很有效地运行。
图 2 展示了整个流程的一个示例。
图 2. 在多个采用 LTPA 令牌的服务器之间实现单点登录
当一个 HTTP 请求到达时，WebSEAL 与 Tivoli Access
Manager Policy Server 协同工作来确定所请求的资源是否受到保护。如果资源受保护，那么
WebSEAL 会确保在允许请求到达应用程序之前对用户进行身份验证；例如，一个在 WebSphere Portal
中运行的 portlet。
如果该 portlet 需要访问其他服务器，例如 Sametime Community
Server，那么共享的 LTPA 令牌就会标识出已经通过 WebSEAL 进行身份验证的用户；不需要对用户重新进行身份验证。
虽然 LTPA 令牌是用来在 WebSphere 应用服务器之间实现 SSO
的标准技术，但在云中实际部署这一系统时，还必须非常谨慎。我们在部署该解决方案时会遇到一些挑战。
通常会从一个系统（例如，WebSEAL）中导出 LTPA 密钥文件，然后将它导入另一个系统中（例如，WebSphere
Portal 和 Domino server）。重要的是，这个密钥文件要采用一致的方式来描述共享的 LDAP，例如，采用一个完全合格的域名：
com.ibm.websphere.ltpa.Realm=vhost1111.site1.compute.ihost.com\:389
如果服务器采用了别名，并导出一个带有该别名的 LTPA 密钥，但是其他服务器不支持使用别名，那么
SSO 将无法正常工作。
在指示 LTPA 令牌已经到期的日志文件中，可能会看见一个错误。当每个虚拟机上设置的操作系统时间不一致时，就会出现这一错误。例如，如果在
WebSEAL VM 上的时间设置为 10:00，而在 Portal VM 上时间设置为 1:00，那么，当
Portal 服务器打开令牌并将其与本地时间对比时，就会认为令牌已经过期了。
这一问题在 IBM SmartCloud 环境当中相当突出，因为无法确保在虚拟机中的规定的时间保持相同。必须采用额外的步骤在每个虚拟机中重置或重新同步时钟，将它们设置为相同的时间和相同的时区，从而确保
SSO 能够正常工作。
在测试整个流程之前，我们建议先进行成对 SSO 测试。例如，确保 SSO
已在下面两个系统之间正常工作：
WebSEAL 与 Portal
WebSEAL 与 Sametime
Portal 与 Sametime
当这些生效时，再测试整个路径 WebSEAL > Portal >
Sametime。在 SOA 解决方案中涉及多台服务器，因此，需要先采用一个系统方法进行测试，然后再重复该测试，这是成功管理云环境当中各类错误的关键要素。
共享数据库服务器
在多租户环境当中需要考虑的第三件事是如何隔离不同租户的数据。假设单租户应用程序正采用
DB2 之类的关系数据库，那么这一任务就相当简单了。
图 3 给出了一些常见的模式。
图 3. 多租户数据库模式
1.每个租户有自己的数据库。
2.在单个数据库中，每个租户有自己的模式。
3.所有租户共享相同的数据库。
第一个场景中，需要对应用程序进行极少的改动就能识别租户概念。通常，您只需确保应用程序已经基于租户
ID 连接到正确的租户特定数据库。
场景 1 还提供了租户间最彻底的隔离。例如，可在不同的计划中对租户 1
和租户 2 的数据库进行存档。
如果由于现有数据库连接的设计问题，使得应用程序具有自己的元数据概念，并且需要存储在同一数据库中的用户数据，那么第
2 个场景会比较典型。在这种情况下，应当考虑利用同一数据库中的不同架构来分隔租户数据，并且应该将所需的重新设计工作减至最少。
第 3 个场景需要大量的应用程序变更和表设计。必须在表设计当中融入租户
ID 的概念，这样应用程序就能够基于租户 ID 来仔细研究为特定租户而更新或者检索的数据。这一场景的典型应用是设计之初就用作
SaaS 产品的应用程序。
共享企业服务总线
企业服务总线 (ESB) 通过从服务实现中解耦用户服务视图来支持 SOA
实现概念。
如果从实际实现中解耦客户服务视图，则有利于提高架构的灵活性。因此，当利用一个服务提供者替代另一个服务提供者时，客户不需要考虑架构的变更或替换。
有很多的 ESB 模式和相应的产品映射（请参阅 参考资料 中的相关红皮书）。我们当前的项目专注于利用
WebSphere MQ 和 WebSphere Message Broker 的典型拓扑。
WebSphere MQ 便于实现应用程序之间的通讯。WebSphere
MQ 中的队列可以作为应用程序之间交换的消息的容器。队列管理器管理着队列并且可作为队列的容器。WebSphere
Message Broker 扩展了 WebSphere MQ，可利用中介规则来操纵队列中的消息。
在一个多租户系统中，所有租户共享单个 WebSphere MQ 和 WebSphere
Message Broker 实例。在这种情况下，某个租户发送的信息必须与他租户隔离。实现这一隔离的方法之一是为每个租户设置单独的队列管理器。租户特定队列管理器中的队列是相互隔离的，从而隔离了经过队列的消息。可以对队列管理器进行单独管理，这样，影响一个租户队列基础架构的问题就不会影响其他租户。
多租户系统当中的每个租户都可以有不同的中介规则集。为了让每个租户都有自己的中介规则，租户特定队列管理器可与客户租户特定中介规则相关联。这允许不同租户的中介规则相互隔离。
图 4 展示了在同一 ESB 实例当中运行两个不同租户的总体思路。
图 4. 多租户企业服务总线样式
租户特定报告
所有解决方案都需要报告。IBM Cognos Business Intelligence
(BI) 提供全面的查询和报告功能，使得用户能够创建报告，并分析数据，制定出更好的商业决策。此外，Cognos
BI 是一个成熟的平台，可以在能实现多客户共享资源的多租户环境中运行。
Cognos BI 将报告和报告元数据组合到文件夹结构中。通过数据源连接对象，报告能够访问被请求的数据，该对象为报告中所展示的数据定义了访问参数。
在所有租户共享一个 Cognos BI 实例的多租户环境中，可通过创建租户特定文件夹和数据源连接来实现租户之间的隔离。来自租户的用户仅能访问为该租户创建的文件夹和数据源连接。这强制了租户之间的隔离，这样它们就无法查看彼此的数据或者报告。
IBM Cognos Software Development Kit
使得开发人员能够无缝地实现多租户，并将 Cognos 功能集成到其多租户应用程序当中。例如，当有新租户注册时，激活处理程序会通过发起
Web 服务调用来透明地访问 Cognos BI，从而创建仅有该租户可见的新文件夹和数据源连接。
租户特定日志文件
由于租户共享相同的中间件，所以需要着重考虑如何将各个租户的日志文件分开，让每个租户仅能访问由其自身执行所生成的日志消息。根据租户来分出跟踪文件和日志文件，有助于
SaaS 管理员排除特定账户的故障。
可通过简单地扩展 WebSphere 日志框架来创建租户特定日志文件。此外，每个产品都有不同的目录结构，因此，不同产品存储日志文件的位置不同。
日志聚合工具能够帮助租户将多个软件产品的日志文件聚合到单个归档文件中。
基于 WebSphere Portal 的统一租户界面
WebSphere Portal 能够统一展现不同的、用于集成到一个 SOA
解决方案中的不同组件、应用程序、流程和内容。例如，在 图 2 当中，可通过 WebSphere Portal
来实现无缝单点登录体验，这样，在用户登录到门户当中后，无需重新输入用户 ID 和密码，便可访问所有相关的软件。
此外，我们发现以下 WebSphere Portal 功能对于创建多租户应用程序特别有用：
门户组件模型 portlets 支持创建可在多 SaaS 应用程序中使用的可重用组件。它提供一种标准编程模式，这样租户就能通过提供其自定义
portlets 便捷地扩展 SaaS 解决方案。
通过门户自定义，租户就可以通过修改样式表来自定义其具有个性外观的 UI。
可以基于角色访问 portlets。当向租户增加用户时，可通过在共享 LDAP
中设置其各自的角色，自动为用户提供正确的 portlets；例如，公司管理员与公司销售。
移动及多设备支持。可通过移动设备来访问大多数 SaaS 应用程序。IBM
Mobile Portal Accelerator 使得您能够在不需要针对设备进行开发的情况下快速支持多个设备。
WebSphere Portal 7.0 对门户场 (portal farm)
的支持使得它特别适合在云环境中运行。门户场是门户服务器的一系列独立实例，有点像传统的集群，但在管理和升级时要方便很多。可根据性能要求自动地扩大或缩小场的规模。
结束语
在本文当中，我们继续分享了我们在构建运行于 IBM SmartCloud
Enterprise 之上的多租户应用程序的过程中获得的经验与教训。
尤其值得一提的是，我们描述了用来将现有单租户 SOA 应用程序转换为多租户
SaaS 应用程序的技术。我们希望随着时间的推移，随着 SaaS 市场的日趋成熟，能够出现一些新的工具来帮助完成更复杂的转换。。
参考资料
1.深入了解 IBM 软件行业解决方案。
2.描述多租户的两篇文章包括 Best practices to architect
applications in the IBM Cloud 和 基于云的、以资产为中心的协作最佳实践。
3.红皮书 Patterns: SOA Design Using WebSphere
Message Broker and WebSphere ESB 解释了如何使用 IBM Tivoli
Directory Server LDAP 实现。
4.查找更多关于 Cognos Business Intelligence
的信息。
5.查找更多关于 IBM Mobile Portal Accelerator
的信息。
6.查找更多关于 WebSphere Portal farm topologies
的信息。
7.文章 将您的 web 应用程序转化为多租户 SaaS 解决方案 详细介绍将
Web 应用快速转换成云应用程序的思路与步骤。文中还着重介绍了来自 Corent 用于协助完成任务的工具。
|
