内容


面向服务环境中的解决方案隔离

Comments

简介

人们总是对服务方向的架构方面和服务方向如何影响 IT 解决方案的开发给予极大关注,但对面向服务架构(SOA)对企业的操作环境及其相关流程的影响却不够关注。服务的好处之一是它们可以跨多个业务线和多个 IT 解决方案重用,意味着同一个逻辑可以服务多种不同的用途和场景。这不仅适用于服务本身,还适用于其他支持组件,比如 Enterprise Service Bus (ESB) 中存在的中介组件。

由于所有这些组件都位于操作环境中的某个地方,因此解决方案有效共享底层资源(机器、网络、进程、消息队列等)的程度要高于传统方式。SOA 的一个积极效果是提供更集中的 IT 管理和更好的物理资源利用率,而这种效果没有 SOA 通常无法实现。 ( 这还影响操作型组织,因为现在有水平工作的角色和团队,比如 ESB 开发人员和 SOA 治理等,但深入讨论组织影响超出了本文范围。)

一个成熟度因素:操作风险

尽管面向服务解决方案促进松耦合系统,但类型相同的组件通常共享同一操作单元。例如,多个中介可能虚拟化不同的服务,但它们在同一台机器上、甚至在同一个 IT 进程中运行。或者,有一些业务流程尽管支持不同的业务线,但也可能都使用同一个关系数据库来存储流程状态数据。或者,一个 ESB 网关使用一个较小的 IBM® WebSphere® MQ 队列集来处理所有入站和出站 MQ 流量。

这种操作耦合意味着解决方案组件可能会争用有限的资源。某个解决方案可能会锁定一些资源,这样它们就对其他解决方案不可用。这样的资源示例是线程、数据库连接、网络连接、内部队列、基于堆的内存等。这可能会导致管理和维护问题,最坏的情况是,一个组件就可能会导致整个环境停用。

例如,如果一个解决方案耗尽到一个执行速度极慢的远程主机的所有网络连接,那么那些连接就不再可用于在同一台机器上运行的其他解决方案。如果两个解决方案共享一个公共队列以接收入站流量,如果针对一个解决方案的大量消息被发送到那个队列,那么针对另一个解决方案的消息可能无法足够迅速地通过。或者,如果针对一个解决方案进行了一个错误的管理更改,导致整个进程崩溃或挂起,则那个进程托管的所有解决方案组件也会崩溃或挂起。

当然,在理想世界中,这种情况不会发生。解决方案在进入生产阶段之前将要接受全面测试,更改应该只在任何不想要的副作用都被排除之后才进行。

但是,在真实世界中,总是有一个错误边际。在任何 IT 环境中,错误的风险总是取决于使用的技术和治理的成熟度水平、开发的解决方案以及实现的总体组织方式。

每当向一个操作环境添加新组件时,都需要考虑不想要的结果,鉴于上面提到的原因,这对于 SOA 上下文尤其重要。一个管理不当的更改的影响不再与托管解决方案隔离,且可能包含在同一个环境中运行的其他解决方案。

创建一个解决方案隔离用例

要克服前面提到的挑战,应该为您的面向服务环境设计并使用一个隔离策略。隔离概念并不是什么新事物,它频繁应用于 IT 解决方案中,以提高可靠性,但那些传统隔离策略能在面向服务环境中成功使用吗?答案是肯定的,但有一个非常重要的警告:过多隔离可能会降低部署的价值和 SOA 的运行时好处。

任何隔离策略在超出其逻辑用途范围时都会引发额外的操作成本。但是,在面向服务环境中,那个临界点出现得更早,且可能导致更大的成本影响。因此,需要小心翼翼地寻找适当的隔离级别,平衡业务需求和操作成本。没有准确的公式用于计算平衡点,但在为您的面向服务环境创建隔离策略时需要考虑几个非常重要的因素,本文将重点介绍这些因素。另外,本文还将提供几个具体示例,展示如何实际应用这些因素。

