本系列以使用 IBM 大型机服务器的客户为主要对象，探讨如何应用 WebSphere MQ 的特性来实现企业级应用的业务需求。本文是第 1 部分，将为大家介绍异步通信与同步通信的特点以及如何设计具有高可用性和负载均衡能力的 MQ 方案。
Websphere MQ 是 IBM 功能强大的消息传送中间件产品，它以其成熟的技术和世界领先的产品向我们提供了的功能丰富、可靠易用的异构平台间实现可靠信息传递的成熟解决方案。使用 MQ 消息传递产品可以帮助业务应用在不同种类平台上交换信息，以消息的方式接收、发送数据，从而实现企业应用集成。MQ 屏蔽了异构软硬件平台和网络协议的复杂性，确保“消息到达并且仅到达一次”的可靠的消息传递，满足高可靠性的、高性能的、安全可靠的稳定信息数据传输要求，并具有开放性、扩展性、先进性、安全性、可管理性和易于维护开发等特性。依靠这些优势，MQ 在消息类中间件市场上占有统治地位，已经成为事实上的行业标准，在企业的各类应用中承担了可靠的信息数据传输的基础支撑。MQ 是为能够支撑大型企业的海量信息传输而设计的，它设计了很多应用特性，为企业级应用提供支持，这些特性分散在系统设计和应用编程的各种细节之处。本系列以使用 IBM 大型机服务器的客户为主要对象，对异步通信与同步通信、MQ 高可用性及负载均衡方案、MQ 的安全性实现、MQ 与传统 CICS 应用的连接、使用 MQ 实现 SOA 服务、MQ 应用性能监控和企业级应用设计构架等几个方面探讨如何应用 MQ 的特性实现企业级应用的业务需求。本文是本系列的第 1 部分，将为大家介绍异步通信与同步通信的特点与设计考虑以及 MQ 高可用性及负载均衡方案。
MQ 在支持同步通讯的同时，提供了基于消息队列存储 - 转发机制的异步通讯模式，应用程序只需将消息交给 MQ，就由 MQ 负责将消息安全、可靠地发送出去，不再需要应用和人工的干预，真正实现了数据传输自动化，这一特点能够使应用程序独立于通信对方和网络的可用性。与我们常见的同步通信相比，异步通信模式有以下特点：
- 通信的达成只依赖于发送方和消息中间件，接收方以及网络的意外情况不造成影响。
- 因为不必实现同步握手，异步通信通常效率更高。
- 因为不必等待响应，异步通信倾向于实现更短的交易处理，节省系统资源占用。
- 异步通信有利于提高系统并发度，提高系统吞吐能力。
- 异步通信有利于实现松散耦合的系统结构。
与异步通信相比，同步通信想法更为简单而且更容易实现――发起方在系统中等待直到对方响应，这样可以避免复杂的发送 / 确认 / 重传机制的设计，但同时也造成了低效率和对资源占用大的缺点，同步通信目前是一种常见的廉价通信实现方式。
需要说明的是这里谈论的同步 / 异步是底层消息传输的模式，与其最终提供的服务模式无关：同步业务服务可以通过同步通信实现，也可以通过异步通信实现。比如我们常见的电话业务，一般我们都认为是一种同步的服务，但电信公司实际实施时，如果是通过交换机，在通话双方之间建立一个电路连接，那就是一种同步通信实现；如果电信公司采用的是 IP 电话，通过网络把声音打成若干数据包在 Internet 上发送，在收话方没有感觉到的时间内再按顺序组合把语音还原出来，那就是使用的异步底层通信实现。我们进行应用方案设计时要充分意识到两种通信模式的特点，考虑各种选择的可能性和优劣。
由于同步 / 异步通信有各自的特点，所以通过异步通信来实现同步应用时，有一些特殊的方法需要考虑。异步通信基础上实现同步应用，是通过若干异步消息分段实现的，以最简单的双方模式为例，A 发送给 B 一个异步消息，B 接收后完成特定处理，再返回给 B 一个异步消息，如果这个处理过程足够快，就能够实现一个请求 / 应答模式的同步应用。这种模式下，应用中 UOW 的范围，和同步应用下是有很大不同的，应用设计中要充分考虑到这种区别。
在同步模式下，在 A 和 B 的所有操作都可以放在一个 UOW 中，通过两阶段提交协议实现数据一致；在异步模式，应用会分成几个 UOW，第一个是应用程序在本地队列管理器中的操作，第二个是两个队列管理器间的数据传输，这个 UOW 是系统完成的，对于应用是透明的，第三个 UOW 是远程应用在远程队列管理器中的操作。应用设计时要充分意识到这些区别。
由于交易一致性控制，一个 MQ 应用中在队列中进行的改变，只在它 COMMIT 后，其他应用程序才能看到，所以在进行请求 / 应答模式的 MQ 应用程序中，请求程序发送请求消息后，要在适当的位置下 COMMIT，完成这个 UOW，然后在到应答队列里去等待对方完成 UOW 后的返回。应答程序也要与请求程序类似，也要合理地控制 UOW 的范围，使得返回消息能够恰当地被请求程序得到。
在使用 MQ 进行要求同步通讯的程序设计时，会碰到原来可能会做单一 UOW 的应用，在 MQ 下的异步应用设计下要划分成若干个 UOW，这就涉及到如何在多 UOW 下保证数据整体的一致性。这种需求，一般可以通过合理的冲正设计来实现。
MQ 产品分为 Server 和 Client 两种版本，在 MQ Server 的运行环境下，有队列管理器、队列、消息通道等对象，它提供全面的消息服务；MQ Client 本身没有队列管理器、队列等对象，它通过 MQI 通道与服务器之间建立通讯，并将消息从客户端发往服务器端的队列，或从 Server 端的队列中取得消息，其他功能也比 Server 有限。MQ Client 与 Server 之间的通信是同步模式完成的，它必须在 Server 正在工作并且可以通过网络访问的情况下才能完成任务。MQ Client 通常在有大量末端环境的应用系统中采用，可以通过这种方式来节省成本，但要求在 Client 到 Server 之间要有比较可靠的网络连接。
大型企业应用方案，在功能性要求之外系统高可靠性能力与负载均衡能力是一个十分重要的衡量指标。MQ 在这方案提供了很强的特性，主要通过两种主要技术实现：MQ Cluster 技术和 Queue Sharing Group 技术。Cluster 技术可以在各种系统平台上甚至跨平台实施，能够提供基本的高可用性能力，Queue Sharing Group 只能在 IBM System z 主机平台上实现，能够提供最高级的高可用性能力。
使用 Queue Manager Cluster 技术，可以把安装在不同平台（如 AIX，LINUX，WINDOW，z/OS）上的若干个 Queue Manager 设计为一个集群，每个 Queue Manager 都创建成集群中的一员。集群中有一个或多个 Queue Manager 可以定义成拥有整个集群的对象定义信息，称作 Repository queue manager。当用户在集群中创建一个接收通道或队列时，系统会自动在其他队列管理器中创建相应的发送通道和远程队列定义。不论整个集群中有多少 Queue Manager，每个 Queue Manager 只要建立一个接收通道，和一个指向 Repository queue manager 的发送通道就可以完成消息连通，而不必要针对每个 queue manager 分别定义通道；同时每个 Queue Manager 也不必要定义远程所有用到的远程 Queue.
图１ MQ Cluster 集群
通过 Cluster 技术，可以有效地减少系统的管理工作，更快地建立应用同时可以提高系统的可用性并可以在集群 MQ 管理器间实现负载均衡。
减少系统的管理工作主要体现在 :
- 不论连接多少远程队列管理器，只要建一个集群发送通道和一个集群接收通道，不必为每个管理器分别建立通道
- 每个队列管理器只要建立一个 transmission queues。
- 不必一一定义远程队列，可直接使用
使用 Cluster 技术提高系统的可用性和实现负载均衡，是通过在 Cluster 内的不同 QMGR 上建立同名的 Queue（同一个 Queue 的多个实例）来实现的。每个 Queue 的实例都能作为消息的目的地，MQ 能够在依照一定的算法决定实际消息应当传给哪个 QMGR。这样当集群里某个 QMGR 失效时，消息会自动路由到其他活动的 QMGR 管理的实例上去。
在实际应用 Cluster 技术时，一般采取如下的部署方案：
图２ MQ Cluster 的典型部署模式
在 Cluster 中首先设计一台 MQ 服务器作为整个 Cluster 的网关，作为对外的连接点，它本地并不定义任何输入（Inbound）队列（如上例中的 Q1），只定义输出（Outbound）队列（如上例中的 Q2）。另外设置若干消息处理服务器，其中定义本地的输入队列，同时有消息处理程序在运行。在外部交易进入 Cluster 时首先发送到网关机上，由网关动态地发送到 Cluster 里定义了输入队列的 MQ 服务器上去。MQ 网关可以根据设置，按照轮循或权重的方式对进入的消息进行分发，还可以通过出口程序（User Exit）实现更加复杂的分发机制。
在每个消息处理服务器都部署有完全相同的应用处理程序，它们读取输入队列里的消息，经过处理后把结果写入输出队列。输出队列只定义在 MQ 网关机器上，任何消息处理服务器写出的消息都回最终传送到网关上。前台程序连接网关，读取返回结果。
为了获得更高可用性，这个方案中有两点需要注意：1. 可以看到 MQ 网关是个单点隐患，为了更高可用性，要使用 HACMP 等方案实现备份。2. 如果消息处理服务器上的应用程序意外停止运行，数据会在队列中堆积起来，为了避免这种情况，需要自动脚本在应用程序停止时自动把 MQ 停止，这样后来的消息会发给其他服务器处理。
一些企业中，经常使用 F5 之只类的网络层负载均衡器来实现一种高可靠性 / 负载均衡解决方案。很多应用可以依靠 F5 实现的动态 IP 地址功能，在不改变应用程序的情况下实现高可用性，这为无状态的网络应用提供了方便的均衡手段。但是 MQ 产品为实现消息到并且只到一次，在收发双方的发送通道和接收通道上要传递记数和确认信息，这样以来发送和接收方必须有固定的一对一关系，如果在中间网络上配置了网络层的负载均衡器，由于它不知道这种机制的存在，必然造成通信的错乱，所以在使用 MQ 的网络环境中不能够同时使用网络层的负载均衡设备。
主机 MQ 特有高可用性技术 -Queue Sharing Group 设计
Shared Queue Group 是 MQ 依托 System z 主机的 Parallel Sysplex 技术而实现的高级特性。Shared queue 是一种本地队列，shared queue 里存储的数据可以被同一个 Sysplex 里的若干个 QMGR 共同访问。能够访问同一个 shared queue 的所有 QMGR 称为一个 queue-sharing group，它们可以访问同一组 shared queues。 Shared queue 的数据存储在 Coupling Facility 的 list structures 里面，一个 Group 里的所有队列管理器都能够从这个队列里读取数据和发送数据。
图３MQ Queue Share Group
Shared queue 的定义被所有 QMGR 共享，共享的队列定义是存放在 DB2 的表里，在一个群里，队列只要定义一次，就能被所有的 QMGR 共享。Queue-sharing group 里的每个 QMGR 都有与一个 DB2 系统相连，这些 DB2 系统必须在一个 data-sharing group 里，这样 QMGR 才能够访问相同的共享队列定义。
在主机上使用 Queue Share Group 技术，结合 Sysplex 提供的系统功能（如 SYSPLEX Distributor 和 VTAM generic resources），MQ 除了可以实现应用处理上的高可用性，还能够提供网络接入和送出的高可用性，这是通过 MQ 的 Shared channel 来实现的。
图４ MQ 共享通道
共享的接入通道 ： Queue-sharing group 里的每个 MQ Server 的 channel initiator 都在同一个 IP 端口监听消息，这个端口通过 Sysplex 提供的网络技术对外做成一个 generic port。这样分布式系统 MQ Channel 的连接请求会被分发到任意一个 MQ Server 上，只要 Group 里还有一个 Server 能够响应，就能够完成消息向 Shared Queue 里的发送。
共享的外传通道 ：如果一个发送通道的 transmission queue 定义为共享的 Shared Queue，那么这个通道就是共享的外传通道。Group 里的任意一个 QueueManger 都可以从共享的 transmission queue 里取得数据向外传输，这样只要还有一个 QM 有响应，这个通道对外就是畅通的。
Shared queue 技术使 MQ 在应用上具有以下优点：
- Scalability
应用处理能力能够很方便地进行扩展，只要新增一个 QMGR，甚至新增一个 z/OS image 并在上面建立 QMGR 和应用程序，就能很好地扩大系统处理能力。
- Availability
多个 QMGR 可以访问同一个 Queue，单个 QMGR 的故障不影响 Shared queue 的应用。MQ 通过 peer recovery 技术，可以监控 QMGR 的非正常中断，能够自动回滚未完成的 ULW。
- Workload balance
利用 SYSPLEX 的负载均衡功能，可以在多个 QMGR 间平衡处理量。
Cluster 技术和 Share Queue 技术为实现可靠性、扩展性和均衡，使用的基本手段是不同的：
- Queue Manager Cluster
Queue Manager Cluster 使用的是同名队列的多个实例，就是在 Cluster 里的多个 QMGR 上建立相同的 Queue。进入这个队列的数据会转发给某个 QMGR，一旦数据进入这个 QMGR，就只能由这个 QMGR 访问。
- Queue-Sharing Group
Queue-Sharing Group 使用的是一个共享的队列，队列的数据存储只有一份，可以由多个 QMGR 共同访问。
抛开 zSeries 对其他开放平台的系统优势不谈，由于这个基本手段本质的不同，使得两种技术提供的服务水平有很大不同：
- Cluster 只在消息进入时实现高可用性，一旦消息进入某个 QMGR，它就只能由那个 QMGR 处理，如果在消息被处理完之前，系统发生故障，已经进入这个 QMGR 的数据将不能被处理。而使用 Shared queue 时，一个 QMGR 失败不会影响队列里的数据。
- Queue Manager Cluster 时一旦数据进入某个 QMGR，就只能被这个 QMGR 访问，如果某个系统上的 QMGR 正常，但处理 MQ 消息的应用程序发生故障停止运行，消息还会继续发送到这个 QMGR 里去，但这些消息就会积压在这里不会得到处理。在 Shared queue 时，由于 QMGR 使用的是同一个队列，如果某个 QMGR 后面的应用程序停止工作，消息会被其他 QMGR 后面的应用程序处理，不会对整个应用造成任何影响。
- Share Queue 是在 Work Load Manager 协调下完成负载均衡的，其负载均衡能力比 Cluster 内带的逻辑要更加强大。Cluster 只能根据消息进入集群时的负载情形转发消息，而 Share Queue 能在消息处理过程中动态地平衡负载。
- 考虑消息进入时的情况，对于 Cluster，发送方必须指定发送到 Cluster 里做 Gateway 的机器的 IP 地址上，一旦这台机器失效，虽然这个 Queue 的其他 QMGR 还在，消息却不能进入 Cluster，存在单点故障隐患；对于 Share Queue，通过 SYSPLEX Distributor 等技术，发送到特定 IP 地址的数据，可以被路由到任何一台机器，单个机器失效，不会造成影响。
本文是本系列的第 1 部分，为大家介绍了异步通信与同步通信的特点与设计考虑以及 MQ 高可用性及负载均衡方案，下面几节将继续为大家介绍 MQ 的安全性实现 ,MQ 与传统 CICS 应用的连接 , 使用 MQ 实现 SOA 服务 ,MQ 应用监控以及企业级应用设计构架技术方案。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-406844/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-406844/
扫一扫
1023
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
