CN103825830B - 基于tuxedo中间件的系统实现流量管控的方法和装置 - Google Patents

Abstract

基于TUXEDO中间件的系统实现流量管控的方法和装置，对于震荡型高容量的联机事务处理系统能够起到重要流量管控作用，包括如下步骤：对于基于TUXEDO中间件构建的应用系统进行架构分离部署，把通信接入层与业务单元处理层分离，在所述业务单元处理层中将业务正常处理服务与业务流量管控服务进行分离部署；所述通信接入层在接收到交易请求后，根据业务类型，确定该交易请求匹配的进行既定服务的TUXEDO服务名，从应用系统里获取该TUXEDO服务名对应的当前交易待处理排队数目，如果该排队数目大于设定阈值则将新入交易请求发送到业务流量管控服务进行交易分流，如果不大于设定阈值则将新入交易请求发送到业务正常处理服务。

Description

基于TUXEDO中间件的系统实现流量管控的方法和装置

技术领域

本发明涉及基于TUXEDO中间件构建应用系统的流量管控技术，特别是一种基于TUXEDO中间件的系统实现流量管控的方法和装置，对于震荡型高容量的联机事务处理系统能够起到重要流量管控作用。

背景技术

TUXEDO中间件是EBA公司的交易中间件产品，是目前联机事务处理系统（OLTP）使用的主流中间件平台，在金融、电信、交通等行业广泛使用。基于TUXEDO中间件的应用系统是利用中间件的高层次编程接口完成系统的运行以实现交易的通信、业务逻辑单元的处理、数据的存储，利用中间件技术可以使应用系统以较低成本具有以下特点，支持大业务量下的联机事务处理、支持多种软硬件平台、具有丰富的通信机制、拥有强大的管理功能、具备有效的安全性管理能力。目前很多行业都搭建了基于TUXEDO中间件的应用业务系统，有业务单一的计费系统，有集中处理并发要求很高的订票系统，有业务分布复杂对交易响应要求很高的前置交换系统。所有系统享受着TUXEDO中间件带来的便利和强大的功能的同时也面临着随着业务量的变化带来的容量问题，在业务量突增达到某个临界点的时候系统会遇到性能下降，系统响应缓慢甚至由于系统资源使用耗尽导致系统瘫痪的情况，给使用客户带来财务风险。

TUXEDO中间件自身有交易请求缓冲功能，会通过其安全队列缓冲技术来管理请求交易，使所有交易在其可控范围内进行排队。当交易不断的涌到系统的时候，TUXEDO自身的管理队列的排队消息会慢慢增多，这样会出现两个问题：1.由于90%的联机交易系统会选择同步短连接的通信方式，在这种方式下交易的请求方会一直等待交易的应答，如果服务方交易排队量越来越多，客户端的等待应答的时间会越来越长，直到等待响应超时，对于请求系统可能会造成交易堵塞或者系统瘫痪的状况，客户体验变差。2.应用系统本身使用的队列资源的占用会影响整个系统的运行效率，其中某部分业务单元的排队对系统资源的占用会影响其他没有排队的业务单元，造成非预期的影响，在甚至会导致系统崩溃风险，不得不停止服务。本发明人认为，采用流量管控技术能够有利于上述问题的解决。流量管控是系统在某种特定的运行状态下根据事先设计好的逻辑规则对系统的访问流量进行管理控制的一种策略。它的意义在于当系统处理能力突然达到系统某个系统限制下，为了防止系统资源被继续消耗可能带来的崩溃风险，为了保障系统的正常运行，对请求交易进行管理，根据当前的处理情况进行控制，并通过既定的业务规则反馈给交易请求方系统目前处理繁忙，请稍后再试。

发明内容

本发明针对现有技术中存在的缺陷或不足，提供一种基于TUXEDO中间件的系统实现流量管控的方法和装置，对于震荡型高容量的联机事务处理系统能够起到重要流量管控作用。采用所述方法和装置，有利于解决客户日益增长的业务对于基于TUXEDO中间件建设的系统容量的需求。

