关于中间件,有一个很有名的定义是:平台+通信。这一点在TUXEDO上面得到了很好的体现,因为它提供了运行和开发的平台,以及多种的通信方式。在这多种通信方式中,使用最频繁的是WS(workstation)方式。WS方式使用的是TCP连接,为了对WS方式有更多的了解,我们结合TCP连接的知识对这种方式进行了一个比较深入的分析。
名词说明:
WSC: WorkStation Client WSL: WorkStation Listener
WSH: WorkStation Handler Server: 小写表示服务器端的服务处理进程
TCP连接是一种C/S模式的,即server端公开自己的IP和端口号,client通过这两个参数与之建立连接,客户端使用的端口一般是OS临时分配的。
TCP server端一般有两种模式,一种是iterative(重复)的,一种concurrent(并发)的。前面一种是一个server的进程(应用层)来处理client的请求,处理完了之后继续接受请求来处理,当server正在处理的过程中,新来的请求得不到处理,只有等待。后面一种是请求到来的时候,server 进程通常会新开一个进程来处理这个请求,自己继续监听公开端口的连接请求。
在TUXEO这种事务处理系统中,会经常有大量的请求,故第一种模式肯定是不行的,第二种模式虽然可以达到同时处理不同请求的目的,但是由于每次要开新的进程,系统的开销很大,也会影响性能。实际中,TUXEDO的Workstation方式采用了另一种方法来实现多请求的并发处理。下面我们进行详细的说明。
以下是ubb中关于WSL的配置参数:
WSL SRVGRP=Group1 SRVID=200
CLOPT="-A -t -- -n //ip(服务器IP,在此隐去):4050 -m 2 -M 10 -x 10"
其中ip:4050就是TUXEDO服务器的WSL的监听地址,只有一个WSL进程。-m参数指定的是启动时WSH的个数,-M为最大个数(用户数大于m*x时系统会自动启动更多的WSH),-x为每个WSH可以多道处理请求的最大数目,可以理解为WSH的请求缓冲区可以存放十个请求。这样我们上面的配置在启动后可以处理同时20个并发请求,最大可以处理100个。
根据这个配置和相关参数的解释,我们就可以知道TUXEDO采用的处理模式了,TUXEDO在上面TCP的第二种方式之上进行了改进。监听进程还是只有一个(WSL),但是事先已经起了多个处理请求的进程(WSH),每个WSH又可以处理多个请求,这样就保证了大量的请求能同时得到处理,也省去了临时开服务进程的开销。
这里还需要理解是WSH和server进程之间的关系。因为大家知道,真正处理client请求的是server进程,所有的业务处理,以及和数据库相关的操作都是在server进程中完成的,这也是我们TUXEDO应用开发主要做的部分。我的理解是WSH可以看成是WSC在本地的一个代理。WSH收到WSC的请求数据,放在缓冲区,然后发给server进程来处理,因为在同一台机器上,一般采用本地进程间通信的机制,效率比较高。Server处理完后将结果返回给WSH,WSH再将结果返回给WSC,这个过程中WSH和WSC是保持着TCP连接的,而server进程并不直接和WSC打交道。
WSC连接的工作示意图:
需要解释的是WSH和server之间的粗线箭头。因为WSH和server直接是多对多的关系,每个WSH可以把请求发给多个server,每个server也可以接受多个WSH发来的请求。