CN1306776C - 基于多层架构的数据处理系统及数据处理方法 - Google Patents

Abstract

一种基于多层架构的数据处理系统及数据处理方法，其中所述数据处理系统包括若干后台服务子系统及客户端且每个后台服务子系统包括应用服务器及与其连接的数据库服务器；数据转发子系统，用于连接后台服务子系统和客户端，根据数据属性，将客户端与其相应后台服务子系统的应用服务器相匹配，建立数据交互通道。所述数据处理方法包括以下步骤：客户端发送请求报文至与该客户端连接的首端应用路由器，所述请求报文包括数据属性和数据；根据数据属性和路由信息选择相应末端应用路由器，并根据确定转发方向，直至转发给与该末端应用路由器相连的后台服务子系统或者根据数据属性和路由信息直接选择相应的后台服务子系统，并根据连接拓朴信息确定转发方向。

Description

基于多层架构的数据处理系统及数据处理方法

技术领域

本发明涉及基于多层架构的数据处理系统，尤其是指兼容分布式和集中式数据处理的基于多层架构的数据处理系统及数据处理方法。

背景技术

现在行业应用软件，大部分是基于关系式数据库的信息处理系统，即MIS系统；软件的系统架构上从二层的C/S结构(客户端/服务器结构)，发展到B/S结构(浏览器/服务器)；进一步发展到三层结构(客户端/应用服务器/数据库服务器)，在三层结构中由SUN公司发展的J2EE架构和由微软公司发展的MS.NET架构是二种应用最广的系统架构。

请参照图1所示，所谓三层结构是指一套软件系统由直接与用户交互的“界面层”、负责业务处理的“业务处理层”、由数据库服务器组成的“数据存储层”组成，每层由一台或多台计算机组成，三层之间通过计算机网络连接。

所谓多层架构是指至少4层以上的架构。

另外，一般把不由最终用户直接操作的软件系统，统称为后台服务系统，比如三层结构中的业务处理层与数据存储层。而后台服务系统的部署方式，尤其是指数据存储层，即该系统中数据是集中存放在一个数据库服务器中，还是按一定规则分割存放在多个数据库服务器。如果集中存放则为集中式数据处理；如果分割存放则为分布式数据处理。

在此以证券交易系统为例，我国有上海、深圳二个证券交易所，有二百家左右的证券公司的通过遍布全国各大城市的计算机网络为全国几千万股民提供证券交易服务；按规定一家证券公司要求拥有5个以上证券营业部，这些营业部往往分布在一个地区，甚至全国各地。所以，证券公司通过部署一套或多套证券交易系统，接受股民的交易指令，通过与数据库服务器中的电子记录进行相应的资金与股票校验后，统一发往交易所进行买卖撮合；撮合成功后，将相应的电子记录存入数据库服务器，供股民查询；证券公司为股民提供多种下单手段，比如使用营业部现场的计算机设备、使用电话委托、通过Internet网上交易。

由于通信手段的限制，证券公司一般在一个营业部部署一套独立的证券交易系统，随着通信条件的改善，逐步发展到在一个城市或地区(或一个省内)部署一套系统，供多个营业部使用。由于业务处理系统的逐步集中(具体请参考申请号为02124781.1的中国专利申请)，对后台服务系统(尤其是数据库服务器)的计算机硬件平台的要求也越来越高，从普通的PC服务器，发展到使用高端小型机；中国的证券市场是一个新兴的市场，股民数量仍在逐年大幅增长；另一方面，国家出于风险控制与发展的需求，鼓励证券公司进行重组合并。由此，导致证券交易系统建设需要根据业务发展进行相应的调整：一般趋势是由分布各地，走向大集中，另一方面大集中后带来的性能瓶颈等技术风险，又要求对后台服务处理系统能根据需求进行适当分割调整与线性扩展。

目前在各证券公司使用的证券交易系统采用的实现方案有：

(1)将公司的客户按地理区域分割，只做小范围集中(50万客户以下)，超前投资硬件平台，确保当前所使用的计算机硬件平台能胜任业务系统处理要求；这种方案对于一些全国性的证券公司而言，仍然需要建设多套独立系统，不利与集约化管理；对于一些发展中的证券公司而言，业务的扩展也会受制与业务系统的处理能力，或者升级硬件平台时，难以保护已有的硬件投资；

