任务:消息传递

关于老鼠和大象

共享资源的多种消息类型就像全都关在同一个笼子中的动物园动物

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 任务:消息传递

敬请期待该系列的后续内容。

此内容是该系列的一部分:任务:消息传递

敬请期待该系列的后续内容。

在每个专栏中,“任务:消息传递”讨论的主题旨在鼓励您重新检查您对 IBM® WebSphere® MQ 及其在您的环境中的作用的看法,以及为什么您应该定期地注意它。

消息动物王国

事后表明,每个项目中都会存在这样的情况,某些决策在此时变得令人很痛苦。对于许多 SOA 项目,你会突然认识到并非所有消息都是生来平等的。为了说明这一点,可以设想一个 Web 应用程序,其中将大量的轻量级用户查询交互转换为 WebSphere MQ 消息。然后将这些非常小的非持久消息发送到后端系统,后端系统通常在一、两秒内生成应答并发回给用户。假设将这些消息看作是老鼠。现在,设想有第二个应用程序,其中用户上载由许多更新事务组成的数兆字节的大型文件。这些内容转换为非常大的持久 WebSphere MQ 消息,并传输到后端系统以进行处理。可以将这些消息看作是大象。

向已经有老鼠在自由奔跑的网络中添加大象,可以预料会导致大量被踩踏的老鼠。然而,通常令人猝急不防的是,反过来也是如此:向为大象而优化的系统添加老鼠,会导致大量受惊的大象。当将该问题视为一个简单的线性扩展时,这似乎是有违直观的。只需添加 CPU、磁盘和内存,直到系统能够处理大象,所有的问题都会消失,对吧?毕竟,根据推理,如果我们有更大的马力来四处移动大象,小小的老鼠不足挂齿。当然,事实在于,优化网络以同时处理这些显著不同的数据分类即便可能,也是极其困难的。

我喜欢将这种情况描述为“老鼠和大象的问题”,因为用这些术语可以立即明白所述的问题。但是还存在其他许多消息类型:

  • 取决于业务需求,消息可能需要也可能不需要加密(好比豪猪和负鼠)。
  • 消息的业务价值可能是长期存在的,或者可能在数秒内消失(好比乌龟和兔子)。
  • 有些消息仅在协同事务的上下文中有价值,而其他消息则在独立事务的上下文中有价值(好比海豚和鲨鱼)。

没有人希望去动物园看到所有的动物关在同一个笼子里,或者甚至是关在相同类型的笼子里。老鼠和大象以及海豚和鲨鱼应该关在单独的笼子里的概念是非常直观的。但是在构建消息网络的时候,人们往往将要求降低到某一数量的消息,其中“消息”是抽象的原子数据块,“数量”不过就是某段时间内的消息的整数数量。虽然这无疑是有用的信息,但它没有准确描述消息网络所需要支持的实际业务需求。

为您的消息设计栖息场所

我的几个客户陷入了麻烦,因为他们将消息网络设计为使用相同的组件来进行横向扩展。他们以为解决性能问题的唯一方法是添加更多的处理能力或更多的节点,并在节点之间均匀地分布流量。随着新的应用程序的实现,每个应用程序具有独特并且通常是冲突的需求,优化网络来处理所有这些不同类型的流量变得日益困难,并且这种情况最终会导致中断。有时候,我被介绍进来帮助进行系统优化。当我出现在现场的时候,始终看到的是非常危险的信号,并且老鼠、大象、负鼠、豪猪、海豚和鲨鱼全都在同一个空间中四处乱撞。优化并不是解决此问题的方法。

动物园通过按将要包含的动物种类来定制栖息场所,从而提供分类服务。通常,具有相似需要的不同动物可以共用某个区域。瞪羚和角马可以完美地和谐共处。其他动物基本上是不相容的,并且不共享任何资源。水栖动物获得池塘,陆栖动物获得某种笼子。在消息网络上提供分类服务并没有太大的区别。您不能构建单一的消息网络并预期它处理您扔在其上的每种类型的消息,但是您可以在网络中构建专用的路由或节点,并优化它们以适应各种不同的需要。

