内容


用于 WebSphere ESB 的 JITT&D

Comments

简介

Just-In-Time Throttler and Dispatcher(后面简称为 JITT&D)通过扩展 IBM® WebSphere® ESB 仲裁提供节流和分派功能,以便更好地在仲裁流中分派和管理流向服务提供商的请求。

您可以在本文的底部的下载去下载文件:

  • JITT&D 安装代码,包括一些示例
  • JITT&D 安装和编程指南

第 1 部分 使用 ESB 进行节流和分派

节流和分派使您能够通过 ESB 更好地控制如何将服务请求发送给目标服务提供商。

节流

从 ESB 的角度看,节流 是指控制发送目标服务的请求的数量。例如,如果为了获得较好的性能而控制服务同时处理的请求数量不超过 3 个,那么 ESB 同时向该服务提交的请求不应超过 3 个,超出的请求将在队列中排队直至一部分正在处理的请求完成。请求的数量超过目标服务的处理能力会降低性能,节流对于避免服务收到过多的请求起到重要作用。

图 1.
节流
节流

分派

分派 指的是在几个端点直接分发请求。在 SOA 中,几个端点通常实现相同逻辑的服务,并且发送到该服务的请求必须在端点之间分发。一些用于驻留服务的基础架构,比如 WebSphere Application Server,本身带有分派功能(通过安装在 HTTP 服务器中的插件实现工作负载平衡),但其他则不带有此功能。因此,ESB 也应该能够在几个端点之间分派请求。

图 2.
分派
分派

要在实现相同服务的不同端点之间动态、平衡地分发请求以保存良好性能,那么分派将起到非常重要的作用。

第 2 部分 需求和可能的设计

需求

JITT&D 是已经经过验证的概念,适用于需要控制服务调用的客户。下面是一些需求:

  • 必须控制出站请求,确保同时向同一端点发送的请求的数量不超过指定数量。
  • 必须在实现相同逻辑服务(共享通用的 WSDL 和实现)的几个端点之间分派出站服务请求。在分派时,必须在可用的端点之间实现工作负载平衡,并且在可能的情况下将请求发送给活动频率最低的端点。此外,分派还需要考虑到不同端点的接受能力,因为一些端点处理并发请求的数量可能比另一些端点多。
  • 必须同时对请求-响应和单向服务调用进行节流和分派。
  • 该工具必须能够提供高性能并且给 ESB 带来最小的开销。
  • 对于由运行在不同物理服务器上的几个 ESB 服务器处理的请求,该工具必须能够起到节流和分派作用。它还应该能够在高可用性环境下工作,以实现随时对请求进行节流和分派。
  • 该工具还必须使用户能够动态地更改配置(在处理请求期间,包括更改每个端点的最大吞吐量,以及为服务添加或删除端点)。
  • 该工具该必须为技术监视提供图形化功能:
    • 一个用于显示关键性能指示器的仪表板,比如输入和输出吞吐量,在等待和处理中的请求数量,以及平均的等待和处理时间。
    • 图形显示界面必须显示这些指示器是如何随着时间而变化的。

根据以上针对 WebSphere ESB 节流器和分派器的需求,有四种解决方案设计可供考虑:

纯 Java™ 解决方案

节流器和分派器被实现成在 WebSphere ESB JVM 中运行的 Java 类,并且还将管理端点状态所需的数据存储在 JVM 内存中:

图 3. 纯 Java 解决方案
纯 Java 解决方案
纯 Java 解决方案

这个解决方案的优势是同构性(仲裁、节流器和分派器都运行在相同的环境中)和高性能设计(完全同步)。

数据库解决方案

节流器和分派器被实现为为 WebSphere ESB 提供服务的数据库,其中逻辑被实现为存储过程:

图 4. 数据库解决方案
数据库解决方案
数据库解决方案

这个解决方案的优势是便于在几个 WebSphere ESB 服务器之间贡献节流/分派功能,并且非常安全地存储需要管理的数据。

JMS 队列解决方案

使用 WebSphere ESB 对请求进行节流的另一种方式是将分裂仲裁模块,并在两个生成的模块之间控制连接上节流。如果使用 JMS 绑定来实现连接,那么可以在第二个仲裁模块(使用 JMS 绑定导出)的入口点上使用最大的并发参数。这个参数确保同时执行的第二个仲裁的实例数量不会多于 <maximum_concurrency> 参数设定的数量,因此向目标端点同时发送的请求不会超过 <maximum_concurrency> 设定的数量:

图 5. JMS 队列解决方案
JMS 队列解决方案
JMS 队列解决方案