(2)由公司统一建设独立的集中式的接入系统，比如网上交易、呼叫中心，由各营业部的股民在下单时明确自己的归属营业部，然后通过公司广域网将订单分发到相应的营业部进行处理；这种方案实现一定程度的资源共享，属于一种分布式的处理，每一个异地的业务处理点(营业部)，对证券公司来言都是一个风险高发区。

现有技术都是走向集中过程中的过渡性方案，只考虑到由分布式处理向集中式处理过渡，没有考虑到集中处理之后发生业务量突增时，系统处理能力是否可以在当前的计算机硬件水平上实现线程扩展。

在计算机硬件投资上，一方面要求具有一定的超前性，以适应可能的业务量发展的需要；另一方面当已有计算机硬件设备无法支撑业务处理时，进行整体更换后，难以保护原有的硬件投资。

发明内容

本发明解决的问题是提出一种基于多层架构的数据处理系统及数据处理方法解决分布式数据处理和集中式数据处理兼容问题。

为解决上述问题，本发明基于多层架构的数据处理系统，包括若干后台服务子系统及客户端，且每个后台服务子系统包括应用服务器及与其连接的数据库服务器；数据转发子系统，用于连接后台服务子系统和客户端，所述数据转发子系统包括若干应用路由器，应用路由器之间通过计算机网络协议连接且每个后台服务子系统的应用服务器连接有一个末端应用路由器而每个客户端连接有一个首端应用路由器，并根据数据属性确定相应的末端应用路由器及根据路由信息选择首端应用路由器和该末端应用路由器间的转发路径，从而建立数据通道。

所述数据为证券交易数据，所述证券交易数据属性包括表示交易操作的功能号、含有归属后台服务子系统信息且统一编码的客户号、股票代码及市场代码。

路由信息包括用于表示连接拓扑信息的转发对象标识及用于表示应用服务器业务处理能力的服务信息。

所述转发对象标识采用数据处理系统中相应连接对象唯一逻辑标识。

所述连接对象如果是应用路由器，则唯一逻辑标识包括应用路由器组名和组内顺序号；如果是应用服务器，则唯一逻辑标识包括应用服务器组名和组内顺序号或包括应用路由器组名、应用服务器组名和组内顺序号；如果是客户端，唯一逻辑标识包括应用路由器组名和客户端逻辑名或包括应用路由器组名和连接编号。

相应地，本发明基于多层架构的数据处理系统的数据处理方法包括以下步骤：客户端发送请求报文至与该客户端连接的首端应用路由器，所述请求报文包括数据属性和数据；根据数据属性和路由信息选择相应末端应用路由器，并根据确定转发方向，直至转发给与该末端应用路由器相连的后台服务子系统(或者根据数据属性和路由信息直接选择并发送相应的后台服务子系统)。

与现有技术相比，本发明具有以下优点：

本发明通过在传统三层结构数据处理系统中，增加一个实现数据多层转发的数据转发子系统，解决了我国证券公司使用的证券交易系统中后台服务子系统在多套分布式部署与单套集中式部署两种部署方式的双向平滑迁移的技术问题，屏蔽了不同部署方式对与系统使用者的影响。

本发明技术方案使后台服务子系统可以适应于不同档次的硬件平台，使用高端硬件平台时可以集中部署；使用低端硬件平台时，可以多套分布式部署。

本发明技术方案降低了业务量激增对后台服务子系统带来的服务质质量下降的技术风险，即业务量增加时可以通过增加部署多套后台服务子系统来分担业务处理负荷。

附图说明

图1是现有技术数据处理系统框图。

图2是本发明基于多层架构的数据处理系统框图。

图3是图2实施例框图。

具体实施方式

本发明基于多层架构的数据处理系统，既支持从分布式处理模式平滑迁移到集中处理模式，也支持在集中处理后，根据需要能对“后台处理服务”进行性能的线性扩展，能充分利用已有的计算机资源，保护前期投资，降低集中处理后的技术风险。