本发明的技术方案如下：

基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，包括如下步骤：对于基于TUXEDO中间件构建的应用系统进行架构分离部署，把通信接入层与业务单元处理层分离，在所述业务单元处理层中将业务正常处理服务与业务流量管控服务进行分离部署；所述通信接入层在接收到交易请求后，根据业务类型与交易码之间的对应关系、以及交易码与业务单元处理层中TUXEDO服务名的对应关系，确定该交易请求匹配的进行既定服务的TUXEDO服务名，从应用系统里获取该TUXEDO服务名对应的当前交易待处理排队数目，如果该排队数目大于设定阈值则将新入交易请求发送到业务流量管控服务进行交易分流，如果该排队数目不大于设定阈值则将新入交易请求发送到业务正常处理服务。

把通信接入层包括如下通信接入模式：TCP/IP通信接入方式，支持同步短连接、同步长连接、异步短连接和异步长连接；TUXEDO中间件接入方式。

应用系统架构在TUXEDO中间件之上，对应用系统进行架构分离，在通信接入层通过增加部署服务数目和减少业务逻辑处理的策略来达到无障碍、高并发交易的接入；根据TUXEDO安全队列缓冲原理，识别中间件使用操作系统基础消息队列规则，通过对操作系统消息队列的访问，识别当前TUXEDO系统交易排队详细数据；根据系统开发人员制定的流量管控规则结合当前交易排队详细数据来判断当前系统是否超出预定容量范围，如果超出则对新入交易进行流量管控进行交易分流。

所述通信接入层支持对业务类型的识别，根据既定的业务报文规则对具体交易进行识别，并对识别出来的业务报文给予系统统一命名规范的命名，一般我们会称为交易码，以便供整个业务系统进行使用和管理。

所述应用系统根据TUXEDO中间件服务配置信息制定应用系统使用的服务信息列表，主要包括每个TUXEDO服务所使用的队列信息，主要是操作系统消息队列ID号；存储方法使用操作系统共享内存机制，提高系统对队列信息的读取效率。

所述通信接入层在接收到交易请求后，根据业务规则识别出交易码，然后根据交易码以及业务定制信息匹配出该交易码所对应的TUXEDO服务名称，这样接入层服务器就可以把交易请求发送到既定服务进行处理。

所述通信接入层的服务器在发送交易到既定TUXEDO服务进行处理前是对交易请求进行流量管控的最佳时间点，接入层服务器需要根据交易码所对应的服务名从系统使用队列列表里找到服务使用的队列ID，然后根据队列ID通过操作系统的队列API可以获取目前队列ID里存储的队列数目，这样就可以掌握当前服务的交易请求排队数据，然后根据开发人员定制的交易访问阀值进行对比，如果目前排队数目多于阀值数目，则对新进交易进行流量管控，反之如果目前排队数目还没有达到阀值数目，则新进交易正常按照既定流程进行处理。

所述业务流量管控服务的流量管控处理手段，对于符合管控条件的交易不能丢弃，这样交易请求方就不能及时了解服务方具体情况，被管控的交易需要想办法让它及时按照既定业务规则及时返回交易请求方。

由于业务逻辑处理是在业务处理层TUXEDO服务里进行，所以被管控交易也要进入业务处理层才能按照原业务规则返回；既然该交易被流量管控，那就说明该交易的服务处理层是饱和的，交易是在排队的，如果用同样的服务来处理依然会排队不能及时返回，所以对流量管控的交易进行处理的服务要进行剥离，与正常交易处理服务进行分离，而且处理逻辑简单能够迅速处理完成并应答给请求方说明服务方具体情况。这样整个系统在设计初就需要将业务正常处理服务与业务流量管控服务进行分离部署。

