当时方位: 主页 > > IBM > IBM软件 > 在IBM Integration Bus中配备WebSphere Service Registry and Repository缓存

在IBM Integration Bus中配备WebSphere Service Registry and Repository缓存

2014-08-01 09:07 来历:IBM 作者:Martin Smithson 人气指数: 我要谈论

本系列文章将介绍怎么集成这两款产品,并供给处理一些重要事务问题的示例。第 7 部分将介绍 Endpoint Lookup 和 Registry Lookup 节点所运用的缓存的配备和行为,包括该缓存怎么支撑高效地查找曾经检索的 WSRR 工件,以及怎么将此数据供给给出产体系。本文将介绍 WSRR 集成查找节点所引证的署理保管的缓存的行为,这些节点能够包括在 IIB 音讯流中。然后,咱们还将介绍怎么配备这个由署理保管的缓存(以下简称 WSRR 缓存)来集成 WSRR 和 IIB,以及怎么验证它的正确操作。本文最终将介绍怎么办理 WSRR 缓存,别离这两款产品来创立一个服务窗口,以便在晋级 WSRR 时无需封闭 IIB 或它的运转时流,并且无需在出产环境中引进任何宕机时间。此进程具有严重的事务价值,由于 IIB 运转时环境需求尽或许少的宕机时间。

特征

WSRR 集成节点:Endpoint Lookup 和 Registry Lookup 被规划为能够与 WSRR 进行交互,支撑经过对这个注册表体系宣布查询来提取搜集的数据。因而,这些节点答应从注册表查找信息,并将这些信息注入到传出它们的音讯树中,以便在它们所嵌入的任何流中履行后续下流处理。

署理完结了一种本地缓存,在启用该缓存之后,该缓存能够存储这些对所重视的查询句子的调用的成果。启用缓存后(默许设置),只需曾经履行过一次彻底匹配的查询,WSRR 集成节点就能够直接从本地缓存检索数据。拜访本地缓存的查询成果集,而不是从头宣布相同的查询句子,有助于改进音讯吞吐量,从而改进与 WSRR 集成的流的功用。

补白:作为一条规矩,假如音讯处理吞吐量是首要的问题,那么主张您启用缓存。可是,假如您的要害方针是对每条针对 WSRR 中存储的最新的易变内容的音讯进行处理,则应禁用缓存。

每个查询在第一次履行时,一直会经过已树立的依据 HTTP 的 Web 服务衔接发送到 WSRR。默许情况下,此活动会在 WSRR 节点初次宣布一个特定查询时发作,但它或许在署理发动时预先填充缓存。

WSRR 节点在没有缓存时也能够操作。假如缓存被禁用,则会将该节点宣布的每个查询发送到 WSRR,以保证查询的成果一直反映了注册表的最新内容。此选项对功用会发作影响。

WSRR 缓存是以履行小组为根底来供给的,因而是一种跨给定履行小组中的音讯流而同享的资源。在查询(读取)或更新(写入)缓存时,缓存会被承认,不管是被音讯流查询仍是履行动态更新。

WSRR 缓存操作

IIB Execution Groups 中的音讯流调用了 WSRR Endpoint Lookup 或 Registry Lookup 集成节点。来自这些节点的查询会转发到 WSRR 署理,这个 IIB 组件衔接到缓存中保存的曾经查询的成果。
点击这儿给我发音讯

假如缓存中存在针对一个查询的现有条目,则会将相应的数据直接回来给音讯流,而不会对 WSRR 进行查询。假如没有此条目,则会一起对 WSRR 进行查询,该查询的成果存储在缓存中,然后回来到音讯流。

在配备的超时间隔之后,一切缓存条目都会过期并从缓存中删去。这意味着,假如一个查询恳求一个过期的缓存条目所持有的数据,则需求对 WSRR 履行一次全新的查找。

补白:在一个音讯流中的音讯进入 WSRR 节点中时,会在整个履行小组中承认缓存,以便在该节点拜访缓存时保存缓存情况。假如在缓存承认期间收到更新告诉,则会在音讯流抛弃缓存上的锁后来处理更新。因而,在一条音讯和一条告诉一起抵达时,音讯中填入的来自缓存的数据或许不再反映上的数据。

因而,告诉更新或许影响 WSRR 缓存内容;这些内容随后或许在给定音讯实例的流中被下流 WSRR 节点拜访,在该实例中进行处理。因而,关于缓存告诉,咱们无法保证缓存的内容在给定流实例处理某个特定音讯的整个时段内坚持不变。

事实上,由于缓存条目超时(参看下文),署理无法保证缓存内容在给定流和音讯实例的各个 WSRR 节点上是共同性的,不管是否启用了缓存告诉。因而一种或许的场景是,由于缓存条目会在流的上游开释锁后被改写,所以流中的其他 WSRR 节点(处理同一个音讯实例)或许处理不同的值。

虽然每个署理履行小组流程会保护自己的 WSRR 缓存的副本,但一切这些缓存的特征在给定署理实例上是相同的。WSRR 缓存配备参数值与 ServiceRegistries 可配备服务相相关;所以您将需求收回署理,然后才干激活对此服务履行的任何更改。