请参照图2所示，在三层结构的界面层与应用服务器层之间，增加一个负责按一定规则进行多次数据转发的应用路由层，由此构成的计算机软件系统结构称为多层架构，即至少4层以上：界面层、数据转发层、应用服务层、数据存储层。这样本发明基于多层架构的数据处理系统，包括：

若干客户端1，位于界面层，为客户提供界面输入输出；

若干后台服务子系统2，所述每个后台服务子系统2包括应用服务器(位于应用服务器层)及与其连接的数据库服务器(位于数据存储层)；

数据转发子系统3，用于连接后台服务子系统2和客户端1，根据数据属性，将客户端1与其相应后台服务子系统2的应用服务器相匹配，建立数据交互通道。

对客户端1而言，后台服务子系统2的位置是透明的(即客户端1不关心后台服务子系统2的具体物理位置)；对客户端1而言，后台服务子系统2是类型是透明的(即客户端1以统一的方式获得服务，后台服务子系统2可以采用不同种类的系统，比如可以是J2EE的应用服务器、MS.NET服务、专用的应用服务器，客户端1发送的不同的请求报文数据，可以由不同的应用服务器处理)。

请结合参照图3所示，数据转发子系统3包括若干应用路由器(例如用路由器31、32、33、34、35、36)，应用路由器之间通过计算机网络协议连接且每个后台服务子系统2的应用服务器(例如应用服务器21、22、23、24)连接有一个末端应用路由器(应用服务器35、36)而每个客户端(例如客户端11、12)连接有一个首端应用路由器(例如应用路由器31、32、33、34)，并根据数据属性确定相应的末端应用路由器及根据路由信息选择首端应用路由器和该末端应用路由器间的转发路径。实际应用中，应用路由器之间通过多种计算机网络协议(如：TCP/IP协议，SPX/IPX协议)相互连接，组成数据转发子系统；应用路由器也通过多种计算机网络协议与客户端及应用服务器相连。

数据转发子系统组网方式为树状拓扑、网状拓扑或基于集群的树状拓扑，具体内容如表1所表示：

                              表1：组网方式表

组网方式	说明	特点
			树状拓朴	每个应用路由器有一个上级连接，能接受多个下级连接，从而构成树状拓朴结构；	逻辑结构简单、系统部署时可以按近似企业的组织结构来部署，便于管理；每一个子树构成一个相对独立的数据转发区域，在当前转发区域内不能转发时，递交给上级应用路由器处理，如果数据本身来自上级应用路由器，则直接丢弃；但存在单点故障，即一个节点出现故障时，整个系统就被分割成二个网。
网状拓朴	每个应用路由器可以有多个上级连接，也能接受多个下级连接，从而构成网状拓朴结构；从一个应用路由器到另一个应用路由器，存在多条冗余的数据转发路径；	不存在单点故障；数据转发时，需要在多条冗余路径中选择最短、最快的路径；当一个节点的连接情况变动时，要通知其他节点；这种网状拓扑的管理方式是按照OSPF标准协议(参见RFC2328)
			基于集群的树状拓朴	多个等价的应用路由器组成集群，构成一个逻辑节点；多个逻辑节点之间再组成树状拓朴连接；数据向下一个逻辑节点转发时，要选择该集群中负载最轻的应用	既具有树状拓扑简单易管理的特点、又避免单点故障；树状拓扑作为网状拓朴的一种特例，拓扑管理也可以采用OSPF标准协议；

路由器；

本实施例中，以证券交易数据为例，所述证券交易数据属性包括表示交易操作的功能号、含有归属后台服务子系统信息且统一编码的客户号、股票代码、市场代码、买卖方向、买卖数量、买卖价格。例如，一个买卖股票委托单的数据报文，主要属性有：功能号(表示各类操作)、统一编码的客户号、股票代码、市场代码(交易所代码)、买卖方向、买卖数量、买卖价格