可以想见,没有任何两个 IT 组织拥有相同的隔离策略,但每个成功的隔离策略都有一些共同特征。具体而言,成功的隔离策略需要:

  • 考虑操作成熟度和有关风险。
  • 受到服务本身及其周围的业务上下文支配。
  • 受到服务使用的 ESB 运行时技术的支配。

以下部分将帮助您定义并定制一个隔离策略,以满足您的独特 IT 需求。注意,必须在任何新环境部署之前定义隔离策略,因为它能极大地影响拓扑的设计方式。

有两种类型的隔离需要考虑:

  • 架构隔离

    SOA 促进松散耦合、问题分离、实现封装和标准化合同等设计原则。遵循这些原则有助于在组件之间创建隔离层,促进重用,建立中央控制和管理点,比如 ESB。由于这种隔离文档丰富,通常很好理解,因此本文不打算关注架构隔离。

  • 操作隔离

    这里的新内容 — 通常被人们忽略 — 是在操作上隔离组件。理想情况下,一个解决方案中的问题绝不会影响另一个解决方案。在运行时共享 IT 资源的组件应该相互隔离。这包括使用仅在一个解决方案中使用的组件,公开虚拟服务的 ESB,以及提供者组件本身。另外,这个组还包含一些支持组件,用于监控、安全性、缓存和负载平衡等用途。

    操作隔离可以应用于多个不同的级别。可以从一个相当精细的级别开始:确保查询不会跨解决方案重用的配置,或者确保在解决方案之间使用分隔的连接池的配置。操作隔离级别可以一直向上延伸,直到向解决方案提供完全独立的硬件,在物理上隔离它们。

面向服务环境的隔离策略的元素

正确研发隔离策略需要一个多维视图。

这个视图中最重要的维度受到服务本身和服务的业务需求的驱动。要拥有这个维度的一个清晰视图,需要在技术和非技术两方面彻底理解您的服务及其特征。另外,关键要采用一种标准方法来理解您的服务。要定义这个维度,一个非常有用的工具是一个服务分类系统。本文稍后将简要描述这种分类系统的标准。

隔离策略中需要考虑的第二个维度是作为服务层基础的运行时技术。与其他技术一样,面向服务的运行时技术也有自己的关于部署、配置、分区机制、拓扑和管理的方法和最佳实践。负责这些技术的工程人员是设计您的隔离策略不可或缺的组成部分。第一个维度确定需要隔离的组件及其原因,这个维度则确定如何使用您的运行时技术来实现隔离。

隔离标准

关注服务和底层运行时技术,就有可能在您的策略中定义正确的标准集。这些标准将有助于有效确定应该在什么位置放置组件,以及在哪些级别上隔离它们。

可能会用到许多不同参数,每个 IT 组织必须确定其优先顺序,并由此定义适当的隔离方法。作为一个起点,必须对解决方案组件进行分类,这有助于确定隔离边界。

这样分类的一个标准集主要基于技术参数。例如(无特定顺序):

  • 物理位置
  • 消息格式
  • 网络协议
  • 更改频率
  • 运行时更改的动态性
  • 性能
  • 规模
  • 维护和当前策略
  • 复杂性
  • 可用性
  • 消息大小
  • 管理便捷性
  • 交互模式
  • 安全性
  • 成熟度

另外,驱动隔离的其他标准与业务相关。例如:

  • 业务关键性
  • 停用影响和成本
  • 渠道
  • 业务领域

确定解决方案隔离优先顺序时,业务级标准通常比技术标准优先。例如,一个必须遵守的要求是:业务关键型解决方案必须与非业务关键型解决方案完全隔离(也许需要互相隔离)。这是因为一旦停用,业务关键型解决方案将导致更严重的后果。当然,前提是业务关键型解决方案更成熟,因此不容易出现故障。

使用 WebSphere 软件的隔离机制

有几种机制支持在使用 WebSphere 产品的环境中实现解决方案隔离。下面通过两组完全不同的示例描述您可以应用的两种实现技术(即 IBM WebSphere Application Server 和 IBM WebSphere DataPower® Appliances)。这些机制可以单独应用,也可以组合应用,具体取决于前面描述的已设置优先顺序的隔离标准集。

WebSphere Application Server

