性能和消息流服务可用性改善的实现和部署最佳实践.docxVIP

IBM? WebSphere? Message Broker（以下称为 Message Broker）可以作为企业服务总线使用，提供用于各种协议的通用连接以及为使用结构化和非结构化数据的应用程序提供数据转换功能。　　消息处理性能取决于很多因素，包括硬件能力、软件配置、消息流和消息格式设计及实现，以及消息流实例的数量。本文将描述为众多客户带来了性能和消息流服务可用性改善的实现和部署最佳实践。虽然本文并不讨论关联的WebSphere MQ和数据库实现的最佳实践，但会从消息代理应用程序的角度对其有所涉及。最佳实践并不是万能的，在某些情况下，此处所述的最佳实践需要进行修改，以满足体系结构灵活性和适应客户的具体需求和能力。　　最佳实践领域　　消息流　　消息流开发阶段的最佳实践，包括如何避免会导致性能问题的消息流实现。　　ESQL 　　消息流中的ESQL开发阶段的最佳实践，包括开发可重用代码和尽可能减少消息流中的优化ESQL代码（单从性能改善的角度而言）。　　发布/订阅　　针对使用发布/订阅模型路由消息的人员的最佳实践。不涉及总体最佳实践和克隆最佳实践。　　从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 节点时，请注意消息树将首先被序列化，然后再被发送到转换引擎。加载了样式表并执行转换之后，节点要将结果重新解析为消息树。另外，Message Broker V6中XMLT节点的输出始终为BLOB格式，因此如果消息处理必须在消息流中进一步作为 XML 消息处理，则必须使用 RCD 节点。因此，将通过多次使用XMLT节点解析整个消息树。如果要转换的消息树很大，此操作开销将非常大。同时，如果ESQL与更好的逻辑一起使用，则处理成本将大幅度减少，因为不需要解析完整的消息树，所得到的好处更多。　　如果要使用 XMLT 节点，则请尽可能使用样式表缓存。　　仅将消息流用于执行转换、翻译、协议转换、消息充实和路由等中介活动