[zz]比较几种常用的中间件产品的通信机制(基于TCP/IP)

各种中间件和应用服务器产品一般都包括一个通信子系统，这个通信子系统的目的就是接受客户机和其它服务器实例的访 问。由于应用范围和产品历史不同，这些通信子系统也就千差万别。关于几种常用的中间件产品，比如IBM MQSeries，CICS/TXSeries和BEA Tuxedo的通信机制，是经常被软件工程师们讨论的话题，因为许多产品特性都是与此息息相关的。我这里仅仅粗浅地介绍一下最表层的一些架构，希望能够抛 砖引玉。
首先，我想对比一下数据传输类中间件MQSeries与TPM类交易中间件CICS/TXSeries和BEA Tuxedo。MQSeries与CICS/TXSeries或BEA
Tuxedo 有很大的不同，因为MQSeries被设计为一个以异步数据通信为基础的中间件。MQSeries这类中间件的特点是“存储/转发”(对持久消息，直接保 存到硬盘；对非持久消息，开始时先保存到共享内存)，而TPM中间件(包括TXSeries和Tuxedo)没有这个“存储”的功能，而侧重分布式的实时 交易处理。数据传输类中间件MQSeries适于以下的应用场合：
  数据跨异种系统的可靠传输。
  高速地传送数据或请求，接收方一般不会因为工作量大而导致溢出或丢弃。
  这是因为数据传输中间件系统的接收器快速存储收到的数据而不急于进行处理和响应。
  消耗时间长的交易，或消耗时间长短不定的交易，或者是批处理作业。
  服务程序(MQ守护程序)可以高效率的执行批量交易和长时间交易，而完全不用考虑通信等待的问题，通信由相关的队列、通道和收听器来维护。
  工作量按时间分布不均匀的服务器系统。
  服务程序可以充分利用系统空闲的时间(比如夜间)工作。
  分布式的复杂系统
  分布式的复杂系统存在各种各样的意外事件和复杂情况，如果全部采用同步系统，一个工作点的失败可以导致整个系统的瘫痪。异步和“存储/转发”是解决相互等待的最佳途径。

相对数据传输中间件MQSeries，TPM类交易中间件(CICS/TXSeries和BEA Tuxedo)有以下的优势：
  针对高速且有返回信息的交易，有极快的响应速度。
  强大的分布式事务处理的能力。
  MQSeries也支持两阶段提交，但异步的性质决定了它不能支持分布式应用的统一交易处理。
  完全屏蔽了通信层的工作，使开发更加简便，专注于业务系统。