WebSphere Application Server 的负载平衡和工作负载管理功能,以及它的故障转移支持,是许多隔离机制的基础。这些功能允许通过定义一个 “集群化” 拓扑跨多个流程和多台物理机器分发解决方案组件。

机器级别

隔离各个解决方案组件的最简单、也是成本最高的方法是将各组件放到分隔的硬件上 — 通常以一个已定义分类系统为依据。

在一种极端的情况下,解决方案不仅放到独立的硬件上,而且处于不同的 WebSphere Application Server 单元中。但是,在很多情况下,这种隔离不利于充分利用 IT 资源,因为它需要大量(利用率不高的)硬件,不利于集中管理和维护。

毫无疑问,我们经常被建议使用一个以上 WebSphere Application Server 单元。拥有一个所谓的维护单元,无需停用即可更新或迁移现有环境。而且,如果更新在生产中产生负面效果,您可以迅速切换到另一个单元,极大地减少恢复时间。

WebSphere Application Server 提供一种方法,支持将解决方案部署到一个逻辑目标上,然后以物理方式分发它们。简言之,这通过定义一些托管某些解决方案或一个解决方案的某些部分的集群实现。然后,这些集群寄宿在一个或多个节点上(那些节点通常映射到一些物理机器)。换句话说,可以通过定义适当的集群并将其部署到分隔的物理机器上来在硬件级别实现解决方案隔离。但是,请记住,这些集群仍然属于一个 WebSphere Application Server 单元。这可能会导致额外的风险,例如,在单元级别进行管理更改。

进程级别

如前所述,WebSphere Application Server 提供定义集群的能力。跨集群分发功能的一种常见方法如所谓的 WebSphere Application Server “黄金拓扑” 所示(见图 1)。在这种拓扑中,应用程序、消息传递和支持分别使用单独的集群。每个集群都有一个或多个成员,每个成员都由一个单独的进程或 JVM 表示。

图 1. WebSphere Application Server “黄金拓扑”
图 1. WebSphere Application Server “黄金拓扑”
图 1. WebSphere Application Server “黄金拓扑”

这样,在为单独的机器定义集群之上,您定义集群成员来在一个进程级别上分发解决方案。这样做部分是由于可伸缩性原因,但另一个重要原因是组件冗余和隔离提高了可用性。

图 1 展示了一个跨两个节点的三个集群的示例,其中每个节点包含三个集群成员,每个集群拥有两个成员(一个节点上一个)。这在解决方案之间提供非常少的隔离,因为所有特定于应用程序的组件都只部署在一个集群上。一个集群成员中的失败可以通过使用另一个集群成员来补偿,但如果一个行为不良的组件导致问题,则那些问题很可能将在两个集群中出现。

可以通过创建额外的集群或集群成员来提高隔离级别。例如,如果您对适当的隔离标准的分析导致您倾向于分隔任务关键型解决方案和非任务关键型解决方案,那么您可能会考虑为每个解决方案创建一个集群。这样,解决方案组件将在单独的进程中运行(因为它们位于不同的集群成员中)。现在,当一个非任务关键型应用程序耗尽(比如)一个进程中的所有线程,那么您的任务关键型解决方案将不会受到丝毫影响。

但是,要注意,创建额外的集群和集群成员需要在内存、CPU 容量和其他方面付出代价,因此不应该大量创建它们。因此,简单地将每个应用程序放到一个单独的集群中的做法是不切实际的。要了解关于扩展集群的最佳实践和注意事项的更多信息,请参见 参考资料

应用程序服务器实例级别

目前为止,您已经看到了如何通过将解决方案放置到单独的机器上或单独的进程中来隔离解决方案,但还有一些方法可以在进程之中(或者在应用程序程序服务器实例之中)隔离解决方案。