所述末端应用路由器的确定即后台服务子系统2的选择，可以数据属性中的客户归属选择，例如按统一编码的客户号中所含的归属营业部信息(比如前4位表示营业部号)，将此证券交易数据转发到相应的营业部的后台服务子系统进行处理；同理，可以选择按数据报文的其他属性进行转发，比如按市场代码，则后台服务系统就可以根据市场进行分割。

应用路由器维护的用于转发路径选择的路由信息分为二类：

(1)连接拓朴信息

一个通信连接由两个连接对象组成，每个连接对象(如：应用路由器、应用服务器、客户端)都有一个唯一逻辑标识(参见下表2：连接对象逻辑标识表)；应用路由器、应用服务器及客户端根据软件配置文件启动相互之间的通信连接；连接拓扑信息在实际网络连接变动时，在数据转发子系统3中通过OSPF协议进行同步。从连接对象逻辑标识表可以看出，由于应用服务器2与客户端1是可以通过所连的应用路由器进行定位的，所以连接信息可以设置成不在应用路由器网络中同步，以减轻连接变动时的同步数据量。所述连接对象如果是应用路由器，则唯一逻辑标识包括应用路由器组名和组内顺序号；如果是应用服务器，则唯一逻辑标识包括应用服务器组名和组内顺序号或包括应用路由器组名、应用服务器组名和组内顺序号；如果是客户端，唯一逻辑标识包括应用路由器组名和客户端逻辑名或包括应用路由器组名和连接编号。

                             表2：连接对象逻辑标识表

连接对象	唯一逻辑标识	说明
			应用路由器	应用路由器集群名(组名)+集群内顺序号(编号)	集群名(组名)在整个互连的应用路由器网络中唯一
应用服务器a	应用服务器集群名(组名)+集群内顺序号(编号)	应用服务器集群名(组名)在整个互连的应用路由器网络中唯一
			应用服务器b	所连的应用路由器集群名+应用服务器集群名(组名)+集群内顺序号(编号)	应用服务器集群名(组名)可以不唯一
客户端a	所连的应用路由器集群名+客户端逻辑名	知名客户端
			客户端b	所连的应用路由器集群名+连接编号	匿名客户端

(2)服务信息

服务信息是路由信息表的主要内容，用于表示某个应用服务器具有哪些业务处理能力的信息业务属性和业务功能(例如业务属性值和功能号)，其中业务属性指业务类别、客户号、银行号等可配置的常见数据属性及其组合；服务信息在应用服务器与应用路由建立连接时，每个后台服务子系统2向数据转发子系统3注册其的业务处理能力(如：可以处理哪些业务、哪些营业部、哪些市场等)，从而使数据转发子系统3能准确将数据转发到具有相应处理能力的后台服务子系统2进行处理。路由信息表实际中，每个后台服务子系统2先注册到末端应用路由器，再由该末端应用路由器负责在整个数据转发子系统中同步。路由信息表包括：各连接对象的互连信息(连接拓扑信息)和应用服务器的服务信息。各应用服务器注册服务信息可以在应用服务器连接到末端应用路由器时向应用路由器报告，也可以在各应用路由器上固定设置，当这两种方式同时存在时，以在线报告为优先。

服务信息也可以在路由软件的配置文件里预先设定，以减轻建立连接时的交换的数据量。

服务能力分类	说明
		按业务属性值	0、对具体业务功能进行分类后，形成业务类别属性，一般同一类业务由某个或某组应用服务器处理；1、按客户归属营业部属性，表明该应用服务器能处理哪些营业部

	的客户(证券业务系统中，客户一般归属某个营业部)；2、按业务涉及银行号属性，涉及银行的业务，一般由特定的应用服务器处理，一个应用服务器处理一个或多个银行的业务；3、其他属性，除了上述常用属性外，业务数据中的其他任意属性都可以作为服务能力的描述信息，多个属性之间还可以通过“与”“或”逻辑进行表示；
		按业务功能号	通过给具体的某个业务分配一个特定的功能号，通过功能号描述该应用服务器的业务处理能力；功能号可以逐个显式列举，也可以采用匹配串形式描述，如用？表示任意一个字符，用*表示任意字符串；