这个解决方案容易实现并且不需要编程。不过,它的性能可能很差,因为该模式是异步模式,并且仲裁应用程序被分裂成两个模块,这样会导致一些处理开销。此外,它不提供分派功能。

WebSphere Application Server 本机节流

WebSphere Application Server 提供一个在 JVM 定制属性中设置的参数 (com.ibm.websphere.webservices.http.maxConnection),该参数定义了运行在应用服务器中的所有 Web 服务客户端应用程序同时能够提交的 Web Service 请求的最大数量。这个参数还适用于由 WebSphere ESB 提交的 Web 服务请求(使用 Web 服务绑定导入) ,因此可用于对 WebSphere ESB 进行节流。尽管该参数易于使用,但它是全局性的,不允许为每个目标服务指定并发请求数量。此外,它不提供分派功能。

第 3 部分 实现

JITT&D 根据上述的第一种方式(即纯 Java 解决方案)进行实现,这种方式与 WebSphere ESB V7.0 有密切的关联,并且主要关注同步和高吞吐量。该解决方案涉及到一组在 WebSphere ESB JVM 中执行的 Java 类,并且将数据作为常驻数据存储在 JVM 中。

实现细节

JITT&D 控制和分发由 WebSphere ESB 仲裁发生给服务提供商的 SOAP 请求。通过组的形式管理目标端点:实现相同服务的所有端点都属于一个代表该服务的组。可以为组中的每个端点分配一个指定值,用于确定并发请求的最大数量,这个值可以根据所驻留的服务器的接受能力而改变。JITT&D 可以同时管理几个这样的组。所有配置数据,比如组、端点以及为其分配的参数都存储在一个配置文件中。

所有包含服务请求的 ESB 仲裁首先会和 JITT&D 通信,以为代表目标服务的组中的每个端点获取一个令牌。获取令牌的请求由一个名为 Dashboard 的单态类进行处理,该类负责管理一个或多个组的端点的状态。然后,Dashboard 类根据每个端点的最大并发请求数(不可超越该数)和在组中的端点之间分派请求的需要将令牌分配给仲裁。这些已分配的令牌将在后面的阶段发行,从而让其他仲裁能够使用它们。发行令牌的方法因请求-响应和单向调用而不同。

图 6. JITT&D 全局概述
JITT&D 全局概述
JITT&D 全局概述

请求-响应模式

在请求-响应模式中,仲裁流将在调用目标服务之前与 JITT&D(API 调用)通信,从而为组中的每个端点获取令牌。JITT&D 管理一个表示端点的状态的表,并通过搜索表找到尚未分配的令牌。它提供了两种搜索算法:

  • 基础算法:使用找到的第一个未占用的令牌,通过 “逐一比照” 的方式在端点之间实现一些平衡。
  • 优化算法:在搜索活动频率最低端点中搜索令牌并使用搜索到的令牌。活动频率是指当前分配的令牌数和端点的令牌总数的比率。这个算法能够考虑到组中不同端点的接受能力。

根据该搜索的结果:

  • 如果找到未占用的令牌,其状态将更改为 “assigned” 并且将相应端点的 URL 返回到仲裁流,后者调用使用所提供的 URL 的 Web 服务。
  • 如果一个组中的所有端点的所有令牌都已分配出去,那么仲裁流请求将储存在一个 FIFO 队列中,直至有令牌转变成未占用状态。

在处理服务响应时,仲裁流将再次与 JITT&D 通信以释放令牌。JITT&D 检查队列中是否包含待处理的请求:

  • 如果存在正在等待的请求,那么令牌将分配给下一个请求,并且将该请求从队列中删除。
  • 如果队列为空,那么令牌的状态将更改为 “free”。
图 7. 请求-响应模式
请求-响应模式
请求-响应模式

单向模式

在单向模式中,令牌的分配机制和请求-响应模式一样。不过,没有处理任何响应,因此先前的机制不能用于释放令牌。在这里,令牌在某一时间段被分配给仲裁流,而该时间段表示目标 Web 服务的理论执行时间。当该时间段结束时,JITT&D 将释放令牌,并将这个令牌分配给另一个仲裁流或将其更改为 “free” 状态:

图 8. 单向模式
单向模式
单向模式

错误处理

目标 Web 服务调用可能导致两种类型的错误:

  • 不可恢复错误:请求必须返回给客户端。例如,因为输入数据损坏而导致服务调用失败。
  • 可恢复错误:请求必须提交给另一个端点。例如,因为端点不可用而导致服务调用失败。