可是,要丢掉(使失效)某个特定的 WSRR 缓存,只需收回与之有相关的履行小组即可。因而,您应该将任何特定于 WSRR 节点的流别离到它们自己的一个或多个履行小组中。在一组给定流的 WSRR 缓存失效时,选用此办法会强制履行别离,操控这些流并答应其他流坚持活动。

除了让整个缓存失效,还能够在缓存中的各个条目上运用超时。向 WSRR 宣布查询并收到呼应后,会向查询句子以及与之有相关的成果集附加一个时间戳。这意味着每个条目会独自从缓存中超时。

缓存过期超时值能够经过设置与 ServiceRegistries 可配备服务有相关的 timeout 参数来调整。每个缓存条目(缓存的一个查询的成果)会在指定的时间(以毫秒为单位)往后被丢掉。默许缓存过期超时值为 100,000,000 毫秒或大约 27.8 小时。

当一个节点对超时的查询进行下一次引证,会强制将该查询从头发送给 WSRR;相应的成果会代替缓存中过期的条目,并与一个新时间戳相相关。

缓存中可用的成果集条目数量不受约束,也就是说,没有强制规则最大缓存巨细。

WSRR 缓存的上述功用得到了两个额外功的进一步增强,这两个功用相结合,提高了注册表查询进程的功用,简化了为一个可猜测的时间段配备一个服务窗口的进程。下面介绍了相关的功用。

缓存预加载

在默许情况下,缓存中没有预加载任何内容,每个查询在第一次履行时都会被发送到 WSRR。能够指定在署理发动时或初次布置一条包括 WSRR 流的音讯流时履行的预界说查询。这些查询会填充缓存,以供后续 WSRR 节点运用。经过指定预界说的查询,在发动时功用或许遭到影响,而在运转时第一次履行查询时功用不会受影响。

缓存告诉

与过期超时比较,缓存告诉是一种更灵敏的改写缓存数据的办法。它答应在 WSRR 中修正各个 WSRR 条目时让它们在缓存中失效,保证缓存绝不会在其存储的条目中包括过期的数据。

要启用缓存告诉,还有必要启用缓存本身。启用缓存告诉后,缓存会订阅在 WSRR 中发作的事情,并在 WSRR 中的一个方针被更新或删去时取得告诉。在这个场景中,依据超时过期机制,缓存中的条目或许会直接失效,或许经过事情订阅间接地失效。

订阅经过一个依据 JMS 的缓存告诉衔接来完结,该衔接不同于 Web 服务衔接。如上所述,缓存告诉机制用于保证缓存的内容是最新的,并与 WSRR 的内容共同。

WSRR 缓存更新告诉

假定 IIB WSRR 缓存中已加载了数据,并且一个办理 WSRR 体系的用户履行了一项与 WSRR 缓存中的一部分数据相关的更改。WSRR 会向 IIB Cache Update Listener 组件发布一条音讯,以奉告此更改。

Cache Update Listener 收到此音讯后,对缓存中宣称被更改的数据履行操作。履行的操作取决于在 WSRR 中履行的更改类型。假如删去了某一项,那么只会从缓存中删去该项。其他任何操作都将导致缓存过期,以保证缓存坚持共同的情况。默许情况下,这意味着下一次履行一个音讯流查询来恳求此数据时,该恳求会转发回 WSRR。请注意,配备了缓存更新告诉后,超时机制会继续起作用。
在IBM Integration Bus中配备WebSphere Service Registry and Reposi

配备缓存预加载

缓存预加载旨在增强署理中的流功用(音讯吞吐量)。正常情况下,缓存会按需填充,第一次履行某个流中的 WSRR 节点宣布的查询句子时,功用影响是能够承受的。因而关于一个节点处理的第一条音讯(在发动时或一次超时往后),预计会发作与直接从 WSRR 搜集(而不是从本地署理缓存搜集)查询成果相关的本钱。

要改进这种情况,能够在运转时消除这种初始开支。这能够经过提早声明署理或许宣布的已知查询表达式列表来完结;在署理开端发动时,会在履行界说的查询时在缓存中预先加载查询成果,然后再由运转时音讯对任何音讯履行处理。

预界说的 WSRR XPath 查询表达式列表经过 ServiceRegistries 可配备服务的 predefinedCacheQueries 参数向署理揭露。表达式列表(由分号分隔)(每个表达式有一个可选的深度标准)能够直接经过此参数界说。

也能够经过将这些表达式放在一个经过参数指向的文件中,间接地拜访它们。能够经过翻开用户轨道并针对重视的流履行运转时,搜集署理体系宣布的表达式调集。对用户轨道的查看能够显现一切已布置的 WSRR 集成节点生成的 WSRR XPath 查询表达式。

构建服务查询文件

