面向服务的某些方面最适合使用 IBM® WebSphere® MQ 集群来提供。集群可以提供位置独立性、运行时名称解析，以及 SOA 应用程序所需要的并发性。由于这些原因，SOA 的采用正在推动从点对点消息网络到集群环境的迁移。本文研究队列管理器的迁移、故障转移和扩展在 SOA 上下文中会受到如何的影响。

　　来自IBM WebSphere Developer Technical Journal。

　　消息对 SOA 的影响

　　在任务：消息的前一部分中，我曾写到从点对点消息体系结构到面向服务的发展要求更新消息领域中的许多长期存在的最佳实践。这里，我们将考虑一个案例研究，以了解队列管理器的迁移、故障转移和扩展，以及在 SOA 的上下文中考虑这些活动时对命名约定、工具、管理流程和操作的影响。

　　首先让我们了解一些术语：

        本讨论中的迁移包括任何重新承载队列管理器的情况，也许是为了更新基础硬件或者为了移动到不同的平台。迁移将始终涉及到构建新的队列管理器、将应用程序和队列逻辑地移动到新的队列管理器，以及最终使旧的队列管理器退役。

        故障转移是主系统在计划内或计划外的关闭，并包括完成将备用节点置于在线以接管处理负载的任务。补充操作在主节点恢复时退回主节点。典型示例是灾难恢复测试，其中涉及故障转移到热备用系统、测试应用程序，然后退回到主系统。

        水平扩展的定义是更改集群中的输入队列的并发实例数量，以便增加或减少处理容量。水平扩展以适应增长通常是永久性的。扩展以适应高峰处理季节是首先增加然后减少容量的周期性过程。扩展过程可能涉及也可能不涉及构建新的队列管理器，并且通常不涉及对现有实例的任何更改。

　　面向服务的某些方面最适合使用 IBM WebSphere MQ 集群来提供。集群可以提供位置独立性、运行时名称解析，以及 SOA 应用程序所需要的并发性。由于这些原因，SOA 的采用正在推动从点对点消息网络到集群环境的迁移。

　　点对点范式

　　大多数历史悠久的 WebSphere MQ 工作室都会至少遇到一次硬件迁移，并体验到足够多的增长以致要求在某个时候进行扩展，因此可能存在用于这些活动的既定过程。但愿所有团队都拥有灾难恢复计划，甚至是刚开始使用 WebSphere MQ 的团队。这些过程应该是什么样的呢？在点对点的世界中，迁移、故障转移和扩展通常是不同的，彼此之间千差万别。

迁移：将迁移作为单个事件来计划和实施是非常普遍的，其中所有的任务都在不间断的序列中进行，包括新的目标队列管理器上的大量构建和配置活动。通过这种方式，可以捕获即将退役的队列管理器的当前状态，并将其毫发无损地移动到新的主机。由于是一次性的活动，因此很少有（如果有的话）退回的余地。

故障转移：故障转移的目标是在两个功能等效的队列管理器之间切换。尽管它们是（至少应该是）具有不同名称的不同队列管理器，但是对于网络的其他部分来说，两者之间的唯一明显区别是 CONNAME。由于故障转移始终预期要退回，因此花时间创建可促进活动一致、可靠和可重复执行的自动化或流程是值得的。通常，故障转移涉及到一个独立于实际切换执行的扩建阶段。

扩展：与适应周期性负载相比，升级容量是更常见的扩展情况。因此，大多数扩展情况都是计划的，并作为一次性的事件来执行，这一点与迁移类似。主要的区别在于，在该事件之后，将创建过程以确保队列管理器的所有实例保持同步，并将应用于一个实例的更改应用于所有的实例。

　　点对点实现

　　在此体系结构中，队列管理器是对象名称的根上下文，用于管理和操作的过程反映了这种倾向。由于在点对点网络中更改队列管理器名称具有干扰性，因此在故障转移和迁移过程中对队列管理器和通道重用相同的名称非常有诱惑力。这实际上是一种反模式；有些主意起初看起来像是正确的想法，但后来通常证明是一场噩梦，这就是其中之一。尽管队列管理器名称重用存在问题，我看到过的大多数迁移计划还是依赖于它。结果，要让两个队列管理器同时在线将非常困难或根本不可能，从而影响迁移任务的计划和执行。

　　在可扩展性的情况下，其中的主要目标是并发性，重用队列管理器名称导致的问题比它解决的问题还多，因此通常不存在创建重复命名的实例的诱惑。在此情况下，通常使用队列管理器别名来实现节点等效性，但是总体效果仍然是在其队列管器的上下文中解析队列。

　　点对点体系结构的另一个方面在于，运行时配置往往保持相当的静态。事实上，许多流程和过程假设配置具有稳定性。例如，以对象定义的情况为例。在许多工作室中，对象定义存储在 mqsc 脚本中。该脚本的初始版本包含队列管理器的本地基准，例如设置死信队列、锁定远程管理访问以及优化通道。然后，特定于应用程序的对象添加在各自的脚本中或添加到主脚本。随着新队列、主题和其他对象的添加，脚本被再次运行。此操作重新定义了已有的现有对象并创建任何新对象。典型的示例类似如下：

　　清单 1
　　DEFINE QLOCAL (APP.FUNCTION.SUBFUNCTION.QA) +
　　       DESCR('APP service queue for QA') +
　　       BOTHRESH(5) +
　　       BOQNAME('APP.FUNCTION.BACKOUT.QA') +
　　       CLUSTER('DIV_QA') +
　　       CLUSNL(' ') +
　　       DEFBIND(NOTFIXED)
　　       REPLACE

　　第一次运行此定义时，创建了本地队列 APP.FUNCTION.SUBFUNCTION.QA。REPLACE 选项确保该定义在后续运行时不会生成错误。这里的关键在于，所有的网络维护活动均在构建时执行。这里的例外是故障转移。由于故障转移被设计在系统之中，执行它的脚本和补充退回脚本通常是预先创建的。通常，还存在 mqsc 脚本，但是与包括 DEFINE 语句不同，它们包括类似如下的 ALTER 语句：

　　清单 2
　　ALTER CHANNEL(QM1.QM2) CHLTYPE(SDR) +
　　       CONNAME('host.of.qm2(1414)')
　　       PUT(DISABLED)
　　  
　　RESET  CHANNEL(QM1.QM2)

　　这样将创建一组执行故障转移的脚本和另一组执行退回的脚本。尽管这些脚本在运行时执行，但是值得注意的是，它们使用与构建时活动相同的工具。还要注意，消息的路由是通过重新连接物理网络来完成的。稍后我们还将谈到这一点。

　　在点对点时代指导 WebSphere MQ 最佳实践发展的重要假设中，至少有两个假设在面向服务的体系结构中不再成立。这样的假设还有许多，但是有两个假设与这里的说明相关。它们分别是：

　　队列管理器是名称解析的根。
　　对象定义是相对静态的。
　　正如您在上面看到的，结果是几乎所有操作均为构建时操作，更改队列管理器名称干扰了对象名称解析，对消息路由做出更改需要重新配置物理网络

评论 (0) All

登陆 还没注册？