韩宇峰 张嘉岭
(1.上海华腾软件系统有限公司,200233,上海;2.上海地铁运营有限公司,200003,上海∥第一作者,工程师)
实时信息交换在银行、社保、电信、票务、零售等行业有着广泛的应用。尽管不同行业在业务处理上存在着不同,但其中都有一些共同的属性和特点,即特定的参与方和传播模式。
交换系统的参与方又称为交换节点。一个特定的参与方即一个信息交换处理节点。数据交换在相关节点间传送。例如,清分系统即一个节点,它是整个轨道交通票务系统的中央机构,负责轨道交通车票的发行与管理、交易数据的收集、车票和票务清分、资金清算,黑名单管理等。清分节点在某些联机交换中作为交易的最初发起方,如运营参数、命令、车站运行模式切换/切换通知、交易数据索取、交通卡黑名单和清分结果等;清分节点在某些联机交换中作为交易的最终目的方,如交易数据上传和寄存器数据上传等。
每种联机交换都采用以下两种模式之一进行传播:
(1)联机交互(又称大圈)交易。采用这种传播模式交换信息时,本节点不能决定交易成功与否,只能由交易最终的目的方给出,介于发起方和目的方之间的其它节点只是传递交易请求和交易应答。对于这种交易,一笔交易可能分成多个阶段进行。分成阶段的数量是由交易类型的业务含义决定的,称之为交易或交易类型的阶段数。联机交互的传播模式如图1所示。
图1 联机交互的传播模式
图1中的节点是根据它们在交易中所起的作用而命名。发起方与目的方之间的节点都可称为转发方,一笔交易的转发方可能有多个。(上游)来源节点和下游交换节点是相对于本交易处理节点而言的。其中实线箭头为请求消息,虚线箭头为应答消息。
(2)分程传递(又称小圈)交易。采用这种传播模式交换信息时,信息交换节点在收到交易请求时总是立即返回成功应答,然后向下游交换节点转发。返回的应答消息仅表明其收到请求消息,没有业务上的交易是否成功的含义。该交易的处理主要在第一阶段中进行,收到应答时仅更新交易状态。为了和联机交互的交易处理过程相统一,规定分程传递交易的阶段数为1。分程传递的传播模式如图2所示。
图2 分程传递的传播模式
实时信息交换系统采用多层结构,这是目前绝大多数信息系统采用的基于分布式计算模式的体系结构。它是将不同层次的功能分散在不同软件层次上的软件系统结构。从数据交易的角度来剖析,整个系统可以被划分成交易传输、信息交互和交易处理等3个部分,分别对应通信层、联机交换层、业务层,如图3所示。
图3 实时信息交换系统逻辑架构图
通信层对TCP/IP协议进行实现,在物理上是独立的进程。它处理通信协议、通信方式,使其上层的应用与通信协议、方式无关。通信层由通信服务模块和通信客户模块组成。每个通信模块所用的方式、参数都可以配置,可以灵活地接入采用各类同步/异步、长/短连接的通信方式的外部节点,同时采用消息队列机制为联机交换层的运作提供一个统一的系统内部接口。
联机交换层实现交易传递、转接,同时针对通信故障采用超时控制和存储转发。它主要由报文处理模块、超时控制模块和存储转发模块组成。其中的报文处理模块处理来自通信层的交易请求和交易应答,同时调用业务层的相关业务逻辑模块,实现对数据库的操作,进行针对交易的业务内容的处理。这些模块的工作都是基于配置信息的。交换层不关心交易的业务含义,所有的业务逻辑均在业务层的业务逻辑模块中实现。
业务层并不是一个物理上实际存在的实体子系统,它的引入仅仅是为了方便开发时的分工,它是一组业务逻辑模块的集合。这些业务逻辑模块被联机交换层的模块调用。业务逻辑是一些标准接口的函数的集合,由这些函数来实现各种交易相应业务内容上的处理逻辑。
(1)请求消息。通信服务模块把从上游节点传来的交易请求消息发送至请求接收队列。报文处理模块从请求接收队列读取请求消息。若该请求可直接应答,则生成应答消息,发送到应答发送队列,否则将请求消息转发到应答发送队列;若交易类型表明需要进行超时控制,则将交易记录发送到超时控制队列;若交易类型表明需要进行存储转发,则将交易记录发送到存储转发队列。通信客户模块从请求发送队列读取请求消息,发送给相应节点。
(2)应答消息。通信客户模块从请求发送队列读取交易请求,发送到相应节点;接收交易应答,发送到应答接收队列。报文处理模块从应答接收队列读取应答消息。若该应答对应的交易还需要向其它交换节点发送交易请求,则组成新的交易请求,发送到请求发送队列;若交易类型表明需要进行超时控制,则将交易记录发送到超时控制队列;若交易类型表明需要进行存储转发,则将交易记录发送到存储转发队列。若该应答对应的交易最初不是由本节点发起的,则将应答消息转发到应答发送队列;若交易类型表明对本交易进行了超时控制,则将交易记录从超时控制队列中删除;若交易类型表明对本交易进行了存储转发,则将交易记录从存储转发队列中删除。通信服务器从应答发送队列读取应答消息,发送给相应节点。
(3)超时控制。每隔一定时间(超时控制时间精度),超时控制模块从超时控制队列读取已经超时了的交易记录,生成超时应答消息,发送到应答发送队列;若交易类型表明需要进行超时冲正,则生成冲正请求,发送到存储转发队列。通信服务器从应答发送队列读取应答消息,发送给相应节点。
(4)存储转发。每隔一定时间(存储转发时间精度),存储转发进程从存储转发队列读取已经到下一次转发时刻的交易记录,生成该交易的转发请求消息,发送到请求发送队列;若本交易尚未达到其交易类型所规定的最大存储转发次数,则重新设定下一次转发时刻,写回存储转发队列。通信服务端从应答发送队列读取应答消息,发送给其连接的远端主机。
(1)高可靠性。系统的流量控制主要是对消息队列进行控制。当流量大于系统设置的最大值时,新的请求不再放入正常的处理队列,而是放入一个特殊处理队列,对该特殊队列的内容系统将直接给予失败应答。这样,在请求量大于系统最大处理能力时,系统能正常处理设置范围内的交易,而超出部分给予拒绝,以保证系统仍然可用。
(2)可扩展性。系统在运行一段时间交易量逐渐增大时,可简单地增加CPU、内存、硬盘或者主机设备等硬件实现扩容,增加处理能力,而无需更改应用。另外还可以重新设置一些接入节点的通信配置,使其连接到新增的通信服务器上,达到扩容目的。
(3)可管理性。对通信服务模块、通信客户模块,采用文件配置的方式配置成多进程方式、异步、同步、长连接、短连接;对数据报文可以配置同步头等信息;对报文处理模块采用数据库表的配置方式配置交易类型、交易阶段数、传播类型等。
(4)安全性。通过对操作员的授权来进行应用安全控制,通过对接入系统IP地址的检查来进行网络安全控制。检查接入的IP地址是否在配置表中存在,对接收的报文进行MAC验证,对发送的报文生成MAC(Media Access Control,介质访问控制)以让对方节点进行验证,从而控制传输安全。
在设计系统时,首先定义贯穿整个系统的全局结构体。每笔交易进入系统后,此交易的数据信息和对此交易进行业务处理,以及存储转发所需的控制信息,均存放于此结构体的变量 txnInfoDef中(见表 1)。
(1)通信服务模块:接受外界的连接请求,建立通信连接,接收数据请求报文,发送数据请求包给报文处理模块;接收数据应答包,发送数据应答报文。对于同步短连接,通信服务模块只用1个子进程进行请求报文的接收和应答报文的发送。通信服务模块启动时,根据环境变量APP_CFG_FILE得到配置文件的全路径名,根据命令行参数得到配置文件中的配置项的节名,并读取该节中的配置项,得到具体的工作配置。通信服务模块以任何方式工作时,都不主动断开连接,仅当发现对方断开连接时,才关闭连接。
(2)通信客户模块:从报文处理模块接收数据请求包,向外部系统发送数据请求报文;从外部系统接收数据应答报文,发送数据应答包。对于同步连接,通信客户模块只用1个子进程进行请求报文的接收和应答报文的发送。
(3)报文处理模块:处理来自外部系统的数据请求包,把数据请求包或数据明细存放到数据库,同时调用相关的业务逻辑处理函数对相应的交易进行处理,并发送至相应的消息队列。
表1 数据结构定义
(4)存储转发模块:对于分程传递交易,交易接收方不能及时返回应答时,存储转发模块会重复发送交易请求。存储转发模块读取指令,根据指令要求从数据库取出数据请求包,把数据请求包发送到通信客户端。
(5)超时控制模块:交易接收方不能及时返回应答时,超时控制模块会生成超时应答包,发送到对应接收方的消息队列中。超时控制模块从消息队列读取控制消息,如果是超时控制请求,则对该请求消息进行超时控制;如果是撤消超时控制请求,则撤消对请求消息的超时控制。对发生超时的请求消息,生成超时应答包,发送到对应接收方的消息队列中。
(6)安全模块:确保消息报文内容在传输过程中没有被篡改。
业务逻辑是一些标准接口函数的集合,将交易的业务处理内容封装在这些函数中,实现各种交易的相应的业务内容上的处理。
(1)判断交易类型(getTxnType):报文处理模块收到请求消息时被调用,它用于在交易请求消息报文的相应位置上取得交易类型。该函数以指向txnInfoDef结构变量的指针为参数。得到的交易类型代码(或关键字)放在 txnInfoDef结构变量的txnType字段中返回。
(2)请求处理时的业务逻辑(bizLogicReq):报文处理模块处理交易请求时被调用,根据交易类型,对交易及相关的业务信息进行处理,包括向相关业务信息表插入、更新、删除记录,触发一些业务内容处理进程的运行等。该函数以指向txnInfoDef结构变量的指针为参数。若交易仅有一个阶段(分程传递的交易),并且处理中未发生任何失败,txnInfoDef结构变量的resultReason和result字段会被分别置成 RC_SUCCESS(成功)和‘S'。
(3)应答处理时的业务逻辑(bizLogicReply):报文处理模块处理交易应答时被调用,它根据交易类型,对交易及相关的业务信息进行处理。
(4)判断路由(getRoute):报文处理模块处理交易请求或交易应答时被调用,根据该交易类型配置和交易具体信息得到下一步的路由。该函数以指向txnInfoDef结构变量的指针为参数。得到的路由节点标识放在txnInfoDef结构变量的routeNode数组元素中返回,同时 txnInfoDef结构变量的routeNodeNum字段被设置成路由节点的数量。
(5)生成应答(genReply):报文处理模块处理交易请求、超时控制模块处理超时交易时被调用,它用于生成交易的失败(如目的方不可到达、下游节点应答超时等)应答消息报文。该函数以指向txnInfoDef结构变量的指针为参数。生成的应答消息报文存放在数据库的交易消息表中,同时还存放在txnInfoDef结构变量的 outMsg中返回,outMsgLen字段被置成应答消息报文长度(字节数),outPkgNo字段被置成 0(包号为 0),outPkgNum字段被置成1(仅有1包)。
(6)生成转发请求(genFw rdReq):报文处理模块处理交易请求或交易应答时被调用,生成交易的下一步需要转发出去的请求消息报文。该函数以指向txnInfoDef结构变量的指针为参数。生成的交易请求消息报文存放在数据库的交易消息表中。同时,最后一包存放在 txnInfoDef结构变量的outMsg中,outMsgLen字段被置成最后一包的报文长度(字节数),outPkgNo字段被置成最后一包的包号,outPkgNum字段被置成消息包数。
(7)生成转发应答(genFwrdReply):报文处理模块处理交易应答时被调用,生成交易的下一步需要转发出去的应答消息报文。该函数以指向txnInfoDef结构变量的指针为参数。生成的交易应答消息报文存放在数据库的交易消息表中。同时,最后一包存放在 txnInfoDef结构变量的 outMsg中,outMsgLen字段被置成最后一包的报文长度(字节数),outPkgNo字段被置成最后一包的包号,outPkgNum字段被置成消息包数。
(8)生成目的方应答(genHomeReply):对于联机交互传播模式的交易类型的交易,报文处理模块处理交易请求时,若发现本节点就是该交易的目的方,则通过调用本函数来生成本节点作为交易目的方给出的应答消息报文,查询账户信息,组成所需的应答消息报文。该函数以指向txnInfoDef结构变量的指针为参数,生成的交易请求消息报文存放在数据库的交易消息表中。同时,最后一包存放在txnInfoDef结构变量的outMsg中,outMsgLen字段被置成最后一包的报文长度(字节数),outPkgNo字段被置成最后一包的包号,outPkgNum字段被置成消息包数。
数据库根据大数据量的特定,采用按天建表、按批次分区的建表原则。数据库主要有如下表组成:
(1)交易日志表(TBL_FEP_TXN_LOG),用于存放本交换节点处理的交易记录,每笔交易对应一条数据表记录。
(2)交易消息表(TBL_FEP_TXN_MSG),用于存放本交换节点接收到的和发送出去的消息报文。每笔交易对应若干个交易消息,而每个交易消息又由若干个包构成,每个消息包对应本表的一条记录。
(3)交易类型表(TBL_FEP_TXN_T YPE_INFO),用于定义交易类型的阶段数。本表的每一条记录对应一种交易类型。
(4)交易类型阶段表(TBL_FEP_TXN_T YPE_PHASE),用于定义交易类型的各阶段的行为。本表的每一条记录对应某一种交易类型的一个阶段。
(5)分程传递交易类型表(TBL_FEP_TXN_T YPE_RELAY),用于定义交易类型在进行分程传递时的行为。本表的一条记录对应某一种交易类型的分程传递部分。
(6)节点信息表(TBL_FEP_NODE_INFO),用于存放各节点信息,如线路、车站等。
(7)一票通交易数据表(TBL_FEP_TICK_YYYYMMDD),存放由线路中央上传的一票通待清分交易数据,按包存放。该类数据的数据量大,处理速度要求较低,与其它消息分开存放。同时考虑到数据访问的效率,该表按清分日期每天建表。
(8)公共交通卡交易数据表(TBL_FEP_CARD_YYYYMMDD),存放由线路中央上传的公共交通卡交易数据,按包存放。该类数据的数据量大,处理速度要求较低,与其它消息分开存放。同时考虑到数据访问的效率,该表按清分日期每天建表。
轨道交通清分中心计算机系统(简称清分系统)完成全路网的车票发行与调配管理、换乘交易清分与帐务结算、路网运营模式监控、各类交易信息和客流信息的统计分析等功能。前置信息交换子系统作为清分系统的重要组成部分,对外提供通信接入服务。前置信息交换子系统是一种典型的实时信息交换系统,负责向线路中央系统、公共交通一卡通中心、结算银行等提供网络联接、记录日志,支持售票交易、进出站交易等的接入以及交通卡相关交易的转接和相关文件的发送。任何直接与清分系统主机有信息往来的外部机构节点都通过该子系统接入清分系统。并且该子系统接收外界发来的交互请求,经过其内部的处理,返回交互的应答。其内部的处理因交互请求的类型不同而各异。例如,对于线路中央上传的交易数据,处理内容是插入数据库;而对于线路中央发来的车站运行模式切换通知,处理内容是记录到数据库后再向其他各个线路中央主机转发。前置信息交换子系统与其它子系统协同工作,共同完成各种业务和交易的处理,构成轨道交通清分系统的有机整体。
实时信息交换技术已成功运用于上海轨道交通清分系统前置信息交换子系统中。系统每天处理500余万笔交易,系统运行稳定。
[1]Richard Stevens W,杨继张.UNIX网络编程(第2卷):进程间通信[M].2版.北京:清华大学出版社,2000.
[2]叶宁.Unix环境下利用Socket和消息队列构建应用通信平台[J].华南金融电脑,2002(11):85.
[3]简广林,王颖.利用消息队列实现三层结构的通信平台[J].现代电力,2003(2):72.
[4]上海轨道交通票务中心.城市轨道交通自动售检票系统专用技术说明[G].上海,2006.