然后的关键就是了解消息流之间共享哪些资源,冲突出现在何处,然后在适当的级别隔离流量。可以使用许多不同的条件来区分消息网络上的分类服务。其中一些较常见的条件包括:

  • 业务价值存续时间:有些消息如果不在短时间内进行处理,则会失去其业务价值。其他消息可以延迟数小时或数天而不会失去价值。一般情况下,将具有短时间业务价值的消息隔离到较高吞吐量的硬件上,而具有长时间业务价值的消息则可以路由到较慢并且可能较廉价的硬件上。
  • 数量:有些接口每秒、每小时、每天传递非常大量的消息。超过某个阈值以后,巨量的消息可以推动接口进入单独的服务分类。
  • 大小:这里的关键不是大小,而是不同消息类型之间的相对大小区别。为始终如一地大或始终如一地小的消息进行优化并不困难,但是为极端的变异性而进行优化则非常困难。
  • 保密和完整性:当消息网络或消息数据量非常大时,对所有流量加密的代价高得惊人。如果需要加密的流量部分相对较小,则为其划出单独的服务分类也许是适当的。
  • 持久性:取决于消息是否持久,在队列和通道方面的吞吐量差别是相当大的。

让我们看一个特定的例子。

解决老鼠和大象的问题至少要求不同类型的消息通过不同的通道和传输队列。取决于消息量和服务器的容量,可能有必要采取附加步骤,并创建单独的队列管理器,或者创建到不同服务器的单独消息流。不同环境中的最佳解决方案是不同的。这里的权衡是在减少共享资源数量的时候,复杂性、许可证成本和管理开销可能会增加。业务案例表明,与您在拥有足够的处理能力来满足服务级别要求之前花在问题上的资金相比,这些成本通常要少得多。

表 1. 按拓扑排列的共享资源
队列拓扑通道XMitQ磁盘CPU/内存网络接口卡
集群队列管理器XXXXX
重叠集群-XXXX
点对点通道--XXX
一个节点上的多个队列管理器---XX
多个节点上的队列管理器-----

表 1 表明集群队列管理器上的应用程序共享许多资源。其中的行表示不同的 WebSphere MQ 拓扑,列表示 WebSphere MQ 使用的不同资源。让我们考虑一下每种拓扑:

  • 集群队列管理器:集群队列管理器上的应用程序共享许多资源。这是将所有类型的动物混合关在单个笼子里的经典示例。
  • 重叠集群:您可以通过添加重叠集群来将流量划分到不同的通道上。这可以提供基于通道优化来进行区分的机会。例如,您可以在一个启用了转换的通道中发送字符串数据,并沿着另一个通道发送二进制数据。也许一条路径使用加密,另一条路径使用纯文本。当多条路径属于集群通道时,您可以按不同的方式优化它们,但是它们仍然全都共享同一个传输队列。如果这是问题,例如对于老鼠和大象来说就是问题,那么您需要提供更多的隔离。
  • 点对点通道:创建专用的点对点通道是在网络中建立单独路由的另一种方法,这种方法可以提供专用的传输队列。现在您能够优化一组通道和关联的传输队列,并根据预期的消息类型来定制每个通道和队列。创建独占式的点对点网络失去了集群的优点,因此通常的实现是混合的,其中集群处理大部分流量,并创建有限数量的点对点通道来提供差异服务分类。
  • 一个节点上的多个队列管理器:在某些情况下,需要完全单独的队列管理器。这为您提供了在队列管理器级别根据特定类型的流量来优化几乎所有一切的能力,例如,当存在针对最大句柄数量、最大未完成工作单元数量、日志文件大小、代理参数或任何其他队列管理器全局设置的特定要求时,这可能是非常有帮助的。如果您的老鼠和大象都采用持久消息,则它们将具有冲突的日志文件优化要求,从而可能导致您选择需要单独队列管理器的解决方案。我通常建议不要在一个服务器上放置两个或三个以上的队列管理器,因为这样做以后,操作系统的可优化性将开始受到影响。
  • 单独节点上的队列管理器:最后一个选项是在不同物理服务器上的队列管理器之间划分流量,其中每个队列管理器为不同类型的消息做了优化。通常使用这种模式来将批量的长时间流量与短时间的高吞吐量流量隔离开来。在此情况下,将对快速流量使用较昂贵的高容量硬件,而批量流量则由具有大型磁盘分区的普通硬件来处理。