这样，路由信息包括转发对象标识及用于表示应用服务器业务处理能力的服务信息，且转发对象标识采用数据处理系统中相应连接对象唯一逻辑标识。例如一条应用路由信息：转发对象标识+按业务属性表示的处理能力+按功能号表示的处理能力。路由信息表中有的路由项是在该应用路由器上静态设置的，有的路由项则是动态的，即应用服务器在与建立连接时注册上来的，动态的路由项会在所有互连的应用路由器中自动同步。每个应用路由器上都有路由信息表包括两个表：连接拓朴信息表(每个应用路由器上此表动态同步)、服务信息表(也称路由项表，每个应用路由器上动态注册的条目会动态同步，静态设置的条目则各可以不同)。下面以图3为例：

(1)服务信息表(假设只按功能号与营业部号两个属性选择路由)

标识	按功能号表示的处理能力	按营业部号属性表示的处理能力	说明
				应用服务器21	0001～0999	0001～010	处理南方营业部客户的0001～0999业务功能；
应用服务器22	1001～1999	0001～0010	处理南方营业部客户的1001～1999业务功能；
				应用服务器23	0001～0999	0011～020	处理北方营业部客户的0001～0999业务功能；
应用服务器24	1001～1999	0011～020	处理北方营业部客户的1001～1999业务功能；

应用路由器35(在本实施例中是属于末端应用路由器)上的服务信息表(路由项表)实例：

标识	类型	按功能号表示的处理能力	按营业部号属性表示的处理能力	说明
					应用服务器21	相邻应用服务器	0001～0999	0001～0010	动态注册
应用服务器22	相邻应用服务器	1001～1999	0001～0010	动态注册
					应用服务器23	非相邻应用服务器	0001～0999	0011～0020	动态注册，由应用路由器36同步过来
应用服务器24	非相邻应用服务器	1001～1999	0011～0020	动态注册，由应用路由器36同步过来

应用路由器34(在本实施例中是属于首端应用路由器)上的服务信息表(路由项表)中没有列出动态注册的条目，因为动态注册的同步范围是可以限定的，用于防止同步信息过多。

标识	类型	按功能号表示的处理能力	按营业部号属性表示的处理能力	说明
					应用路由器35	相邻应用路由器	0001～09991001～1999	0001～00100001～0010	静态设置，可以使用通配符来表示处理能力，从而简化设置由于应用路由器35与两个应用服务器21、22相连，所以可以认为应用路由器35具有那两个应用服务器的处理能力。
应用路由器36	相邻应用路由器	1001～19991001～1999	0001～00100011～0020	静态设置，可以使用通配符来表示处理能力，从而简化设置由于应用路由器36与两个应用服务器23、24相连，所以可以认为应用路由器36具有那两个应用服务器的处理能力。

(2)连接拓朴信息表(假设各应用路由器之间预设是两两互连，实际通信断开时，各应用路由器上的此表会相应变动)

编号	端1	端2	说明
				1	应用路由器35	应用服务器21	连接建立时，应用服务器21会向应用路由器35注册自己的处理能力，应用路由器35会根据设置决定是否要把应用

比如一个请求包转发，包括以下步骤：1)在服务信息表(路由项表)中查找，找到业务信息处理能力匹配的转发对象(找到一个匹配的即可)；2)通过表项中的类型，可以判断找到的对象是否与当前应用路由器直接相连；3)如果直接相连，则可以直接转发；4)否则根据转发对象的标识，在连接拓朴信息表中，使用OSPF算法确定应该向在当前应用路由器的所有邻居中的哪一个转发(即转发给这个邻居，由此邻居再去决定下次的转发方向)。对于一个明确目标对象的数据包(比如一个应答包)，简化为上述的步骤4)。根据上述流程可知，在服务信息表中类型一栏可以设为未知的，这种情况下，就会跳过步骤2)、3)，增加类型一栏，是为了当目标对象与本应用路由器直接相连时，加快路由计算(不必进行费时的OSPF计算)。

当符合上述数据属性和路由信息有多条转发路径时，则采用轮流或按负载情况选择负载最轻的路径发送。在请求-应答的通信模式中，请求数据需要按一定的数据属性和路由信息来选择路径，而应答数据应为有明确的接收者，则以最短、最快的原则直接使用OSPF算法来选择转发路径，转发对象/路径选择需要考虑下面因素：