要完结与 WSRR 的署理阻隔,有必要在署理内配备缓存预加载。这使得署理能够在履行小组发动后,从 WSRR 拉取一切已知的服务工件。每次发动署理内的一个履行小组时,或许初次布置一个包括 WSRR 集成节点的音讯流时,都会进行缓存预加载。

缓存完结运用对 WSRR 履行的服务查询作为进入缓存的钥匙。这些服务查询是专一的,并且在配备缓存预加载时,它们需求在运转时以 Endpoint Lookup 节点或 Registry Lookup 节点运用的彻底相同的格局来指定。假如这些查询不知道,承认它们的专一办法是在署理内启用用户轨道,并履行相关的流。然后,查询能够从署理轨道文件读取数据。能够经过两种办法发动用户轨道:

  • 第一种办法是在署理本身内启用用户轨道。轨道类型分为正常或调试。关于此操练,需求将轨道类型设置为调试。这经过运转以下指令来完结: mqsichangetrace <broker_name> -u –e <execution_group> -l debug
  • 第二种办法是从 MQ Explorer 内启用用户轨道。这经过切换到 WebSphere MQ Explorer 来完结。在 Navigator View 中,翻开 Integration Nodes 树元素,并右键单击要启用用户轨道的履行小组。单击 User Trace All Flows,然后挑选轨道等级。在本例中为 Debug。下图显现了该视图:
  • 在IBM Integration Bus中配备WebSphere Service Registry and Reposi

启用用户轨道后,有必要履行或许会履行 WSRR 查询的一切流。履行这些流期间,每次 Endpoint Lookup 节点或 Registry Lookup 节点对 WSRR 履行查询时,该查询都会捕获在轨道中。

它将归于用于创立 Query 文件的查询。一切相关的查询都运转后,开端在轨道文件中扫描短语 ‘BIP3676I’。这是 Endpoint lookup 节点的音讯 ID。它在轨道文件中相似于以下代码:

署理记载的 EndpointLookup 查询字符串用户轨道

2013-12-06 17:01:56.414672    14395   UserTrace   BIP3676I: The query 
string from node ''EndpointLookup'' that will be used to query the 
WebSphere Service Registry and Repository (WSRR) is: 