WebSphere Application Server 中部署的解决方案通常基于 Java EE。这也适用于 “常规” WebSphere Application Server 应用程序,以及在 IBM WebSphere Process Server 中运行的 BPEL 流程或在 IBM WebSphere ESB 中运行的中介(这里只是列举两个例子)。这些应用程序能够访问若干应用程序服务器资源:有些资源是用户定义的,有些资源是系统定义的。下面是一些经常争用的资源的示例,因此,如果配置适当,就能提高组件之间的隔离级别。

  • 线程

    有各种设置影响 WebSphere Application Server 如何在运行时分配线程。有些线程总是被共享,比如 Web 和 EJB 容器使用的线程池;而有些线程则关联到特定资源,比如消息传递引擎使用的线程池。

    配置这些线程池主要是调优应用程序服务器以实现最优性能的调优工作的一部分。对于解决方案隔离,则应该从另一个角度审视它们,确保作为不同解决方案组成部分的组件使用它们自己的线程池。可以实现这个目标的地方并不多。一个 例子是 Java™ EE WorkManager,它支持从应用程序服务器中的 Java 逻辑内部管理线程。每个 WorkManager 都有自己的线程池,以便您通过创建多个 WorkManagers 并将其分配给不同的解决方案来实现隔离。

    能影响一个组件可用的线程的数量(和这些线程源自的线程池)的另一个地方是消息传递。WebSphere Application Server 支持 “消息总线” 概念。所有消息传递资源(连接工厂、队列、主题等)都被分配给一个已命名总线。一个总线可以跨多个节点和机器,拥有一个或多个服务器或集群作为其总线成员。然后,总线成员使用消息传递引擎实际处理消息。每个集群只能有一个活动消息传递引擎。

    简言之,总线使用消息传递引擎处理消息。您可能会想到:可以配置消息传递引擎可用的线程池的大小。更重要的是,还可以定义哪个解决方案组件使用哪个总线,从而确保使用不同总线的解决方案组件也使用不同的线程池。

    但是,总的来说,问题依然存在:行为不良的组件能够使用并锁定一个进程的所有可用线程,即使您已经正确配置了隔离的线程池。解决这个问题的一种方法是将线程分配和管理的测试作为您的常规系统测试的一部分。

  • 连接

    与线程一样,连接也是一种有限的资源,因此也被放置到池中。连接有不同的类型,比如通过 JDBC 连接到数据库,JMS 连接,以及通过 J2C 资源适配器连接到其他任何外部资源。

    如果任一解决方案耗尽一种类型的所有连接,导致其他解决方案没有连接可用,问题就会产生。为连接池大小配置适当的值是一个应用程序服务器调优问题。实现解决方案隔离的常用方法是:确保与一个解决方案关联的系统的组件不与同一个服务器中运行的其他组件共享连接池。

    具体操作方法取决于要隔离的连接的类型。例如,到一个 JDBC 支持的数据库的连接通过使用的 JDBC 数据源定义连接池;JMS 和其他 J2C 连接池通过激活规范定义。这样,在 JMS 示例中,可以通过使用不同的激活规范来隔离各个解决方案组件,或者通过提供单独的数据源来隔离使用相同数据库的组件。

    使用在 WebSphere Application Server 之上运行的产品(比如 IBM WebSphere Process Server)时,部署解决方案组件可能会导致自动生成使用连接池的资源。例如,一个 WebSphere Process Server 模块会导致生成几个激活规范,这些规范用语管理模块组件之间和模块组件与其他外部组件的通信。这将导致一个默认隔离级别,不需要其他任何干预。

    如前所述,请记住,了解哪些组件使用哪些连接池不仅使您了解当前存在的隔离级别,还向您提供一个不错的调优系统、获取更好性能的起点。

  • 队列

    最后一个示例是消息传递队列。许多解决方案都以某种方式利用异步通信,或者显式利用(例如通过包含使用 JMS 的逻辑),或者隐式利用(例如通过定义 WebSphere ESB 中介模块组件之间的异步交互)。

    如果解决方案通过共享队列来满足它们的消息传递需求,那么存在这样的风险:某个解决方案的行为可能会影响另一个解决方案。例如,假定一个服务提供商通过一个 JMS 队列集提供客户数据检索服务。这个服务的一个使用者位于一个企业的呼叫中心。使用这个解决方案的员工必须能够非常快速地检索客户信息。另一个使用者是一个解决方案,该解决方案合并多个遗留系统的客户信息,每天运行一次,没有人工干预。第二个使用者能在很短的时间内使用大量消息 “淹没” 服务的请求队列,使得呼叫中心解决方案很难继续正常运行。

    在这个示例中,不仅单独的服务提供商的组件之间需要隔离,使用者之间也需要。在本例中,实现隔离的方法是:向单独的使用者分配单独的队列,并确保服务提供商按照优先顺序服务所有队列。注意,在这个每天运行的批处理式使用者示例中,可能需要额外的限流措施来控制同时处理的消息的数量。