基于TUXEDO中间件的系统实现流量管控的装置，其特征在于，包括在基于TUXEDO中间件构建的应用系统中分离部署的通信接入层服务器与业务单元处理层服务器，在所述业务单元处理层服务器中包括分离部署的业务正常处理服务模块与业务流量管控服务模块；所述通信接入层在接收到交易请求后，根据业务类型与交易码之间的对应关系、以及交易码与业务单元处理层中TUXEDO服务名的对应关系，确定该交易请求匹配的进行既定服务的TUXEDO服务名，从应用系统里获取该TUXEDO服务名对应的当前交易待处理排队数目，如果该排队数目大于设定阈值则将新入交易请求发送到业务流量管控服务进行交易分流，如果该排队数目不大于设定阈值则将新入交易请求发送到业务正常处理服务。

本发明的技术效果如下：本发明相对于基于TUXEDO建设的应用系统而言，具有以下特点：该技术其原理是根据消息队列内排队消息数目来作为管控依据，与特定系统没有关系，可以不依赖于应用本身。该技术由于直接通过操作系统API来访问系统队列，与TUXEDO中间件本身管理机制没有关系，通过操作系统API直接访问其使用队列，避免使用TUXEDO管理API减少了TUXEDO软件本身的管理资源使用，保障了TUXEDO本身不受影响。通过流量管控技术，提前进行系统风险管控，根据系统配置以及实际业务交易量评估系统容量，设置管控阀值，降低了运维成本，使系统可用自动适应系统突然的交易响应时间变化和交易量变化。阀值配置灵活，管控粒度灵活可用根据不同粒度来进行配置，比如交易码、业务流程、交易渠道、业务种类。

附图说明

图1是交易处理流程图。

图2是流量管控逻辑图。

图3是TUXEDO通信方式接入结构图。

图4是TCP通信方式接入结构图。

图5是流量管控示意图。

具体实施方式

下面结合附图（图1-图5）对本发明进行说明。

本发明提供一套业界主流中间件产品TUXEDO的安全队列的识别方法，生成一套基于TUXEDO中间件产品的应用系统的流量管控方案和实现方法。本发明的目的是通过基于TUXEDO中间件产品的应用系统的流量管控方法，实现应用系统的交易访问分流，快速处理系统堵塞情况下的新增交易，使系统排队交易得以顺利进行，保证系统的稳定，减少对访问系统的同步超时影响，大大提高了业务使用者或者客户的系统使用体验。

本发明人通过对TUXEDO产品安全队列的识别，加之对操作系统队列的访问封装，结合具体业务系统要求情况，设计出一套通用基础架构，本架构具有如下特性：1.成熟的部署架构：基于TUXEDO中间件实现，系统接入层与系统逻辑处理层分离部署，对接入层进行功能最小化处理，大幅提高接入层处理性能，功能处理集中在业务处理层。2.高效的分流机制：对于被流量管控的处理原则是不丢弃、按照原业务要求返回、快速处理、由业务处理层统一处理、不增加额外开发工作量。3.可定制化的操作机制：考虑到用户业务需求的多样性和复杂性，框架提供可灵活定制的操作机制，满足按照交易、按照渠道、按照业务等不同细分粒度进行流量管控定制，根据业务变化情况灵活调整阀值参数。

本发明深入了解TUXEDO中间件技术，掌握其安全队列管理原理，设计出合理有效的应用系统流量管控技术。考虑系统的稳定性和性能，提供了成熟的系统架构部署方案；考虑到用户的体验度和交易规则的遵守度，提供了高效的分流机制；考虑到用户的需求的多样性和复杂性，提供了可定制化的操作机制。该技术为软件集成商提供了可操作的、科学的实现方法和依据。

本发明为了达到业务系统流量管控的目的，从以下几个方面进行了分析、约定和设计。

一、系统流量管控方法的设计原理

基于TUXEDO中间件的应用系统主要有两种接入方式：

1.TUXEDO通信方式接入（见图3）：系统发布TUXEDO服务作为外围系统的访问接入点，交易接入以后调用业务逻辑处理服务进行交易处理。

2.TCP通信方式接入（见图4）：系统发布TCP通信服务端口作为外围系统的访问接入点，外围系统通过SOCKET进行链路连接，建立TCP通信链路后进行交易报文的发送，交易接入后调用业务逻辑处理服务进行交易处理。