'/WSRR/WSDLService/ports[binding/portType[@name='MathServerPortType' 
and @namespace='http://math.pot.ibm.com' 
and @version='1.0']
and exactlyClassifiedByAllOf(., 'http://www.ibm.com/xmlns/prod/
serviceregistry/lifecycle/v6r3/LifecycleDefinition#Online')]' 

This is the query string that has been generated to query the WSRR. 
No user action required.

查询字符串能够是放在单引号内的任何内容。所以,在上述轨道中,以下内容是 WSRR 查询:

/WSRR/WSDLService/ports[binding/portType[@name='MathServerPortType' 
and @namespace='http://math.pot.ibm.com' and @version='1.0']
and exactlyClassifiedByAllOf(., 'http://www.ibm.com/xmlns/prod/
serviceregistry/lifecycle/v6r3/LifecycleDefinition#Online')]

此查询字符串有必要修正,才干转义任何单引号。每个单引号有必要替换为 &apos;。新字符串查询相似于以下代码:

/WSRR/WSDLService/ports[binding/portType[@name=&apos;
MathServerPortType&apos; 
and @namespace=&apos;http://math.pot.ibm.com&apos; 
and @version=&apos;1.0&apos;]
and exactlyClassifiedByAllOf(., &apos;
http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
LifecycleDefinition#Online&apos;)]

同样地,轨道文件将包括短语 ‘BIP3685I’。这是 Registry Lookup 节点的音讯 ID。它在轨道文件中相似于以下代码:

署理记载的 RegistryLookup 查询字符串用户轨道

2013-12-06 17:05:14.519078    10849   UserTrace   BIP3685I: The 
following details will be used to query WebSphere Service Registry 
and Repository (WSRR) from node 'RegistryLookup': query string=
'//*[@name='MathService' and @namespace='http://math.pot.ibm.com' 
and @version='1.0']', depth='1'

操控检索的数据将怎么显现的 Depth Policy 是 MatchPlusImmediate。指定的查询字符串和深度将被发送到 WSRR。依据 DepthPolicy 中指定的方位,从 WSRR 回来的信息添加到 LocalEnvironment。假如这些不是您想要的设置,请查看节点特点是否在 LocalEnvironment 中被掩盖,假如运用了 DepthPolicy 掩盖值,请仔细查看该值的拼写。

署理音讯流对 WSRR 履行的查询集应存储在一个独自的文本文件中。该文件中的每个查询字符串有必要由一个分号分隔,一切查询字符串有必要显现在一行上,也就是说文本文件中的任何当地都不能呈现新行或换行符。能够指定和预加载的 XPATH 查询的数量不受约束。以下是一个查询文件的示例:

/WSRR/WSDLService/ports[binding/portType[@name=&apos;
MathServerPortType&apos; 
and @namespace=&apos;http://math.pot.ibm.com&apos;
and @version=&apos;1.0&apos;]
and exactlyClassifiedByAllOf(., &apos;
http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
LifecycleDefinition#Online&apos;)]&apos; 
/WSRR/WSDLService/ports[binding/portType[@name=&apos;
MathServerPortType_V2&apos; 
and @namespace=&apos;http://math.pot.ibm.com/V2&apos;
and @version=&apos;2.0&apos;]
and exactlyClassifiedByAllOf(., &apos;
http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
LifecycleDefinition#Online&apos;)]&apos; 
//*[@name=&apos;MathService&apos; 
and @namespace=&apos;http://math.pot.ibm.com&apos; 
and @version=&apos;1.0&apos;]&apos;, 
depth=&apos;1&apos;

此文本文件需求保存在上或保存在能够拜访的网络方位上。此时,能够经过将轨道等级设置回 None 来禁用用户轨道。正如上面所谈论的,这能够从指令行或 MQ Explorer 完结。

启用缓存预加载

创立查询文件并将它放在上后,是时分将署理配备为在履行小组发动时运用该文本文件了。能够运用更改特点指令来完结此意图,可经过运转以下指令来完结:

启用从文件预加载 WSRR 缓存的指令

mqsichangeproperties <broker_name> -c ServiceRegistries -p 
"<wsrr_query_text_file>" -o DefaultWSRR -n predefinedCacheQueries

将 <broker_name> 替换为运用的署理的称号。将 <wsrr_query_text_file> 替换为查询文件的绝对路径方位和称号。履行笑傲组应从头弄发动,对缓存配备的更改才会收效。从头运转一切测验流,以验证是否一切功用仍按预期运转。

此查询文本仅在发动时运用。缓存中的数据仍会依据缓存过期超时的值而失效。在履行署理内的相关流时,需求再次从 WSRR 抓取失效的条目。

出于这个原因,需求将缓存过期超时设置为一个适宜的值才干创立所需的服务窗口。用于陈述超时值的署理指令的一个示例如下:

陈述对给定署理体系设置的 WSRR 相关特点的指令

mqsireportproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR -r

从成果中能够看到,超时值是在缓存中设置的查询成果将被视为最新(也即有用)的时长。显现的超时值以毫秒为单位。要更改此设置,需求宣布以下指令:

修正对给定署理体系设置的 WSRR 缓存超时特点的指令

mqsichangeproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR –n timeout –v 10000000

正如上面所谈论的,指定的值的巨细,使之满足创立一个能够包容 WSRR、WebSphere Application Server 和 WSRR 数据库实例的晋级的服务窗口。此超时值应由出产团队承认,依据它们一般对指定产品履行一次晋级所花费的均匀时间。

保护查询文件

查询文件初次树立时,应被视为一段源代码,因而放在出产团队的源代码办理体系中。跟着新 Endpoint Lookup 或 Registry Lookup 节点添加到署理流中,它们的相关查询也需求附加到这个文本文件中。树立新的或修正的查询的进程坚持不变,已在上面介绍查询文本文件的开端结构时介绍。因而,此文本文件的结构和修正应遵从团队选用的软件开发作命周期 (SDLC) 流程。

验证缓存

在某个时间(出产前),出产团队将需求承认其署理办理的缓存的操作有用性;具体来讲他们期望测验其运转时署理能否与其方针 WSRR 环境阻隔。

经过这么做,他们将验证凭借已启用和预加载的缓存,WSRR 环境能够撤销激活,而不影响署理运转时的操作。署理将继续运转,没有任何宕机时间。这在 WSRR 的晋级进程中将变得十分有用。

在署理初始发动时一切预加载配备进程都已完结,且缓存填满后,运转的 WSRR 地点的 WAS 实例应中止。这能够经过指令行或运用 WebSphere Administration Console 完结。

WSRR 中止后,一切署理测验事例(WSRR 集成流)将需求出产团队从头履行,他们才干承认虽然没有一个正在运转的 WSRR 体系作为方针,但其署理仍能彻底正常地运转。履行了署理测验事例并验证了它们的操作后,出产团队能够从头发动其 WSRR 实例。

办理缓存和 JVM 堆巨细

运用 WSRR 缓存时会当即想到的一个问题是,出产团队是否需求忧虑打破 JVM 堆巨细约束。也就是说,由于在履行小组中运用了 WSRR 缓存,他们是否需求进步署理中的默许 JVM 约束?此问题没有清晰的答案。

在 IIB 中,您能够经过启用和运用署理发布的资源统计数据,监督 JVM 堆巨细和废物搜集速率。此功用然后将指示出产团队是否需求进步 JVM 约束。署理以各个履行小组为根底发布运用的资源的统计数据;因而要缩小 WSRR 缓存运用数据规模,出产团队应将其 WSRR 流阻隔到一个或多个特定的履行小组中,以便监督。

配备缓存告诉

启用缓存告诉后,在发动包括一个或多个音讯流的履行小组时(其间包括至少一个 Endpoint Lookup 或 Registry Lookup 节点),署理将订阅 WSRR JMS 发布主题:给定 WAS 音讯引擎上的 jms/SuccessTopic。WAS(代表 WSRR)发布的针对此主题的任何音讯,都会由署理收到并被剖析。

假如该音讯为以下事情类型:create、update、transition、make_governable 或 remove_governance,整个缓存将失效。假如音讯为事情类型:delete,那么该音讯所引证的方针(由一个专一的 WSRR 一致资源标识符 (bsrURI) 来标识)会从缓存中删去。收到这些告诉后,当即会对它们履行操作。

假如缓存告诉衔接(出于某种原因)失利,该衔接将无限期地不断重试。频率下降时会发作一条陈述衔接失利的过错音讯,该频率会在每次过错输出后添加一分钟。从头树立衔接后,整个缓存会失效,以保证它不断改写。

在缓存告诉衔接失利期间,缓存条目超时仍会继续发作。如之前所述,缓存超时以每个查询为根底,所以它的开端时间和过期时间都依赖于特定查询第一次宣布的时间。

假如 JMS 衔接由于缓存告诉而丢掉,整个查找流程会测验从头树立一个订阅衔接,也就是说会从头拜访 JNDI 。流中不会抛出任何反常,履行小组将无限期地重试衔接。

启用缓存的 JMS 告诉

WSRR 缓存启用时,假如遭到查找节点的恳求且署理的超时值已过,署理将仅更新一个缓存条目。因而,假如 WSRR 中的一个服务界说在这个配备的超时过期之前被修正,那么署理不会反映该更改,它将回来本地缓存中包括的一个过期的值。

署理中的缓存能够配备来从 WSRR 接纳 JMS 告诉;这些告诉会在注册表体系中的内容更新后当即宣布。

要启用缓存告诉,第一步是运转下面的指令:

在给定署理体系上启用 WSRR 缓存,以开端处理 WSRR 所发布的更新告诉

mqsichangeproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR –n enableCacheNotification –v true

接下来,运用下面的指令设置绑定特点 (IIOP URI) 的方位。

设置 WAS JMS 供给程序 JNDI 绑定地点的体系端点的指令

mqsichangeproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR –n locationJNDIBinding –v iiop://<WSRR_host>:<PORT>

将 –v 参数更改为您体系上的 JNDI 绑定的方位。该参数标明 WebSphere Application Server JMS 供给程序 JNDI 绑定的 URL,其间主机名 <WSRR_host> 是一个变量,标明能够在其上查找绑定界说的网络上的 JNDI 。此设置是署理等级的,会由给定署理的一切履行小组选用。每个履行小组 JMS 衔接会在发动进程中树立。

此外,Internet InterORB Protocol (IIOP) 是一个在 Internet 上运用的 General Inter-ORB Protocol (GIOP) 完结。它在 GIOP 音讯与 TCP/IP 层之间供给了映射。

假如运转的 WSRR 地点的 WebSphere Application Server:

  • 启用了安全性或
  • 供给了一个高可用性环境(一个衔接工厂能够办理多个引导)。

然后,您需求运转以下指令:

设置 JMS 衔接工厂称号的指令;用于查找音讯引擎

mqsichangeproperties <broker_name> -n jms::DefaultWSRR@jms/SRConnectionFactory
 –u <userid> -p <password>

-n 令牌描绘用于衔接到 WSRR 服务集成总线的衔接工厂。履行此指令后,署理实例需求运转以下指令来从头发动:

mqsistop <broker_name>
mqsistart <broker_name>

要承认缓存的 JMS 告诉现在已启用并正确配备,需求在修正的署理环境中从头履行曾经有用且能正常操作的测验事例。举例而言,这儿有一个服务需求在 WSRR 体系中更新;无需从头发动署理或它布置的任何运转时工件,只需从头履行同一个测验即可完结更新。从头履行测验的意图是承认现已检测到注册表更改和署理缓存确实已改写;从而反映了现已运用的更改。

缓存 JMS 告诉和高可用性

到编写本文时,IIB 有一个已知的约束,那就是它只能运用一个简略的(单主机名)IIOP URI 在 WebSphere Application Server (WAS) 命名空间中查找 WAS JMS 供给程序 JNDI 绑定。

署理不支撑多个代替性端点,此设置能够在署理等级上进行运用。依据规则,这个单点毛病用于获取 JMS 供给程序 JNDI 绑定,后者从而用于查找一个衔接工厂;在高可用性环境中,该衔接工厂能够办理多个用于挑选音讯引擎的引导。

要让这个 JNDI 端点更简略运用,能够布置各种不同的体系架构拓扑结构。

虚拟 IP

要在 WAS 集群中的成员之间完结自动高可用性,引荐运用网络设备处理方案。在这儿,咱们运用了一个虚拟 IP (VIP) 来监督 WSRR 中的端口,将恳求路由到活动的运用。

在 VIP 下,IP 地址由某个中心体系(一般是来自 F5 或 Cisco 等供货商的网络设备)来保护,该体系屏蔽了多个后端体系。这些设备供给了许多配备选项来完结跨多个隐藏在 VIP 背面的体系的负载平衡。一个常见的选项是支撑体系之间的自动/被动形式,选用一些惯例端口监督办法来留心后端体系(在本例中为一个 WAS 集群成员,充当着 JNDI )何时封闭。假如可用,此选项是为署理与高度可用的注册表体系之间的集成供给支撑的最轻松的办法。

找到坐落署理机器本地的 JNDI WAS

咱们的意图是供给某个当地来放置 JNDI 方针,重要的是,这个当地在理论上应在署理可用时一直可用。

供给一个灾祸康复环境

为了支撑此使命,能够将 IIOP URI 指向一个动态的主机名。动态主机名相似于 VIP,但经过域名体系 (DNS) 供给,所以该处理方案不需求网络设备。可是,需求操控的 DNS 记载。一种办法是在本地操作体系上创立一个简略的 hosts 文件,它能够经过任何脚本更新。在这儿,DNS 在任何时间都只包括一个条目,但某个体系会依据 WAS 端的监督情况来动态更新它。支撑此办法的已知的监督技能包括:AIX PowerHA (HACMP)。

出产保护

非高可用性环境中的服务晋级

这样一个 WSRR 环境中的第一个晋级进程是,保证在单一方针 WSRR 体系中止期间,署理办理的 WSRR 环境不会失效。由于无法承认某个保管缓存中的条目前次是何时失效的,所以引荐从头发动每个布置到出产运转时的履行小组,一次一个。再次声明,只包括一个或多个音讯流的履行小组(其间至少包括一个 Endpoint Lookup 或 Registry Lookup 节点)需求收回。

经过按次序从头发动每个履行小组,整个署理环境绝不会彻底不可用。完结从头发动后,一个履行小组具有的一切缓存都将当即填入来自 WSRR 的一切需求的数据(假定配备了预加载),并且在署理级缓存过期超时抵达之前不会失效。

此超时值应由出产团队设置;它应该有一个满足大的时间窗口,以便包容方案的服务晋级活动。在非高可用性环境中,只要一个 WSRR 体系可供署理运转时拜访。在服务晋级期间,此体系将处于离线情况,所以署理树立的 Web 服务衔接会丢掉。在这样一个场景中,假如现已超过了某个特定条目上的超时值,那么署理办理的缓存将无法支撑 WSRR 查找。这些条目已失效;导致它们的过期数据被毁掉,虽然事实上没有活动的 Web 服务衔接可供运用。

下一步是履行修正包或最新版别所供给的引荐的晋级流程。

运用缓存告诉进行提高

关于启用了缓存告诉的 WSRR 下的同步提高,在成功完结事务之前,绑定到给定提高操作的事情不会提交到 SuccessTopic。因而,在成功地完结 WSRR 生命周期过渡后(这会触发一次提高),出产团队应防范生命周期过渡的成功事情被署理处理。

对此事情的处理的承认信息将会显现在署理服务轨道中(假如已启用),其间此事情标明绑定到给定提高操作的最新事情;因而在这个时间之后,与在 WSRR 中提交的具有事务操控的同一个提高操作有相关的未来事情不该让 WSRR 缓存从头失效。

此时,出产团队能够安全地封闭服务轨道,发动或从头启用其 WSRR 流,以便能够继续针对其彻底更新的 WSRR 体系处理音讯。关于大多数出产团队,将无法挑选翻开服务轨道。最佳实践主张创立一个服务流,将它布置到每个受影响的履行小组中。这个流将包括一个衔接到 TraceNode 的 JMSInput 节点。这样一个流能够在提高之前发动;发动它的意图是捕获 WSRR 发布的 JMS 成功主题事情并将它们写入文件中。

在 JMSInput 上设置的 Location JNDI 绑定 JMS 衔接特点,并将它设置为对 ServiceRegistries 可配备服务的 locationJNDIBinding 特点设置的相同值。所以上述操作的条件是在提高进程中禁用音讯流,保证没有针对 WSRR 体系或署理缓存处理任何音讯;WSRR 体系或署理缓存或许处于过渡情况,因而它们的内容或许不共同。

可是,在与方针 WSRR 体系的集成仅限于 EndpointLookup 节点的情况下,不共同性标明存在问题,也就是说,您要么取得一个旧端点,要么取得一个新端点。在这种场景下,在提高活动期间无需中止工作流。

关于注册表查找,情况又有所不同。咱们不期望缓存保存不共同的数据,即一切更新(除了删去)导致整个缓存失效,但删去仅会让受影响的特定条目失效。因而,在理论上,咱们能够在一次提高之后处理过期数据和最新数据的混合体。

在一次提高之后提交整个事务之前,不会向成功主题发布任何事情。事情音讯的次序和它们的类型(将由署理拉取和处理)都是是不知道的;所以缓存或许不会当即失效,因而会强制抓取一切后续的查询恳求。

经过启用的缓存来提高

在这儿,假定咱们遵从了最佳实践攻略,因而将一切特定于 WSRR 的流阻隔到自己的履行小组中。在 WSRR 出产注册表经过提高来晋级之前,出产团队应中止 WSRR 履行小组,以便中止对出产注册表处理更多音讯并让整个缓存失效。

然后,他们应该将条目过渡到暂存体系中,以便提高它,并将同一个受操控的调会集的方针条目过渡到出产环境中。他们应该监督 WSRR 中的同步提高,承认过渡已成功完结。最终一个进程是从头发动 WSRR 履行小组,继续对晋级的出产注册表处理新音讯。一切查询成果集开端都将经过直接调用出产体系来获取。应该将抓取的成果与它们的查询相结合,以便在缓存中填入一个新查询条目。后续调用可直接从缓存中抓取,这些条意图默许超时值应适当地进行延伸,以合适团队的操作需求。

在与方针 WSRR 体系的集成仅限于 EndpointLookup 节点时,注册表的内容在工件提高期间不共同也不会导致问题。与上面相同,在这个场景中,在提高活动中无需中止工作流。

问题扫除

从署理衔接到 WSRR 时的过错

要确诊这种一般性过错,能够履行以下查看:

查看指向您的注册表的端点地址值。从指令操控台,运转以下署理指令,将 <broker_name> 替换为您署理的称号,以显现与它有相关的 WSRR 特点:

mqsireportproperties <broker_name> -c ServiceRegistries 
–o DefaultWSRR -r

上述指令将生成一个相似输出的呼应:

ReportableEntityName=''
ServiceRegistries
DefaultWSRR=''
connectionFactoryName='jms/SRConnectionFactory'
enableCacheNotification='false'
endpointAddress='http://<host>:<port><web service interface url>'
....

假如未衔接到安全的 WSRR ,那么您应该能够将陈述的 endpointAddress URL 值复制到浏览器中,并取得有用的呼应,也就是说,体系没有回来 404 Not Found 或 5xx server error 作为情况代码。例如,考虑下面这个无效的 URL 和回来的呼应:

http://localhost:9080/WSRR_9/services/WSRRCoreSDOPort
Error 404: 
com.ibm.ws.webcontainer.servlet.exception.NoTargetForURIException: 
No target servlet configured for uri: /WSRR_9/services/WSRRCoreSDOPort

以下是有用的 URL 和在发送给 WSRR V8.0 体系时相应的呼应的示例:

http://localhost:9080/WSRRCoreSDO/services/WSRRCoreSDOPort            
{http://www.ibm.com/xmlns/prod/serviceregistry/6/0/ws/sdo}WSRRCoreSDOPort
Hi there, this is a Web service!

http://localhost:9080/WSRR6_1/services/WSRRCoreSDOPort
{http://www.ibm.com/xmlns/prod/serviceregistry/6/1/ws/sdo}WSRRCoreSDOPort
Hi there, this is a Web service!

http://localhost:9080/WSRR7_5/services/WSRRCoreSDOPort
{http://www.ibm.com/xmlns/prod/serviceregistry/7/5/ws/sdo}WSRRCoreSDOPort
Hi there, this is a Web service!

http://localhost:9080/WSRR8_0/services/WSRRCoreSDOPort
{http://www.ibm.com/xmlns/prod/serviceregistry/8/0/ws/sdo}WSRRCoreSDOPort
Hi there, this is a Web service!

假如上述操作不起作用,则标明未正确指定 URL。一般 <host> 或 <port> 值存在问题。请保证供给的主机名是彻底限制的。例如一个彻底限制的主机名为:pic.dhe.ibm.com,而不是 pic.dhe。

关于不同的 WSRR 版别,支撑运用不同的 URL 来拜访揭露的 Web 服务接口。更高的 WSRR 版别支撑其自己的 URL,并且为了完结向后兼容性,它们还支撑同一个 URL 的前期版别。

  • 例如,WSRR 6.0.2 版支撑的中心 Web 服务接口 URL 为:/WSRRCoreSDO/services/WSRRCoreSDOPort,
  • 而同一个 URL 针对 V6.1 的版别为:/WSRR6_1/services/WSRRCoreSDOPort。

因而,请在陈述的值中查看 <web service interface url>,保证它兼容您的方针注册表体系。例如,运用 V6.1、V6.2 或 V6.3 兼容性 URL 而不是 V6.0.2 兼容性 URL 时,V7.0.0.3 到 V7.0.0.6(以及 APAR IC84693)供给了 WSRR V8 支撑。关于对 WSRR V7.5 的相同署理等级的拜访,没有 V6.2 和 V6.3 兼容性 URL 可供运用。

请运用受您的署理和 WSRR 体系组合支撑的最高的 Web 服务接口版别。例如,关于 V9,运用 V6.3 中心 Web 服务接口 URL:WSRR6_3/services/WSRRCoreSDOPort。

拜见 参考资料 部分,获取有关哪些 Web 服务接口 URL 可用于某个特定 WSRR 版别的信息的链接。另一个链接显现了特定署理版别和渠道的体系需求;更具体来讲,在产品协作部分中,列出了不同 WSRR 版别供给的功用。

运用 WAS V8.0 时,假如期望启用和运用 JMS 缓存告诉支撑,默许的 IIOP 安全设置有必要被设置为支撑 SSL。关于 WAS 的更高版别,默许的 JMS 安全性设置应从 supported 更改为 enforced。

从 MQ Explorer 启用并查看署理用户轨道。指定的端点地址有必要是正确的,但您仍有或许看到无效的呼应。例如,考虑呼应 GIOP。这个呼应是一般性的呼应,提示在与 WSRR 通讯时某处出错了。这或许标明在绑定到 WAS 时呈现了一个反常,在 WAS 中,在洽谈 General Inter-ORB Network Protocol 期间呈现一个过错。

因而,在此实例中,下一步或许是生成一个署理服务轨道。此轨道能够捕获在产品测验交互时生成的反常(假如有)。它能够杰出显现署理中呈现过错的当地,该过错是否从 WSRR 发回,或许署理是否未正确处理了某个过错。考虑下面这段与这类呼应绑定在一起的示例服务轨道片段:

...'WSRRMbLogHandler:FINEST' , 'BUFFER RELEASED: Calling Element: 
com.ibm.ws.http.channel.impl.HttpServiceContextImpl.clear 
(HttpServiceContextImpl.java:993) Main ID: 0'

...'WSRRMbLogHandler:FINEST' , 'BUFFER RELEASED: Calling Element: 
com.ibm.ws.genericbnf.impl.BNFHeadersImpl.clearBuffers
(BNFHeadersImpl.java:502) Main ID: 0'

...'WSRRMbLogHandler:FINER' , 'close(), 
com.ibm.ws.tcp.channel.impl.TCPConnLink@3d66c39 Entry'

...'WSRRMbLogHandler:FINEST' , 'Closing the connection: remote host 
name: wsrrhost.corp.xyz.com remote host address: x.x.x.x local host 
name: brokerhost local host address: x.x.x.x'

...'WSRRMbLogHandler:FINEST' , 'Connection closed with exception: 
Connection close: Read failed.  Possible end of stream encountered. '

...'WSRRMbLogHandler:FINER' , 'destroy(Exc) Connection close: Read 
failed. Possible end of stream encountered.  Entry'

...'WSRRMbLogHandler:FINEST' , 'Destroying the connection: remote host 
name: wsrrhost.corp.xyz.com remote host address: x.x.x.x local host 
name: brokerhost local host address: x.x.x.x'

...'WSRRMbLogHandler:FINER' , 'close Entry'

...'WSRRMbLogHandler:FINEST' , 'SocketChannel close starting, local: 
brokerhost/x.x.x.x:38775 remote: wsrrhost.corp.xyz.com/x.x.x.x:9080'

...'WSRRMbLogHandler:FINE' , 'SocketChannel close, local: 
brokerhost/x.x.x.x:38775 remote: wsrrhost.corp.xyz.com/x.x.x.x:9080'

查看服务轨道能够看出,好像抛出了一个 IOException (Connection close:Read failed)。瘦客户端成功地树立了衔接并读取了一些数据,但随后,出于某种原因,衔接被封闭了。

提示:为了筛查出这个 WSRR 瘦客户端的轨道,来自 WSRR 的一切署理日志条目都将包括 WSRRMbLogHandler。在以这种办法进行过滤时,支撑越过一切类加载条目。

为您引荐: IBM 缓存 Integration Bus
咱们感兴趣的内容
小伙伴独爱的新闻
小伙伴还重视了以下信息
小伙伴重视的焦点

小伙伴都在重视的抢手词

芈月传 老司机玩法 萌乐网 黑科技 坐骑揭秘 三国令 铁血皇城 竞技场攻略 书剑恩仇录 披风玩法 配备强化攻略 户外BOSS玩法 全网曝光 赤壁传说 半回合制国 ACT 哥们网 天书国际 奇珍商城 热血战歌 传奇瑰宝抽奖 门徒 范伟打天下 翻开办法 门徒获取玩法 三大萌宠简介 新手攻略 挂机体系简介 资料副本 大海战 鸵鸟 大黑 热情玩法 门徒战力提高 万世 强化特点 上古降魔 提高战力 配备攻略 九阴绝学 质量引荐 老干妈 激战来袭 大黑游戏 新服亮点 福利多多 画江山 资料片 玩家 九阴真经 江湖儿女 实在场景 实际 虚拟 随机副本 风色轨道 听其自然 ppwan 神助攻 武林秘药 激活八大脉门 九霄劫变 猎命格 天问 大型PVP 花千骨 激战更尽兴 网易mumu 手游玩家 安卓模拟器 安卓 单挑群战 武侠传说 女神 孙尚香专访 胸猛抱团 新游 占山为王 跨服城战 蜀山战纪 剑雨江湖 攻略 实时VR交互 七大女神代言 酷炫走江湖 国际四大杀手 玩家专访 三国经典 大制造 好玩网页游戏 盘点 世界霸主 境地玩法 莽荒纪 勇闯难关 镜像副本 荒漠霸主 配备通晓 三大战役 鹌小彦奇谈