(1)应用路由器根据路由信息表列举所关心的业务属性，从转发数据中获取相应的业务数据属性值及功能号；

(2)搜索当前应用路由器的路由信息表，根据当前数据中相应的属性值，匹配每个转发对象的按业务属性表示的处理能力；若业务属性相匹配，则再检查功能号是否在该转发对象的处理范围之内；

(3)如果找到二项处理能力都匹配的转发对象，如果该转发对象与当前应用服务器直接相连，则可以直接转发；否则在连接对象逻辑标识表中按OSPF协议，寻找最短最快的转发路径，从而确定当前应用路由应该向哪个下级连接对象转发当前数据；

(4)当连接对象以集群方式部署时，当前应用路由器还要根据负载确定向集群中的哪个成员发送；负载信息是在相互通信过程中以负载因子的形式交换的；当要负载因子相同时，则以顺序轮换的方式来均衡负载。

相应地，本发明一种基于多层架构的数据处理系统的数据处理方法包括以下步骤：客户端发送请求报文至与该客户端连接的首端应用路由器，所述请求报文包括数据属性和数据；根据数据属性和路由信息选择相应末端应用路由器，并根据确定转发路径，直至转发给与该末端应用路由器相连的后台服务子系统，建立数据交互通道。具体包括以下步骤：

客户端11将服务请求通过网络发送给与其相连的首端应用路由器32；

首端应用路由器32在整个数据转发子系统2中搜寻，发现能处理该请求的应用服务器21或22是与末端应用路由器35相连接的，就将请求转发给末端应用路由器35；

末端应用路由器35发现应用服务器21或22都能处理这个请求，根据负载均衡将请求发给负载较轻的应用服务器21进行处理；

应用服务器21处理该请求，并根据业务处理逻辑的需要访问后台数据库服务器41，并将处理结果(应答)返回给末端应用路由器35，并按原请求的转发路径返回给客户端11。

本实施例中，根据请求数据中的有关数据属性值来进行，比如该客户是A营业部，该营业部的数据都在数据库服务器41中，则首端应用路由器32可以根据请求中的营业部信息来决定转发路径；应用服务器是具有具体处理能力的单元，因在初次连接应用路由时，向所连的应用路径通报其业处理能力的服务信息，这种服务信息会在应用路由器之间进行传递，从而影响各应用路由的转发路径选择；应用服务器也随时向应用路由器通报其负载情况，以便应用路由器可以进行负载均衡。

具体地，在本发明应用在证券交易系统中，用户在客户端11、12的操作，与应用服务器21、22、23、24之间，通过请求-应答模式的通信交互机制完成各类证券业务，如买卖股票、查询余额等。下面举例给出证券数据的提交、转发、处理的详细过程：

例如，将所有南方区营业部的客户数据存放在数据库服务器41中，所有北方区营业部的客户数据存放在数据库服务器42中。这两个数据库服务器41、42可以集中放在中心机房，也可以异地存放(如：以南北中心的方式)。

南方营业部的编号是0001～0010，北方营业部的编号是0011～0020，营业部编号信息保含在每个股民的客户编号中(比如：前4位)。

现在有一个股民A他的编号是0005000001，从编号可以知道他属于南方的一个营业部。股民A通过任意一个客户端，比如位于一个北方营业部的客户端12，进行下订单买入股票操作，这个订单请求中包含了股民A的客户号0005000001：

请求报文从客户端12送到了首端应用路由器32，假设订单请求的功能号为0001；

首端应用路由器32从订单请求报文中的客户号属性，判断出该客户属南方区营业部，可以向应用路由器35转发，或者先发给应用路由器36，由应用路由器36再向应用路由器35转发；首端应用路由器32根据两个转发路径上的通信延时、流量状况或者其他负载均衡情况，决定向应用路由器35转发。