JITT&D 管理一个可恢复错误列表。在处理响应时,它将识别此类错误,并将请求重新提交到组中的另一个端点。它还将失败的端点登记为 “Suspended”,并在一段时间内不向该端点发送请求。在这个时间段之后,JITT&D 解除该端点的暂停状态并重新向其发送请求。

其他功能

在管理将令牌分配给仲裁流的同时,JITT&D 还计算关于其活动的统计数据,计算过程由 History 类执行。可以通过下面描述的图形用户界面显示这些统计数据。可以通过用户界面动态地修改 JITT&D 的配置(在将令牌分配给请求的时候)。您可以调优以下参数:

  • 与某个端点相关联的最大令牌数。
  • 端点能够添加到组,或从组中删除端点。

运行时配置

实现了两个版本的 JITT&D,一个用于单服务器环境,一个用于集群和多服务器环境。

单服务器环境

在这种情况下,仲裁应用程序和 JITT&D 都运行在相同的 WebSphere ESB JVM 中,并且两个组件的通信是直接的,没有涉及到网络层。

图 9. 单服务器架构
单服务器架构
单服务器架构

多服务器架构

在多服务器架构中,在几个服务器上执行需要通用节流和分派的仲裁应用程序。这些服务器可能属于一个集群,但不一定得这样。还可能使用到完全独立的服务器的配置。在多服务器架构中,JITT&D 的单个实例在单个服务器上执行,并且所有仲裁应用程序都通过网络与之通信,以请求和释放令牌。仲裁和 JITT&D 之间的网络通信是以 REST 的方式实现的。

为了实现高可用性,JITT&D 应该安装在集群中,并且配置为每次仅在一个服务器上是活动的。如果运行 JITT&D 的服务器停机了,那么 JITT&D 将自动在集群中的另一个服务器上重新启动。

图 10. 多服务器架构
多服务器架构
多服务器架构

第 4 部分 使用 JITT&T

与仲裁应用程序集成

仲裁流调用 JITT&D 以从某个服务端点请求和释放令牌。这些调用通过一个 Java API 来完成。

建议从特定的仲裁流调用 JITT&D,即不使用包含核心仲裁功能的仲裁流,比如转换和路由功能。 这 种分离便于重新提交出现可恢复错误的请求。重新提交由第一个仲裁流的 Callout 节点触发。

图 11. 集成组装图
集成组装图
集成组装图

节流和分派仲裁包含与 JITT&D 调用相关的代码。

请求流

在节流和分派仲裁的请求流中,必须使用业务对象填充关联上下文,并且该业务对象为将请求消息 ID 传递到响应流所用的对象。默认情况下,请求消息 ID 没有传递到响应流,从而使 JITT&D 能够关联请求流和响应流调用。管理上下文业务对象必须包含一个名为 requestMessageID 的字符串字段。

图 12. 输入节点的详细属性
输入节点的详细属性
输入节点的详细属性

然后,使用一个定制仲裁节点来调用 JITT&D,从而为名称指定为 API 调用的第一个参数(下面例子中的 QueryPersonDispatchThrottleGroup)的组请求一个令牌。在给仲裁分配了令牌之后,JITT&D 将已分配的端点的 URL 设置到服务消息对象中(/headers/SMOHeader/Target/address 字段),并将请求消息 ID 设置到关联上下文 requestMessageID 字段中:

图 13. 仲裁流请求图
仲裁流请求图
仲裁流请求图

响应流

在响应流中,使用定制的仲裁节点来调用 JITT&D 以释放令牌。使用组和请求消息 ID(在服务消息对象的管理上下文中找到)来获取令牌。如果服务调用失败,JITT&D 将检查错误并确定其是可恢复的(必须重新提交到组的另一个端点)还是不可恢复的(必须返回给客户端应用程序)。这一决定将作为布尔值返回给仲裁流。

图 14. 仲裁流响应图
仲裁流响应图
仲裁流响应图

当需要重新提交时,节流仲裁将一个模型化的错误返回给转换和路由仲裁。这个仲裁流的 Callout 节点必须配置为对模块化错误进行重试。

图 15. Callout 节点的重试设置
Callout 节点的重试设置
Callout 节点的重试设置

技术监视和调优

在管理将令牌分配给在 WebSphere ESB 中执行的仲裁流时,JITT&D 还收集可以通过用户界面显示的统计数据和历史数据。该用户界面首先显示 JITT&D 所管理的群列表:

图 16. 群选择面板
群选择面板
群选择面板

这些组、它们的端点和所有其他运行时参数都在一个配置文件中进行定义。

组性能指示器