WebSphere DataPower SOA Appliance

最近几年,新一代专用设备已经进入企业 IT 领域。这些硬件设备本质上类似于路由器和交换机等网络设备,因为它们都将软硬件合并到一个可以立即投入使用的包中。但是,它们与典型网络设备也有区别,因为它们提供网络堆栈中的高级功能,主要关注应用程序层功能。

这种新一代设备提供简单快速的部署,这是每个 IT 部门都梦寐以求的功能。这些设备的核心是硬件和软件,因此需要考虑和实现一个解决方案隔离策略。

本节探索 IBM 的 WebSphere DataPower SOA Appliances,简要介绍实现一个解决方案隔离策略可以利用的可用元素。

如前所述,最极端且最安全(尽管存在争议)的隔离级别是物理隔离;但是,这种策略可能转化为高昂的所有者总成本,这可能不是合理的业务成果。因此,本节主要关注在诉诸物理隔离之前可用于实现隔离的 WebSphere DataPower 元素。(这不应该与用于满足容量需求的额外设备需求相混淆。容量规划是一个成功的 WebSphere DataPower 实现的关键元素,但这个主题超出了本文的范围。)

当识别在解决方案中扮演重要角色的 WebSphere DataPower 内部组件时,我们还将简要了解 WebSphere DataPower 环境的物理拓扑如何发挥作用。

与其他计算平台一样,WebSphere DataPower 也拥有一个软件栈,其中包括操作系统和用于实现一个功能集的软件组件。但是,由于其专用特性,整个软件栈(包括操作系统)都是高度定制的,或者说,它的规模是针对预定用途适当设置的。结果,在通用操作系统上的软件栈中可用的一些隔离方法在这里不可用。WebSphere DataPower 的操作系统的核心元素没有公开,这将一个解决方案限制到一个进程,无法分配有限的资源量(内存、线程等)。这要求在 WebSphere DataPower 中隔离解决方案时稍微转移焦点。这种转移转向为解决方案创建行为边界而不是资源边界。这是为了确保一个解决方案的工作负载不会垄断 WebSphere DataPower 资源并影响其他解决方案。如前所述,容量规划是这里的一个重要元素,它规定某个工作负载集所需的物理设备的数量。但是,鉴于本文目的,我们假定适当的容量已经被规划并提供。这样,我们将聚焦于跨多个解决方案共享一个设备这种情况中的设备内隔离原则。本质上,我们关注如何保护设备本身和工作负载,以免出现意料之外的负面情况。

幸运的是,WebSphere DataPower 有一个非常强大的功能,名为服务级别监控(Service Level Monitoring,SLM),可用于定义和实施行为边界。SLM 支持管理单独的 Web 服务或 Web 服务集。例如,您可以定义请求和响应消息流量的阈值,触发警报,并且可以在阈值达到时启动限流功能。这防止一个解决方案使用过多设备资源,导致其他解决方案没有足够的资源可用。

尽管可能显而易见,但还是需要特别强调的一点是:在实施任何行为边界之前,您需要理解解决方案和 WebSphere DataPower 中作为解决方案一部分的每个服务的预期行为。这些行为边界必须在解决方案的非功能需求上下文中定义和实现。实现必须通过充分的生产前测试进行验证,并在生产中受到监控,以确保解决方案的正确执行不会受到限制。

设备中的隔离的另一个重要方面是需要一些配置工件来告知 WebSphere DataPower 处理什么消息以及如何处理。WebSphere DataPower 为其配置实现了一个面向对象模型,可生成大量非常适合在设备中重用和共享的独立对象。这种配置项目重用简化了 WebSphere DataPower 设备及其功能的管理、配置和部署。但是,应注意确保某个服务没有任何关联配置项目会阻止其他服务运行。确保适当的配置隔离级别应该考虑的一些关键配置项目将稍后讨论。