应用路由器35收到股民A的订单请求报文，根据报文中的功能号属性(0001)及客户号中的营业部属性(0005)，判断与它相连的后台服务子系统2中的应用服务器21、22哪个能处理0005营业部的0001功能；应用路由器35做出这个判断的依据是由与其相连的应用服务器21、22注册的服务信息；如果两个应用服务器都能处理当前的订单请求，则应用路由器35要根据预定的负载均衡策略，作出转发路径选择，比如根据应用服务器上排队等待处理的请求报文数量，或者应用服务器的CPU处理器繁忙程度，决定将当前报文转发给应用服务器22；

在这个系统架构中，应用服务器21、22与数据库服务器41都属于后台服务子系统2。应用服务器22收到股民A的订单请求报文后，通过与数据库服务器41的交互进行相应的业务处理，处理结果形成应答报文，发送给应用路由器35；

应答报文最后由客户端12展示给操作股民0005000001。在应答报文通过数据转发子系统2原路径返回给客户端12的过程中，每一次转发，各应用路由仍然要遵守通信负载均衡的策略。

实际应用中，证券公司可以使用当前已有的通信手段与计算机硬件平台构建全国性的大集中证券交易处理系统，实现100万以上客户的交易集中处理，处理能力可以随客户数的增加而线性扩展。本发明技术方案具有数据多次转发功能的数据转发子系统的多层系统架构；

数据转发子系统本身可以构成复杂的网状连接；通过数据转发子系统的隔离，客户端可以以统一的方式访问异构应用服务器(即提供服务的应用服务器可以是J2EE的应用服务器、MS.NET服务器、专用的应用服务器等)，使得证券交易系统部署灵活，按需部署；保护已有计算机硬件投资。

Claims (9)

1.一种基于多层架构的数据处理系统，包括若干后台服务子系统及客户端，且每个后台服务子系统包括应用服务器及与其连接的数据库服务器，其特征在于，还包括：数据转发子系统，用于连接后台服务子系统和客户端，所述数据转发子系统包括若干应用路由器，应用路由器之间通过计算机网络协议连接且每个后台服务子系统的应用服务器连接有一个末端应用路由器而每个客户端连接有一个首端应用路由器，并根据数据属性确定相应的末端应用路由器及根据路由信息选择首端应用路由器和该末端应用路由器间的转发路径，从而建立数据通道。

2.如权利要求1所述的基于多层架构的数据处理系统，其特征在于，所述数据为证券交易数据，所述证券交易数据属性包括表示交易操作的功能号、含有归属后台服务子系统信息且统一编码的客户号、股票代码及市场代码。

3.如权利要求2所述的基于多层架构的数据处理系统，其特征在于，路由信息包括用于表示连接拓扑信息的转发对象标识及用于表示应用服务器业务处理能力的服务信息。

4.如权利要求3所述的基于多层架构的数据处理系统，其特征在于，所述转发对象标识采用数据处理系统中相应连接对象唯一逻辑标识。

5.如权利要求4所述的基于多层架构的数据处理系统，其特征在于，所述连接对象如果是应用路由器，则唯一逻辑标识包括应用路由器组名和组内顺序号；如果是应用服务器，则唯一逻辑标识包括应用服务器组名和组内顺序号或包括应用路由器组名、应用服务器组名和组内顺序号；如果是客户端，唯一逻辑标识包括应用路由器组名和客户端逻辑名或包括应用路由器组名和连接编号。

6.如权利要求4所述的基于多层架构的数据处理系统，其特征在于，服务信息包括业务属性和功能号，其中业务属性指业务类别、客户号、银行号及其组合。

7.如权利要求1至6任意一项所述的基于多层架构的数据处理系统，其特征在于，数据转发子系统组网方式为树状拓扑、网状拓扑或基于集群的树状拓扑。

8.如权利要求1所述的基于多层架构的数据处理系统，其特征在于，所述转发路径从符合数据属性和路由信息多个路径选择负载最轻的路径。

9.一种基于多层架构的数据处理系统的数据处理方法，其特征在于，包括以下步骤：客户端发送请求报文至与该客户端连接的首端应用路由器，所述请求报文包括数据属性和数据；

根据数据属性和路由信息选择相应末端应用路由器，并根据确定转发方向，直至转发给与该末端应用路由器相连的后台服务子系统。

Images