从图1和图2可以看出，系统结构比较统一，任何一个交易请求，首先通过TUXEDO接入或TCP接入网关，通过tpforward或tpacall这种异步方式，发送请求报文到TUXEDO业务处理服务队列，等候服务的处理。并且所有核心交易逻辑处理都采用了同步模式，一个服务完成交易的全部处理。从这个体系结构可以看出系统的瓶颈将出现在服务处理上，阻塞的请求报文主要存储在每个应用服务器的请求队列中，而网关部分由于采用异步模式，所以交易不会导致请求阻塞在网关上。

由此，系统的流量控制的负载检查机制只需要建立在每个处理服务的请求队列上就可以了。此方案有两个关键点：

1.判断系统过载的方式。TUXEDO提供了访问管理信息库的API，可调用TMIB动态访问每个应用服务器的当前队列的负载。但是这种方法在系统交易高峰期，TUXEDO本身处理就比较忙碌，加上频繁调用TMIB服务会对TUXEDO本身带来一定的压力，有可能会导致不可知的系统问题。最终我们选择另外一种直接的方式，绕过TUXEDO本身通过查询系统消息队列ID来查询当前队列负载。因此余下的问题就是如何管理每个交易对应的应用服务器当前的负载阀值。

设置阀值的粒度有如下几种方式：（1）按外部交易码；（2）内部交易码；（3）按请求渠道；（4）业务种类。

本设计采用文件配置的方式。文件由阀值项构成，允许以#开头的注释，阀值项格式如下：渠道号.业务种类=阀值。

流量管控策略可以针对不同的TUXEDO配置做负载控制

2.共享内存存储。本设计有两块信息需要存储，一是每个业务处理服务所用到的队列ID，一是应用系统建设时设置的各种阀值信息，比如某个交易对其交易码设置流量管控阀值。

为了提高信息的读取检索速度，以上两块信息存储到共享内存区域，结合应用系统，以系统本身的规则格式存储以上信息。

如果当前应用系统过载，如何按照原业务规则进行交易的应答处理，避免请求方无谓的超时等待。

当请求交易发现其对应的应用服务器当前工作负载超过阀值后，如果直接丢弃报文，将导致请求方无谓等待，直到超时。因此最好进行某种处理，避免这种情况的发生。根据通讯方式的不同，建议如下:

(1)请求方通过TUXEDO的tpcall方式访问系统，可以PBMIDGW直接丢弃报文，tpreturn(TPFAIL,0,NULL,0,0);请求方将收到通讯异常的响应，从而进行相应的处理。

(2)请求方通过TCP/IP的方式访问前置，由于TCP/IP的通讯模式比较复杂，尤其对于异步的通讯模式，如果tpacall直接失败，也不能直接发送应答到请求方，因此必须有某种机制保证应答的返回，现设计如下的机制：

a)提供一个超时处理服务器，PbTimeOutServer.

b)当请求交易对应的应用服务负载超阀值后，直接请求PbTimeOutServer.

c)PbTimeOutServer的功能是一个所有业务处理逻辑的全集，当它收到报文后，执行原请求报文对应交易流程，但在与主机通讯或第三方通讯时，其立即报通讯异常，由于原交易流程的完整性，交易将返回相应的交易异常应答到TCP/IP请求方。

二、系统流量管控方法的设计实现

系统设计如下接口供应用系统调用：

1.获取当前启动的所有TUXEDO服务信息，包括服务名，队列个数，队列ID

函数名称：int GetQueInfo(LOADCTL_STRU queinfo[])

功能：获取当前启动的所有TUXEDO服务信息，登记到临时的结构体数组queinfo中

2.获取系统指定ID消息队列

函数名称：int SetQueLoadFmt(int QueID)

功能：获取指定ID的消息数目。

3.获取指定渠道外部交易码的负载阀值及超载服务名，特殊处理标志

函数名称：int getCfgVlues(...)

功能：根据渠道及外部交易码及流量配置表取对应的负载阀值及超载服务，如果流量配置表未配置，则负载阀值默认为0，超载服务为空。