WebSphere DataPower 提供几种可以配置的服务类型。在这里,我们主要关注 WebSphere DataPower 的 Web Service Proxy 服务类型。Web Service Proxy 是一个功能丰富的、基于 WSDL 的代理,面向 Web 服务提供者。由于所有 WebSphere DataPower 服务类型都有相同的基本特征,因此针对 Web Service Proxy 讨论的隔离概念也同样适用于其他 WebSphere DataPower 服务类型。

图 2 简述了有助于在 WebSphere DataPower 设备中创建边界的关键配置对象。实现隔离策略时需要考虑这些对象。下面,我们逐一查看它们。

图 2. WebSphere DataPower 内部隔离点
图 2. WebSphere DataPower 内部隔离点
图 2. WebSphere DataPower 内部隔离点

应用程序域

配置隔离的核心是应用程序域(以下简称域)。WebSphere DataPower 域是一个逻辑分区,提供隔离服务的能力。一个域包含一个或多个服务,其中包括那些服务需要的 WebSphere DataPower 配置对象。默认情况下,一个域中的对象对其他域不可见。因此,跨多个域分隔您的服务是一个好方法,可以隔离和最小化配置更改的风险。您还必须特别小心,确保 “游离的” 对象(即服务不需要的对象)被清理;否则,您将发现,启动时间会变长,管理对象时的配置复杂性也会增加。

挑战是如何细分您的服务并将其分组到一个逻辑域结构中。分组选项有很多,有一个选项备受瞩目,即通过理解现有服务治理模型、采用一种自下而上的方法对服务分组,正如服务的开发周期中所反映的。服务通常作为一个集合来开发和维护,将这一点作为创建您的域的基础,就能提供一个从生产前到生产阶段的逻辑服务流。

可以创建独立于环境的自含式 WebSphere DataPower 域。因此,域可以变成非常方便的部署包,这种包不仅便于部署,而且提供良好的配置隔离。

应用程序域提供良好的配置和部署隔离,但还需要利用其他方法来隔离服务并提供运行时隔离。这些运行时隔离元素将在本文后面讨论。

有一个重要的警告需要注意。根据 WebSphere DataPower 的架构,一个设备的计算资源被所有已部署域均等地共享。如图 2 所示,WebSphere DataPower 中部署的所有组件(因而解决方案)都可以访问所有网络、CPU 和内存。另外,这些资源不能分区或绑定到任一解决方案。

Web Service Proxy

Web Service Proxy 是一个配置构造,用于封装并最终定义如何处理基于 WSDL 的服务事务。一个 Web Service Proxy 可以包含一个或多个基于 WSDL 的服务,如图 2 所示。

与应用程序域类似,Web Service Proxy 能帮助隔离各个服务的配置对象。尽管 Web Service Proxy 中有大量调优和设置选项,但这些选项中的大部分(稍后将讨论例外情况)都针对如何处理消息或服务进行了调整,几乎不能对解决方案隔离和创建行为边界提供任何帮助。但是,跨一个域中的多个 Web Service Proxy 分隔服务能极大地协助管理并帮助隔离配置。

如前所述,Web Service Proxy 级别上有几个关 键参数能用于向服务应用一些边界:

  • 一个实时请求在 WebSphere DataPower 中被持有、等待来自后端服务提供者或前端使用者的活动的时间有多长:
    • 后端超时
    • 前端超时
  • 一个闲置持久性 TCP 连接在与 WebSphere DataPower 断开之前的被持有的时间有多长:
    • 后端持久性超时
    • 前端持久性超时

这两组参数都可用于在使用者或服务提供者行为异常时优化 WebSphere DataPower 中的资源使用。如果持有闲置请求或 TCP 连接的数量太多、时间过长,就会在设备中产生一种 “堆积” 效应,从而影响其他请求。“闲置” 和 “太长” 都是相对的,取决于后端提供者等组件的预期响应时间。 对一个服务而言 “闲置时间太长” 可能是另一个服务的合理延迟。因此,重要的是要通过性能测试来定义和检验响应时间目标和实际延迟时间。只有这样,才能够正确设置这些值,确保正确定义服务的行为边界,而不是过度限制服务边界,导致请求不适当地失败。