MQSeries 的通信机制的核心是通道和收听器。通道设置决定了通信的协议、参数和相关方法。MQSeries的收听器有两种机制：基于inetd的守护进程机制 (amqcrsta)，和基于线程响应的机制(runmqlsr)。这两种机制各有优缺点。runmqlsr的性能更出色，但老版本的MQSeries在 接收过多的连接时有一些问题。amqcrsta能支持更多的通道和客户访问，但可能造成系统资源更多的损耗。MQSeries
v5.3以后，runmqlsr已经得增强，我个人认为这种方式更好。当然，无论如何，要接受更多客户机或通道的访问，必须调整qm.ini或Windows注册表的一些参数(MaxChannels,
MaxActiveChannels, ListenerBacklog)，以及一些相关的操作系统的内核参数。
以客户机访问方式为例，MQSeries的每个客户机都与收听器(amqcrsta或runmqlsr)建立Socket连接，而MQSeries收听器通过IPC机制通知Queue
Manager Agent
(amqzlaa0)读写消息和队列。客户机访问方式采用的是短连接，而通道连接方式采用的是长连接。关于短连接和长连接的比较，后面还要加以讨论。
CICS/TXSeries 的通信处理与MQSeries的通道连接方式类似，使用长连接的方式。CICS/TXSeries的TCP/IP收听器进程叫做cicsip，在v5.1 以后，其功能大大增强。CICS/TXSeries使用一个LD:TCPProcessCount参数，其内部是用了Socket的 SO_REUSEADDR选项，支持多个收听器进程是用相同的IP和端口。这个特性大大简化了多并发情况的客户机设置，可以采用相同的服务器收听器设置。 当然这种特性会增加服务器收听器的设计难度。cicsip进程将请求写入请求队列，实际上是写入Region
Pool中的共享内存。而每个应用服务器进程(cicsas)通过IPC机制读取请求，经过计算，返回信息到共享内存中的应答队列，再通过收听器返回客户机。
可 以看出，CICS/TXSeries在内部使用了一个异步处理的方式，其目的是充分利用系统资源，达到最高的吞吐效率。但对外仍然是一个同步通信的系统。 但是与MQSeries不同，CICS/TXSeries没有任何存储数据或请求的操作，队列的容量和数据的生存期也远远小于MQSeries。在这些方 面，CICS/TXSeries与Tuxedo没有什么不同。
但Tuxedo的通信机制还是有很多不同于CICS/TXSeries的方面：
  CICS/TXSeries的通信设置很简单，只须设置一个收听器IP和端口就可以了。Tuxedo的通信设置可就多了，本地语言(C, COBOL等)客户访问(WSL)，Java
  Jolt访问(JSL)，域连接(T/DOMAIN)，集群等等都需要独立的网络设置，使用独立的收听器。而且还有很多看不见的端口被作为客户连接使用(WSH)，网络管理员在配置防火墙时要颇费一番脑筋。
  Tuxedo使用短连接的方式，与MQSeries的客户机访问方式相似，但通信方式要复杂一些。以本地语言客户访问的收听器WSL为例：WSL在接收到 客户请求后，立即释放连接，而客户机接着使用新建的连接与一个WSH进程继续通信。这种方式可以降低WSL的工作量。
  Tuxedo的客户机程序直接与收听器建立Socket连接。CICS/TXSeries的客户机程序通过IPC与一个客户机守护程序(cclclnt)通信，该守护程序(cclclnt)与CICS/TXSeries的服务器建立一个Socket连接。
目前MQSeries和Tuxedo的收听器还不支持复用IP地址和端口，所以如果有太多的客户访问或通道连接，需要增加新的收听器端口。
从 上面的讨论可以看出：MQSeries的通道连接方式以及CICS/TXSeries采用长连接的通信方式，MQSeries的客户机访问方式以及 Tuxedo采用短连接的通信方式。所谓长连接，就是一旦建立连接，一般的应用API不会中断该连接；所谓短连接，就是在一个完整的应用中先建立连接，最 后结束该连接，而且程序退出时必然切断连接。这两种通信方式对应用系统有着深刻的影响。
短连接灵活方便，避免了下述很多长连接面临的棘手的问题：
  客户机异常中断，网络中断，包括Windows 9x之类的操作系统正常关闭，都不会通知服务器，造成服务器保持闲置无用的连接，长连接通常要等待“tcp_keepidle”之类的时间，这个时间默认 时一般是两个小时。这样会明显加重服务器的负载，无故占用相应的资源。MQSeries采用DISCINT和HBINT等通道参数来避免这个问题。
  如果仅仅是少量访问，建立长连接浪费过多的资源。MQSeries也是通过DISCINT和HBINT等通道参数来避免这个问题。
  网络相关的故障仅仅影响本次连接。短连接可以隔离故障的影响。
当然，长连接也有自己的好处：
  长连接通信方式的好处是效率高，因为应用程序无须等待建立连接。
  诸如SNA之类的通信协议只能使用长连接方式。
  短连接是由应用建立的(例如MQSeries客户机的MQCONN调用，Tuxedo的tpinit调用)。短连接的关闭也许要等待2倍MSL (Maximum
  Segment
  Lifetime)的时间，大约1-4分钟。如果频繁地建立短连接，会在服务器造成大量暂时不能访问的等待关闭的socket连接(状态是TIME_WAIT)，乃至造成客户机无法获得新的连接。

以上我粗浅地讨论了几种中间件的通信机制的原理，如果是初学者，在实际应用中会有更深的体会。