值得提及的是,分类服务向二维网络增添了第三个维度。这增加了复杂性,从而意味着也增加了成本。如果解决方案需要附加的队列管理器,可能会导致堆积其他软件组件的更多实例,并包括更多的服务器。还应该在应急计划中考虑所有这些新组件。这里的业务案例在于,仅当比简单地通过增添处理能力来解决问题更廉价的时候,才增建分类服务。

适应您的实现

如果您的消息网络非常小,您可能想知道如何预测从现在开始的一年内将需要哪些分类服务。或者,如果您有一个已建立的网络,您可能已经在努力解决这些问题,并且想知道如何改进网络以适应分类服务。在任一种情况下,关键都在于灵活设计以轻松实现分类服务。虽然似乎有违直观,但是遵守严格的标准可以通过改进互操作性和减少网络中的依赖关系来提高灵活性。

下面是一些适用于本讨论并且值得重复建议的最佳实践:

  • 保持简单。当存在两种提供相同功能的配置时,较简单的配置是首选。仅当能够处理较简单的配置所无法处理的一些业务需求时,才添加复杂性。例如,重叠集群以解决命名空间问题几乎从来就不是个好主意,但是重叠集群以提供加密的网络路径也许是恰当的解决方案。
  • 标准化队列名称中的节点和节点分隔符。由于句点字符对于 Object Authority Manager 非常重要,因此通常是首选的分隔符。对象名称中的节点通常从左到右和从一般到特定地进行构造。
  • 根据所表示的服务来命名队列。用 SOA 术语来说,这是“寓意”名称。根据 SOA 原则,对象的名称揭示其功能,而不是揭示如何实现该功能。请不要包括物理属性,例如队列管理器名称、发送应用程序名称(这是旧式的点对点做法)或队列类型。务必在队列名称中包括服务版本,以便能够独立于服务使用者部署新的服务版本。
  • 在对象名称中为分类服务限定符保留空间。您目前不一定需要使用该限定符,但是只要为其留出了几个字符的空间,以后您就可以添加该限定符。
  • 在 CLUSRCVR 通道名称中包括集群名称。众所周知的示例是 <cluster>.<qmgr>,它为每个集群产生一个专用的 CLUSRCVR。当集群重叠的时候,这使得集群的管理更加容易和更加可靠,但是也的确限制了集群和队列管理器名称的长度。
  • 了解您的数据。对消息网络进行检测以捕获运行时流量统计信息,并将实际数字与开发团队在实现前提供的估计数据进行协调。仅基于消息计数是无法充分地管理网络的。您需要了解大小、持久性、优先级和频率分布,还要能够使数据流中的消息关系相互关联起来,例如将请求与应答进行匹配。除非将实际流量与估计数据进行协调,否则估计数据的质量决不会得到改善。更糟的是,如果您不了解消息延迟,那么您在接近某个阈值并且即将违反 SLA 时,将不会有任何预兆。
  • 继续教育非常重要!将队列和队列管理器中的所有交互和设置的描述精简到一两篇文章中是不可能的。不存在深入了解消息产品并将该技能应用于您的特定环境的捷径。我非常希望向您销售服务,您的企业将通过培训增长专业技能来获益。

当您看到两个不同的消息流对某个系统优化值施加冲突的要求时,您将能够认识到这个问题。例如,偶尔大象会将您的老鼠流中断几秒钟,并且您无法优化通道批量大小以同时适应这两种消息类型。此时,上面提到的命名和其他标准将使您很容易在现有网络中添加 MQ 通道、队列或集群。所提到的检测将帮助您决定何时以及在何处将消息流移动到专用资源上。最后,教育将使您可以执行必要的分析和设计,并最终完成成功的实施。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=338356
ArticleTitle=任务:消息传递: 关于老鼠和大象
publish-date=09182008