在先前的面板中选择一个组,该面板将显示关于该组的关键性能指示器:

  • 请求(每秒的输入)和释放(每秒的输出)令牌的仲裁流的吞吐量。
  • 等待令牌(等待流)的仲裁流的平均数量,当前使用一个令牌来调用 Web 服务(在处理流中)和两者(所有流)。
  • 请求和使用令牌的仲裁流的平均等待时间,处理时间和全局时间(等待时间加上处理时间)。
  • 组端点的细节:URL、当前工作负载(使用的令牌)和最大令牌数。
  • 可以通过按钮来将令牌添加到端点 (+),将令牌从端点中删除 (-),将端点从组中删除 (Remove) 和将端点添加到组 (Add new endpoint)。这些调优不需要修改配置文件,因此在服务器重启之后就失效。要让修改长久有效,请修改配置文件而不是用户界面。
图 17. 组性能指示器面板
组性能指示器面板
组性能指示器面板

性能指示器历史数据

通过先前面板中的 History 按钮可以显示关于组的指示器如何随着时间而变化的历史数据。下图绘制出历史数据:

  • 每秒输入和输出流的数量变化
  • 等待、处理中和所有流的数量变化
  • 等待、处理和全局时间的变化

通过按钮能够在时间上前移或后移,能够回到过去的任意时间点,并且能够回到当前的时间点。

图 18. 性能指示器历史数据面板
性能指示器历史数据面板
性能指示器历史数据面板

结束语

本文展示了如何通过节流和分派功能扩展 ESB。它通过 JITT&D 为 WebSphere ESB 提供这些功能的通用实现,从而能够控制和分派 WebSphere ESB 仲裁向 Web 服务发出的请求,并能够通过图形化仪表板监视吞吐量和持续时间。该工具的优点包括极佳的节流和分派能力、高性能和易用性。还可以通过添加其他功能在增强该工具,比如为请求指定优先级和在 WebSphere Service Registry and Repository 中对端点进行 SLA 检查。本文提供的概念、架构和代码可以在其他 ESB 中重用。

配置文件

JITT&D 的组、端点和其他运行时参数都在一个配置文件中定义。JITT&D 安装和编程指南描述了可用的参数及其语法。下面该配置文件的一个例子:

JITThrottler.properties
# JIT Throttler & Dispatcher configuration properties
#########################################################

# Endpoints of group '2525'
Group1 = 2525
Group1_Mode = RR
Group1_Endpoints_MaxReqNb = 3
Group1_Endpoint1 = http://localhost:9080/gSOAP1/ServiceMos
Group1_Endpoint2 = http://localhost:9080/gSOAP2/ServiceMos
Group1_Endpoint3 = http://localhost:9080/gSOAP3/ServiceMos
Group1_Endpoint3_MaxReqNb = 6
Group1_History = 1

# Endpoints of group '9911'
Group2 = 9911
Group2_Mode = RR
Group2_Endpoints_MaxReqNb = 2
Group2_Endpoint1 = http://localhost:9080/gSOAP4/ServiceMos
Group2_Endpoint2 = http://localhost:9080/gSOAP5/ServiceMos
Group2_Endpoint3 = http://localhost:9080/gSOAP6/ServiceMos
Group2_History = 1

# List of recoverable faults
SuspendRetryFault1 = javax.xml.ws.WebServiceException: java.net.ConnectException: 
    HTTP (404) Not Found address:
SuspendRetryFault2 = javax.xml.ws.WebServiceException: java.net.SocketTimeoutException: 
    Async operation timed out

# Suspend duration (milliseconds)
SuspendDuration = 180000

# Token wait time (milliseconds)
TokenWaitTime = 60000

# Pending in process requests overduetime
PendingInProcessRequestsOverdueTime = 120000

# Pending in process requests cleaner frequency
PendingInProcessRequestsCleanerFrequency = 60000

# Number of last completed requests used for average response time calculation
ResponseTimeSampleSize = 5

# Time in seconds used to calculate the average throughput
ThroughputCalculationTime = 3

# Number of history recordings per minute
HistoryRecordingsNb = 10

# Period of time for displaying history recordings (minutes)
HistoryDisplayPeriod = 2

# Time in seconds to refresh the group view in the user interface
UIGroupViewRefreshTime = 12

# Time in seconds to refresh historical graphics in the user interface
UIHistoricCurvesRefreshTime = 6

# Directory to store historical data
HistoryDataStorageDirectory = D:/Temp/JITThrottler

# TraceLevel (0, 1 or 2)
TraceLevel = 0

下载资源


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=762560
ArticleTitle=用于 WebSphere ESB 的 JITT&D
publish-date=09292011