WebSphere-Message-Broker-开发和部署最佳实践.doc

WebSphere Message Broker 开发和部署最佳实践 2009 年 1 月 19 日 本文以多个客户企业的经验为基础，给出了使用 WebSphere Message Broker 来开发和部署可靠且可扩展的 ESB 解决方案的一些最佳实践。 引言 IBM? WebSphere? Message Broker（以下称为 Message Broker）可以作为企业服务总线使用，提供用于各种协议的通用连接以及为使用结构化和非结构化数据的应用程序提供数据转换功能。 消息处理性能取决于很多因素，包括硬件能力、软件配置、消息流和消息格式设计及实现，以及消息流实例的数量。本文将描述为众多客户带来了性能和消息流服务可用性改善的实现和部署最佳实践。虽然本文并不讨论关联的 WebSphere MQ 和数据库实现的最佳实践，但会从消息代理应用程序的角度对其有所涉及。最佳实践并不是万能的，在某些情况下，此处所述的最佳实践需要进行修改，以满足体系结构灵活性和适应客户的具体需求和能力。 最佳实践领域 消息流 消息流开发阶段的最佳实践，包括如何避免会导致性能问题的消息流实现。 ESQL 消息流中的 ESQL 开发阶段的最佳实践，包括开发可重用代码和尽可能减少消息流中的优化 ESQL 代码（单从性能改善的角度而言）。 发布/订阅 针对使用发布/订阅模型路由消息的人员的最佳实践。不涉及总体最佳实践和克隆最佳实践。 从 Message Broker 的角度确定的 WebSphere MQ 最佳实践 此部分并不描述所有相关的 WebSphere MQ 最佳实践，但会说明在使用 Message Broker 作为 MQ 客户端应用程序时如何调整 WebSphere MQ 来改善性能。 从 Message Broker 的角度确定的数据库最佳实践 此部分并不描述所有相关的数据库最佳实践，但会说明在使用 Message Broker 作为 MQ 客户端应用程序时如何调整 WebSphere MQ 来改善性能。 配置 Message Broker 设置、配置和部署阶段的最佳实践。不涉及特定于高可用性环境的最佳实践。 消息流 通常，为了将配置信息同业务逻辑分离，客户会将配置信息外部化到文件或数据库中。此技术可能会降低性能，因为读取配置或参数文件是在创建节点的第一个实例时或处理第一个消息时的一次性活动，而不会对每个消息都进行循环检查。由于 Message Broker 更多的是面向 CPU 而不是 I/O，通常最好尽可能避免涉及文件或数据库的 I/O 操作。 尽可能使用部分解析方法，除非业务需要消息的完整解析。在消息流的最后，如果有输出节点（如 MQOutput），则将出现消息、转换为位流），会解析完整的消息。此 Message Broker 功能能帮助改进性能，因此尽可能对其加以利用。 处理成本与消息树的大小之间存在直接的正比关系。因此，消息树大小和设计在处理成本中扮演着重要的角色。例如，将所有这些可能使用的字段都放置在决策中，以在消息的开始位置路由消息。由于对消息树进行部分解析时并不会完全解析，因此消息将路由到下一个节点。如果消息在 Header 中包含用户可维护的数据文件夹（如 MQRFH2 usr 文件夹），则建议最好在其中存储决策路由元素。 尽可能减少消息流中的节点数量。还要尝试减少消息树副本或创建新消息树。消息树占用了大量的空间，特别是在包含大量元素的情况下更是如此。仅在必要时使用计算节点（提供修改树的能力）之类的节点，以避免出现消息树副本。这不仅从内存利用率方面提高了效率，而且还提高了处理速度。 避免使用重置内容描述符 (Reset Content Descriptor) 节点。RCD 节点旨在用于更改实际解析完整消息树的消息域。此活动的内存和 CPU 使用量都较大。 可以使用 IF 语句、“CREATE with PARSE”语句和 ESQL ASBITSTREAM 的逻辑组合来消除 RCD 节点和多个计算/筛选器节点。 不要在生产环境中使用跟踪节点。使用 ${Root} 表达式的操作开销非常大，因为这会导致进行完整消息树解析。如果目的地不处于活动状态，就会发生这样的情况。 在可能的情况下，请尽量使用用户退出，并恰当地重定向审核/日志记录信息。使用退出功能能够获得灵活性，可在消息处理期间动态地激活和取消激活。 将中介结果保存在消息树中，以避免在后续节点中进行重新计算。如果消息在 Header 中包含用户可维护的数据文件夹（如 MQRFH2 usr 文件夹），则将中间结果存储在其中，以供后续节点使用。 当必须将消息写入到多个目的地时，建议使用目的地列表，而不要采用使用多个节点的方法。 使用 XMLT