目前分为四种控制方式：按渠道控制：默认当前渠道下的所有外部交易码配置相同。按业务控制：当前业务种类下所有对应的外部交易码配置相同。按外部交易码控制：取指定渠道，指定外部交易码的配置。按业务流程：取当前业务流程对应的内部交易码进行配置。

头文件定义如下，用于保存启动的服务的信息。

三、系统流量管控方法的使用规范

TUXEDO服务与流量控制的关系

1.在TUXEDO服务未启动的情况下，由于要将业务处理服务对应的队列ID初始化到流控共享内存中，此时获取服务队列ID失败，会出现初始化流控失败信息，这种情况下流量控制失效。

2.在TUXEDO服务已经启动的情况下，初始化流控共享内存成功，流控配置有效。

3.在TUXEDO服务重启的情况下，需要重新初始化流控共享内存，保证队列ID与系统共享内存中的对应ID一致。否则会在交易及流控更新日中会打印日志，提示队列不一致信息。

机制启动控制：系统流量管控机制可以通过系统应用开关来控制，在系统变量池中配置“CHKSERCFG”参数，当值为“YES”表示启动负载检查机制。“NO”表示关闭负载检查机制。

阀值参数配置方式

1.在.profile中增加负载阀值参数文件路径的环境变量ServCfgFile.

例如：

export ServCfgFile=$HOME/etc/ServCfgFile.cfg

2.在$HOME/etc目录下编写$ServCfgFile配置文件，文件由阀值项构成，允许以#开头的注释，阀值项格式如下：渠道号.业务种类=阀值。

负载值的配置需要根据各系统的业务情况具体配置，如果没有配置相关的渠道.业务种类项，则取缺省值default,缺省值可以设置，模板文件的缺省值为100。

#负载缺省值,如果没有配置则取缺省值

default=100

#负载配置值,流控类型.流控内容=负载值

#1-外部交易码2-业务种类3-请求渠道4-内部交易码

1.810001=100

一种基于TUXEDO中间件的通用流量管控机制的实现方法和系统，其特征在于包括如下步骤：应用系统架构在TUXEDO中间件之上，对应用系统进行架构分离，把通信接入层与业务单元处理层分离；在通信接入层通过增加部署服务数目和减少业务逻辑处理的策略来达到无障碍、高并发交易的接入；根据TUXEDO安全队列缓冲原理，识别使用系统基础队列规则，通过对操作系统队列的访问，识别当前TUXEDO系统交易排队详细数据；根据系统开发人员制定的流量管控规则结合当前交易排队详细数据来判断当前系统是否超出预定容量范围，如果超出则对新入交易进行流量管控进行交易分流。通信接入服务与业务处理服务分离的TUXEDO部署架构。通信接入层的轻量级设计。所述选用的流量管控功能能够根据需要进行开关切换。使用了TUXEDO安全队列的设计原理。通过操作系统的消息队列API操作技术实现对TUXEDO安全队列的访问。流量管控后被分流的交易处理服务与原正常交易处理服务分离部署。流量管控后被分流的交易不丢弃而是按照业务规则快速返回。流量管控负载阀值可以根据不同的粒度进行配置。

Claims (10)

1.基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，包括如下步骤：对于基于TUXEDO中间件构建的应用系统进行架构分离部署，把通信接入层与业务单元处理层分离，在所述业务单元处理层中将业务正常处理服务与业务流量管控服务进行分离部署；所述通信接入层在接收到交易请求后，根据业务类型与交易码之间的对应关系、以及交易码与业务单元处理层中TUXEDO服务名的对应关系，确定该交易请求匹配的进行既定服务的TUXEDO服务名，从应用系统里获取该TUXEDO服务名对应的当前交易待处理排队数目，如果该排队数目大于设定阈值则将新入交易请求发送到业务流量管控服务进行交易分流，如果该排队数目不大于设定阈值则将新入交易请求发送到业务正常处理服务。

2.根据权利要求1所述的基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，把通信接入层包括如下通信接入模式：TCP/IP通信接入方式，支持同步短连接、同步长连接、异步短连接和异步长连接；TUXEDO中间件接入方式。