与应用程序域一样,Web Service Proxy 也适用一个类似的警告。尽管 Web Service Proxy 能隔离一个服务或一组服务的配置,但它本身或在默认情况下并不能对解决方案隔离提供太多帮助。

前端处理器

前端处理器(Front Side Handler,FSH)对象用于向外界公开 WebSphere DataPower 中定义的服务。FSH 定义为监听一个特定 IP 地址和网络端口,配置为处理 WebSphere DataPower 支持的众多协议之一。在这里,我们仅讨论基于 HTTP 的 FSH。FSH 将与接收入站消息的使用者交互,将消息传递到 Web Service Proxy,然后传递到其中定义的服务。

FSH 在协议层操作,不提供限制网络资源的能力,这样,没有一个应用程序能垄断网络栈。但是,可能有某种性能和操作隔离,通过 FSHs 将不同的入站端口分配给不同的服务;根据您的网络的负载平衡和故障转移功能,您可能会发现,隔离服务集和它们自己的端口有好处。

有一个重要的、指向 FSH 的 WebSphere DataPower 行为链接,这个链接能极大地影响您设计 FSH 对象的方式。正如 WebSphere DataPower 支持技术说明 Multiple Web Service Proxy using the same Front Side Handler 所述,将多个服务分配给一个 FSH 有意义。这个问题源自这样一个事实:共享一个 FSH 的所有服务都会 “相互链接”,因此,如果那些相互链接的配置对象中发生更改,那么所有链接到的服务都会被更新。这可能会成为一个操作问题,需要与您的操作流程结合考虑。

服务级别监控

WebSphere DataPower 的服务级别监控(Service Level Monitoring,SLM)功能支持对各个服务处理的工作负载进行细粒度行为控制。SLM 特性允许控制工作负载、执行工作负载的凭据、以及处理工作负载时的时间间隔。有几种方法可用于处理超过设置阈值的工作负载,比如形成(排列)请求或立即拒绝请求。

执行隔离分析时,必须考虑隔离各个服务,确保单个服务不会耗尽设备的系统资源。WebSphere DataPower 系统资源在设备中共享,您必须小心谨慎,确保一个服务使用的资源不会超过其适当的份额。例如,您可能会遇到这样的情况:由 WebSphere DataPower 前置的一个服务正在经历响应发送延迟。这是,您需要保护后端,防止其被耗尽,并确保 WebSphere DataPower 保持稳定。在 SLM 策略中,可以配置允许进入 WebSphere DataPower 的连接的数量,或指定基于后端延迟执行的事务的数量。基于实时事务型数据,WebSphere DataPower 能触发一个 SLM 策略,确保打开数量适当的连接,或将数量适当的事务发送到后端。WebSphere DataPower 的最优工作负载类型包含一些短暂事务;当大量长时运行的事务在 WebSphere DataPower 上运行时,保持连接开放需要更多系统资源(比如 CPU 和内存);因此,使用适当的值调优它们能确保服务的资源份额适当。

SLM 策略配置并非易事,需要使用各种工作负载执行性能测试,确定您的 SLM 策略的适当配置值。设置和执行性能测试超出了本文范围,但您的企业应该有一些测试工具和方法系统可供使用。另外,应该定期对生产数据进行事务型分析,调优您的 SLM 策略,因为工作负载会随时间改变。

XML 管理器

XML 管理器控制 WebSphere DataPower 中定义的服务的几个特征。有一个默认 XML 管理器,它自动连接到 Web Service Proxy,并为定义到该代理的每个服务设置一些边界。

尽管默认设置完全够用,但熟悉 XML 管理器还是很重要。XML 管理器可帮助控制服务的两个关键方面:

  • 消息大小。
  • 文档缓存大小。

对这两个服务元素应用边界能放置不良消息或处理过度使用设备中的共享内存,从而影响其他服务。

Web Service Proxy 的 XML Parser 选项卡提供各种消息大小约束,应该检查它们,确保它们适合您的服务。如前所述,重要的是要理解服务的 NFRs,最大消息大小应该是那些 NFRs 的一部分。如果消息大小限制设置得太低,那么有效的服务事务可能会失败(这适用于请求和响应消息);相反,将它们设置为安全的值则允许处理需要大量内存或 CPU 的大消息。

Web Service Proxy 的 Document Cache 选项卡提供与服务可以在 WebSphere DataPower 中使用的缓存文档相关的各种约束。这里也适用上述 XML Parser 限制原则。

物理隔离

尽管物理隔离成本高昂,但如果没有物理隔离,任何隔离策略都是不完整的。

WebSphere DataPower 中有一些情况,只有物理隔离才是正确的答案。显然,这会涉及容量因素,但鉴于本文目的,我们假定容量因素已经被考虑在内。

如前所述,某些计算资源无法在 WebSphere DataPower 中限制。WebSphere DataPower 中的计算能力被布局为一个线性平面,流经设备的所有工作负载都能访问。

有些工作负载非常重要,不能与他人共享资源;它们需要极高的可用性水平 — 侵占设备中的其他服务的资源的专用配置设置,或者生成一种资源垄断级别(比如非流动性、规模很大、或高延迟的工作负载)。这时,物理隔离就能发挥作用了。

通过物理隔离,您选取一个解决方案或一组具有相似特征的解决方案(从此前讨论的服务类别驱动),将它们隔离到它们自己的 WebSphere DataPower 设备集上。现在,您可以针对那些解决方案应用一个专门配置的 WebSphere DataPower 环境。

应该注意,即使在这种情况下,应用设备内行为边界的重要性仍然存在。

尽管已超出本文的范围,但包含多个物理设备(无论是由于容量、隔离还是故障转移原因)的 WebSphere DataPower 实现需要一个可靠的网络和负载平衡设计。尽管可以集成各种智能负载平衡解决方案来使用 WebSphere DataPower,但 WebSphere DataPower 中的应用程序优化特性还是非常值得推荐的,因为它们提供了一种强大的智能负载平衡集成解决方案。

小结

完整的解决方案隔离策略通过构建一个基于一些隔离标准的决策树构建,这些隔离标准通过正在使用的运行时和产品提供的相关机制确定。可以使用一种或多种技术在一个级别上实现隔离。

一种隔离实现方法是创建一个流,将每个标准表示为一个决策节点。决策树的末尾是一个指示器,定义组件如何隔离。例如,假定一个集群环境包含几个跨三个节点的 WebSphere Application Server 集群,应用程序组件需要根据隔离要求进行放置。图 3 中的决策流示例展示了如何分布这些组件,以便将隔离标准映射到物理环境。

图 3. 使用 WebSphere Application Server 隔离组件的决策树示例
图 3. 使用 WebSphere Application Server 隔离组件的决策树示例
图 3. 使用 WebSphere Application Server 隔离组件的决策树示例

图 3 展示了一个 WebSphere Application Server 单元,包含三个节点,节点上定义了三个集群。隔离标准(业务关键性、可用性、更改频率等)通过决策节点表示,以便为每个已部署应用程序确定一个适当集群。

结束语

本文介绍了解决方案隔离概念,将其作为一种提高面向服务环境的操作可用性的方法。假如 SOA 能提高组件重用水平(实际情况也的确如此,这是因为组件被多个使用者使用或组件共享相同的底层运行时环境,或同时包括这两个原因),那么组件之间相互施加负面影响的风险就会增加。可以通过定义和部署一个解决方案隔离策略来减小这种风险。本文通过一些示例展示了能帮助您制定适用您的环境的适当策略的标准,以及适用 WebSphere Application Server 和 WebSphere DataPower 的隔离机制。

致谢

本文作者衷心感谢 Rachel Reinitz、Greg Flurry 和 Alexandre Polozoff 对本文撰写提供的帮助!


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=659778
ArticleTitle=面向服务环境中的解决方案隔离
publish-date=05192011