3.根据权利要求1所述的基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，应用系统架构在TUXEDO中间件之上，对应用系统进行架构分离，在通信接入层通过增加部署服务数目和减少业务逻辑处理的策略来达到无障碍、高并发交易的接入；根据TUXEDO安全队列缓冲原理，识别中间件使用操作系统基础消息队列规则，通过对操作系统消息队列的访问，识别当前TUXEDO系统交易排队详细数据；根据系统开发人员制定的流量管控规则结合当前交易排队详细数据来判断当前系统是否超出预定容量范围，如果超出则对新入交易进行流量管控进行交易分流。

4.根据权利要求1所述的基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，所述通信接入层支持对业务类型的识别，根据既定的业务报文规则对具体交易进行识别，并对识别出来的业务报文给予系统统一命名规范的命名，一般我们会称为交易码，以便供整个业务系统进行使用和管理。

5.根据权利要求1所述的基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，所述应用系统根据TUXEDO中间件服务配置信息制定应用系统使用的服务信息列表，所述服务信息列表主要包括每个TUXEDO服务所使用的队列信息，所述队列信息主要是操作系统消息队列ID号；存储方法使用操作系统共享内存机制，提高系统对队列信息的读取效率。

6.根据权利要求1所述的基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，所述通信接入层在接收到交易请求后，根据业务规则识别出交易码，然后根据交易码以及业务定制信息匹配出该交易码所对应的TUXEDO服务名称，这样接入层服务器就可以把交易请求发送到既定服务进行处理。

7.根据权利要求1所述的基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，所述通信接入层的服务器在发送交易到既定TUXEDO服务进行处理前是对交易请求进行流量管控的最佳时间点，接入层服务器需要根据交易码所对应的服务名从系统使用队列列表里找到服务使用的队列ID，然后根据队列ID通过操作系统的队列API可以获取目前队列ID里存储的队列数目，这样就可以掌握当前服务的交易请求排队数据，然后根据开发人员定制的交易访问阈值进行对比，如果目前排队数目多于阈值数目，则对新进交易进行流量管控，反之如果目前排队数目还没有达到阈值数目，则新进交易正常按照既定流程进行处理。

8.根据权利要求1所述的基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，所述业务流量管控服务的流量管控处理手段，对于符合管控条件的交易不能丢弃，这样交易请求方就不能及时了解服务方具体情况，被管控的交易需要想办法让它及时按照既定业务规则及时返回交易请求方。

9.根据权利要求1所述的基于TUXEDO中间件的系统实现流量管控的方法，其特征在于，由于业务逻辑处理是在业务处理层TUXEDO服务里进行，所以被管控交易也要进入业务处理层才能按照原业务规则返回；既然该交易被流量管控，那就说明该交易的服务处理层是饱和的，交易是在排队的，如果用同样的服务来处理依然会排队不能及时返回，所以对流量管控的交易进行处理的服务要进行剥离，与正常交易处理服务进行分离，而且处理逻辑简单能够迅速处理完成并应答给请求方说明服务方具体情况，这样整个系统在设计初就需要将业务正常处理服务与业务流量管控服务进行分离部署。

10.基于TUXEDO中间件的系统实现流量管控的装置，其特征在于，包括在基于TUXEDO中间件构建的应用系统中分离部署的通信接入层服务器与业务单元处理层服务器，在所述业务单元处理层服务器中包括分离部署的业务正常处理服务模块与业务流量管控服务模块；所述通信接入层在接收到交易请求后，根据业务类型与交易码之间的对应关系、以及交易码与业务单元处理层中TUXEDO服务名的对应关系，确定该交易请求匹配的进行既定服务的TUXEDO服务名，从应用系统里获取该TUXEDO服务名对应的当前交易待处理排队数目，如果该排队数目大于设定阈值则将新入交易请求发送到业务流量管控服务进行交易分流，如果该排队数目不大于设定阈值则将新入交易请求发送到业务正常处理服务。