CN104581794A - 一种中间件业务故障处理方法及系统 - Google Patents

Abstract

本发明提供一种中间件业务故障处理方法及系统，所述方法通过实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值；筛选出服务效率差的中间件链路；分别确定服务效率差的中间件链路的业务量和平均响应时间是否在响应时间和业务量的可信区间内，以及确定服务效率差的中间件链路的业务量和平均响应时间是否偏离业务效率基线值，根据确认结果重置中间件链路。与现有技术相比，本发明解决了在中间件集群中单链路问题引起的高实时性业务效率降低，人工查证耗时长、问题易扩大化等缺陷，从实际场景出发提升工作效率，降低风险。

Description

一种中间件业务故障处理方法及系统

技术领域

本发明涉及移动通信技术领域，尤其涉及一种中间件业务故障处理方法及系统。 

背景技术

现有大型企业的健康发展与其信息技术建设程度密切相关，企业的核心业务通常承载于BOSS（Business&Operation Support System，电信业务运营支撑系统）或CRM（Customer Relationship Management，客户关系管理）系统中，逐渐替代以纸质为媒介的传统业务办理模式。而中间件则是大型企业的IT业务系统的关键链路之一。 

以移动的BOSS系统为例，其中间件集群包括后台的tuxedo和前台的weblogic，其中后台tuxedo应用根据业务类型分成不同的域，每个用户域有上千个的服务进程。前台的weblogic应用根据业务需求部署在几十台主机上，有上百个服务端口。我们把从weblogic端口至tuxedo的服务调用过程路径称为中间件链路，链路上承载这些weblogci端口和tuxedo服务的主机就是中间件的链路设备。 

通常情况下，BOSS系统中运行大量实时性要求较高的业务，其特征是单次执行时间短，业务量也较大，分配给它运行的中间件链路通常有几条至几十条。若从终端用户的感知出发进行分析，高实时性业务如果结果返回时间在1-4秒是良好，4秒-10秒是勉强可以接受，如果超过10秒就比较难以容忍了。 

具体来说，在实现本发明的过程中，发明人发现现有的方案存在如下缺点： 

现有的业务系统中，中间件集群几十条链路相互独立，每个链路都可以接收客户端发出的需求与后端数据库等交互办理业务，当出现中间件的单链路故障时，只要中间件集群前端的负载均衡器仍能正常工作，将会把新的业 务请求分配至其他链路，不会使系统整体处于“全阻”的故障状态。 

但对于高实时性业务，上述工作模式存在如下不足： 

若中间件单链路退服且不能快速恢复，高实时性业务办理效率会相对降低，高峰期效率降低引起的请求排队若不能及时处理，可能在系统其它环节（数据库、中间件公共域）中形成累积效应，一段时间后导致故障扩大化。 

由于高实时性业务在中间件集群的链路众多，单链路宕机、阻塞等显性问题易被监控处理，但单链路的性能降低等问题则需要逐一对链路进行人工分析，排查和恢复需花费较长时间。 

若中间件链路处于“假死”状态，使前端负载均衡器认为该链路仍“在服”，则仍会将客户端新的业务请求发至该链路处理，使部分客户端感知到故障。 

发明内容

本发明的目的在于克服现有技术的缺点和不足，提供一种中间件业务故障处理方法及系统。 

一种中间件业务故障处理方法，所述方法包括： 

A、实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值； 

B、根据业务量和平均响应时间计算服务效率，筛选服务效率差的中间件链路； 

C、确定所述服务效率差的中间件链路的业务量和平均响应时间是否在所述响应时间和业务量的可信区间内，若是，执行步骤D，否则，重置所述中间件链路； 

D、确定所述服务效率差的中间件链路的业务量和平均响应时间是否偏离所述业务效率基线值，若是，重置所述中间件链路，否则，不作处理。 

所述计算响应时间和业务量的可信区间，包括： 

平均响应时间的可信区间： 

${\left|\right|T\left|\right|}_1=\underset{i=1}{\overset{n}{\mathrm{\Σ}}}\left|t_i\right|,T=\{t_1,t_2,...,t_n\},{\left|\right|T\left|\right|}_2=\sqrt{\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{\left(t_i\right)}^2},T=\{t_1,y_2,...,t_n\};$ 所述T为响应时间； 

业务量的可信区间： 

${\left|\right|S\left|\right|}_1=\underset{i=1}{\overset{n}{\mathrm{\Σ}}}\left|s_i\right|,S=\{s_1,s_2,...,s_n\},{\left|\right|S\left|\right|}_2=\sqrt{\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{\left(s_i\right)}^2},S=\{s_1,s_2,...,s_n\};$ 所述S为业务量。 

所述计算业务效率基线值，包括： 

业务响应时间为T，业务量为S，每天24小时分为24个时段，任意一个时段的平均响应时间均值为业务量均值为平均响应时间误差系数为 业务量误差系数为得到中间件服务效率的基线值： 

平均响应时间基线值=平均响应时间的均值*平均响应时间的误差系数

业务量的基线值=业务量的均值*业务量的误差系数

平均响应时间的均值计算公式： $\stackrel{\‾}{t}=\frac{1}{n}\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{t}_i;$ 误差系数：  $w_{\stackrel{\‾}{t}}=\sqrt{\frac{{\mathrm{\Σ}}_{i=1}^n{(t_i-\stackrel{\‾}{t})}^2}{n(n-1)}};$

业务量的均值计算公式： $\stackrel{\‾}{s}=\frac{1}{n}\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{s}_i;$ 误差系数： $w_{\stackrel{\‾}{s}}=\sqrt{\frac{{\mathrm{\Σ}}_{i=1}^n{(s_i-\stackrel{\‾}{s})}^2}{n(n-1)}};$

所述i的取值从0到23，每天24时段。 

所述方法还包括： 

当单个所述中间件链路上运行多个服务时，选择执行频率最高的服务来计算所述中间件链路的服务效率。 

所述业务效率基线值以小时为单位，计算一天24小时每个时段的均值； 

采集三个月数据，以其均值作为各时段基线值，所述基线值每个月根据上月数据更新一次。 

所述方法还包括： 

若连续三个探测周期，同一所述中间件链路均被选中重置，则所述中间件链路的问题无法通过重置解决，将所述中间件链路重置结果告警。 

一种中间件业务故障处理系统，所述系统包括计算单元、筛选单元、可信区间确认单元、基线值确认单元及重置单元，其中， 

所述计算单元，用于实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值； 

所述筛选单元，用于根据业务量和平均响应时间计算服务效率，筛选服 务效率差的中间件链路； 

所述可信区间确认单元，用于确定所述服务效率差的中间件链路的业务量和平均响应时间是否在所述响应时间和业务量的可信区间内； 

所述基线值确认单元，用于确定所述服务效率差的中间件链路的业务量和平均响应时间是否偏离所述业务效率基线值； 

所述重置单元，用于重置所述中间件链路。 

所述计算单元进一步包括采集子单元、响应时间计算子单元、业务量计算子单元及基线值计算子单元，其中， 

所述采集子单元，用于实时采集中间件链路实时性业务量及平均响应时间； 

所述响应时间计算子单元，用于计算响应时间的可信区间； 

所述业务量计算子单元，用于计算业务量的可信区间； 

所述基线值计算子单元，用于计算业务效率基线值。 

所述系统还包括告警单元，用于在连续三个探测周期内，同一所述中间件链路均被所述重置单元选中重置时，将所述中间件链路重置结果告警。 

本发明通过实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值；筛选出服务效率差的中间件链路；分别确定服务效率差的中间件链路的业务量和平均响应时间是否在响应时间和业务量的可信区间内，以及确定服务效率差的中间件链路的业务量和平均响应时间是否偏离业务效率基线值，根据确认结果重置中间件链路。与现有技术相比，本发明解决了在中间件集群中单链路问题引起的高实时性业务效率降低，人工查证耗时长、问题易扩大化等缺陷，从实际场景出发提升工作效率，降低风险。 

附图说明

图1为本发明实施例1提供的中间件业务故障处理方法原理流程图； 

图2为本发明实施例1提供的业务量排名示意图。 

图3为本发明实施例2提供的中间件业务故障处理系统结构示意图； 

图4为本发明实施例2提供的计算单元100结构示意图。 

具体实施方式

下面结合附图对本发明的具体实施方式进行详细描述。但本发明的实施方式不限于此。 

本发明各个实施例中，针对现有技术缺点，提出了一种简单易行的方法，实现对中间件集群中高实时性业务的单链路故障的快速定位和恢复，防止因单链路退服，导致高实时性业务性能降低，阻止问题扩大化的可能性，实现24小时不间断的业务服务。 

该方案通过实时收集监控中间件集群中高实时性业务的链路办理效率和交易量，利用一种算法周期性排序，筛选出可能的故障链路并自动重置weblogic端口和tuxedo服务，5-10秒即可恢复，可自动规避和处理偶发性的单链路异常，提升量较大、实时性要求较高的业务（如BOSS系统中的附加资费变更、前台公共查询、1008611话费查询）的运行稳定性。 

如图1所示，为本发明实施例1提供的上行干扰定位方法原理流程图，具体如下： 

步骤10，实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值。 

将高实时性业务的中间件链路常见故障进行分析，可将故障归结为两类，第一类是“显性”故障，如中间件所在主机宕机停服、中间件链路队列排满等，这类故障可以通过现有的监控快速发现并采取针对性措施予以解决。第二类是“隐性”故障，如中间件链路中的端口监控正常但不处理事务（处于“假死”状态）、weblogic或tuxedo软件服务自身异常导致处理效率降低、单个异常请求阻塞链路、外部接口返回数据慢导致排队严重等，这类故障则需要人工介入处理，而根据维护经验，重置链路的端口和服务，可以解决80%以上的“隐性”故障。 

无论是中间件链路的“显性”还是“隐性”问题，都会使得运行在其上的高实时性业务办理效率降低，因此要快速排查故障链路，关键是如何根据业务办理效率，及时地筛选出可能的故障链路并及时处理，使问题被遏制在萌芽状态，规避其产生累积效应，导致故障扩散。 

首先需要实时采集中间件链路高实时性业务量及平均响应时间，计算高实时性业务效率的基线值。通常来说，计算过程如下： 

在中间件主机上部署代理脚本，实时采集业务效率指标：业务量和平均响应时间； 

将效率指标传至后台服务器，以小时为单位，计算出一天24小时每个时段的均值； 

采集三个月数据，以其均值作为各时段基线值，该基线值每个月自动根据上月数据更新一次。 

设单链路业务响应时间为T，业务量为S，每天24小时就分为24个时段，任意一个时段的平均响应时间均值为业务量均值为平均响应时间误差系数为业务量误差系数为（i的取值从0到23）得到中间件服务效率的基线值： 

平均响应时间基线值=平均响应时间的均值*平均响应时间的误差系数

业务量的基线值=业务量的均值*业务量的误差系数

平均响应时间的均值计算公式： $\stackrel{\‾}{t}=\frac{1}{n}\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{t}_i;$ 误差系数：  $w_{\stackrel{\‾}{t}}=\sqrt{\frac{{\mathrm{\Σ}}_{i=1}^n{(t_i-\stackrel{\‾}{t})}^2}{n(n-1)}}.$

业务量的均值计算公式： $\stackrel{\‾}{s}=\frac{1}{n}\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{s}_i;$ 误差系数： $w_{\stackrel{\‾}{s}}=\sqrt{\frac{{\mathrm{\Σ}}_{i=1}^n{(s_i-\stackrel{\‾}{s})}^2}{n(n-1)}}.$

i的取值从0到23，每天24时段。 

另外，计算响应时间和业务量的可信区间。采集服务效率的原始数据放在后台服务器中分析处理，大部分数据都处于比较稳定的范围之内，这个范围以外的数据我们称其为效率差的数据。 

根据如下的范围，可以根据历史数据，分别计算出响应时间和业务量的可信区间的上、下线值，这个范围区间内，就是可信区间。 

平均响应时间的可信区间： 

${\left|\right|T\left|\right|}_1=\underset{i=1}{\overset{n}{\mathrm{\Σ}}}\left|t_i\right|,T=\{t_1,t_2,...,t_n\},{\left|\right|T\left|\right|}_2=\sqrt{\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{\left(t_i\right)}^2},T=\{t_1,y_2,...,t_n\};$ 所述T为响应时间； 

业务量的可信区间： 

${\left|\right|S\left|\right|}_1=\underset{i=1}{\overset{n}{\mathrm{\Σ}}}\left|s_i\right|,S=\{s_1,s_2,...,s_n\},{\left|\right|S\left|\right|}_2=\sqrt{\underset{i=1}{\overset{n}{\mathrm{\Σ}}}{\left(s_i\right)}^2},S=\{s_1,s_2,...,s_n\};$ 所述S为业务量。 

有了响应时间和业务量的可信区间以及业务效率基线值，就可以继续进行后续计算。 

步骤20，根据业务量和平均响应时间计算服务效率，筛选服务效率差的中间件链路。 

在后台服务器中根据每分钟办理业务量大小从高到低进行排序，放在队列中，筛选出业务量最低的中间件链路。本实施例中当单个链路上运行多个服务时，选择执行频率最高的服务来衡量链路设备能力。如图2所示，其中根据每分钟业务量排名，可以得到中间件链路的业务量排序。 

步骤30，确定服务效率差的中间件链路的业务量和平均响应时间是否在响应时间和业务量的可信区间内，若否，重置中间件链路。 

筛选出服务效率最差的中间件链路后，需通过比对后台服务器中保存的性能数据,然后及时处理：重置链路或者告警。采集服务效率的原始数据放在后台服务器中分析处理，大部分数据都处于比较稳定的范围之内，这个范围以外的数据我们称其为效率差的数据。 

如果服务效率指标在可信区间的范围之外，即认为该链路出现异常，需要重置链路；如果服务效率在可信区间范围之内，需再比对历史同期的基线值来确认是否存在异常。如果不在可信区间内，则需要重置中间件链路。 

步骤40，确定服务效率差的中间件链路的业务量和平均响应时间是否偏离业务效率基线值，若是，重置中间件链路。 

将实时采集到的中间件单链路当前业务响应时间T和业务量S与采集的历史数据作对比，可以得到是否偏离（大于）业务效率基线值，若是，说明业务量偏大或者响应时间偏长，需要重置中间件链路。 

实际上，如果业务量过大，重置中间件链路显然也无法解决问题，这个时候需要发布告警信息，以提醒维护人员。 

对于可信区间和基线值的判断通常是联合进行的，如下表1所示，为可能发生服务效率降低的场景，并且提供相对应的处理实施。 

表1 

为了提高处理速度，在每台中间件主机上部署采集和效率比对的进程，周期是每分钟一次。 

采集服务效率的原始数据放在后台服务器中分析处理，历史数据的可信区间、均值和误差系数等指标都需要每月更新一次。 

实际上，通过上述方案，将平均响应时间或业务量可能异常的链路定位后，即调用重置命令将该链路的端口进行重置或告警。 

若连续三个探测周期，同一链路均被选中重置，则证明该链路的问题无法通过重置解决，此时将重置结果告警，提醒维护人员人工干预。 

由于重置的设备选择逻辑链路中最小单位，即tuxedo的单个服务进程或者weblogic的一个端口，由于负载均衡的系统架构，重置过程中其他逻辑链路上的业务仍然可以正常有序地办理，受影响的只有已经出现异常的个别终端。 

以上述方法对高实时性业务的中间件链路进行维护管理，可及时、自动地解决80%以上的“隐性”软件故障，并可对其他重置无法解决的异常精确定位和告警，减少人工排查工作量。 

本实施例提供的方法，与日常维护主要对比差异如表2所示： 

表2 

本实施例在对在某移动计费中心进行BOSS核心系统管理和维护经验总结。经过长期对核心系统维护管理中不断改善管理体制，完善工作流程。总结出了一种行之有效的高实时性业务中间件链路管理方法，能够快速针对不同的业务链路进行优化，在充分利用资源的同时，时刻保障集群中所有链路处于正常工作状态，降低故障率。 

实际采用经验表明，该方案不仅切实可行，而且非常有效。而且由于结构清晰，部署简单，能够快速完成，减少了中间件链路瓶颈发生的几率，避免单点故障，对保障移动业务支撑中心的业务开展稳定和高效运行起到了关键的作用。 

如图3所示，为本发明实施例2提供的中间件业务故障处理系统结构示意图，该系统包括计算单元100、筛选单元200、可信区间确认单元300、基线值确认单元400及重置单元500，具体如下： 

计算单元100，用于实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值； 

筛选单元200，用于根据业务量和平均响应时间计算服务效率，筛选服务效率差的中间件链路； 

可信区间确认单元300，用于确定服务效率差的中间件链路的业务量和平均响应时间是否在响应时间和业务量的可信区间内； 

基线值确认单元400，用于确定服务效率差的中间件链路的业务量和平均响应时间是否偏离业务效率基线值； 

重置单元500，用于重置中间件链路。 

进一步的，该系统还包括告警单元600，用于在连续三个探测周期内，同一中间件链路均被重置单元500选中重置时，将中间件链路重置结果告警。 

进一步的，如图4所示，上述的计算单元100进一步包括采集子单元101、响应时间计算子单元102、业务量计算子单元103及基线值计算子单元104， 具体如下： 

采集子单元101，用于实时采集中间件链路实时性业务量及平均响应时间； 

响应时间计算子单元102，用于计算响应时间的可信区间； 

业务量计算子单元103，用于计算业务量的可信区间； 

基线值计算子单元104，用于计算业务效率基线值。 

需要说明的是：上述实施例提供的中间件业务故障处理系统在中间件业务故障处理时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的中间件业务故障处理系统与中间件业务故障处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。 

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。 

本发明各个实施例中，可以提升高实时性业务中间件链路的稳定可靠性，可及时、自动地消除80%以上的单链路性能降低、“假死”等“隐性”软件故障，而对无法通过重置解决的问题也无需人工分析即可快速定位，大大提高了链路维护的效率。避免高实时性业务的效率降低，高实时性业务因其执行时间短，执行量大，容易在效率降低后短时间内形成累积效应，影响系统其它环节，造成故障扩散。消除中间件维护工作“死角”，减少人工分析和查证问题工作量，解决以前靠监控和人工难以定位的“隐性”问题。方式实施科学，几乎无新成本增加。流程上更加灵活，可借鉴性强。其他中间件集群（如websphere等）也能够参考此方法快速简便的进行管理。 

综上，本发明通过实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值；筛选出服务效率差的中间件链路；分别确定服务效率差的中间件链路的业务量和平均响应时间是否在响应时间和业务量的可信区间内，以及确定服务效率差的中间件链路的业务量和平均响应时间是否偏离业务效率基线值，根据确认结果重置中间件链路。与现有技术相比，本发明解决了在中间件集群中单链路问题引起的高实时性业务效率降低，人工查证耗时长、问题易扩大化等缺陷，从实 际场景出发提升工作效率，降低风险。 

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。 

Claims (9)

1.一种中间件业务故障处理方法，其特征在于，所述方法包括： 

A、实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值； 

B、根据业务量和平均响应时间计算服务效率，筛选服务效率差的中间件链路； 

C、确定所述服务效率差的中间件链路的业务量和平均响应时间是否在所述响应时间和业务量的可信区间内，若是，执行步骤D，否则，重置所述中间件链路； 

D、确定所述服务效率差的中间件链路的业务量和平均响应时间是否偏离所述业务效率基线值，若是，重置所述中间件链路，否则，不作处理。 

2.如权利要求1所述的方法，其特征在于，所述计算响应时间和业务量的可信区间，包括： 

平均响应时间的可信区间： 

所述T为响应时间； 

业务量的可信区间： 

所述S为业务量。 

3.如权利要求1所述的方法，其特征在于，所述计算业务效率基线值，包括： 

业务响应时间为T，业务量为S，每天24小时分为24个时段，任意一个时段的平均响应时间均值为业务量均值为平均响应时间误差系数为 业务量误差系数为得到中间件服务效率的基线值： 

平均响应时间基线值=平均响应时间的均值*平均响应时间的误差系数

业务量的基线值=业务量的均值*业务量的误差系数

平均响应时间的均值计算公式：误差系数：

业务量的均值计算公式：误差系数：

所述i的取值从0到23，每天24时段。 

4.如权利要求1所述的方法，其特征在于，所述方法还包括： 

当单个所述中间件链路上运行多个服务时，选择执行频率最高的服务来计算所述中间件链路的服务效率。 

5.如权利要求1所述的方法，其特征在于，所述业务效率基线值以小时为单位，计算一天24小时每个时段的均值； 

采集三个月数据，以其均值作为各时段基线值，所述基线值每个月根据上月数据更新一次。 

6.如权利要求1所述的方法，其特征在于，所述方法还包括： 

若连续三个探测周期，同一所述中间件链路均被选中重置，则所述中间件链路的问题无法通过重置解决，将所述中间件链路重置结果告警。 

7.一种中间件业务故障处理系统，其特征在于，所述系统包括计算单元、筛选单元、可信区间确认单元、基线值确认单元及重置单元，其中， 

所述计算单元，用于实时采集中间件链路高实时性业务量及平均响应时间，分别计算响应时间和业务量的可信区间以及业务效率基线值； 

所述筛选单元，用于根据业务量和平均响应时间计算服务效率，筛选服务效率差的中间件链路； 

所述可信区间确认单元，用于确定所述服务效率差的中间件链路的业务量和平均响应时间是否在所述响应时间和业务量的可信区间内； 

所述基线值确认单元，用于确定所述服务效率差的中间件链路的业务量和平均响应时间是否偏离所述业务效率基线值； 

所述重置单元，用于重置所述中间件链路。 

8.如权利要求7所述的系统，其特征在于，所述计算单元进一步包括采集子单元、响应时间计算子单元、业务量计算子单元及基线值计算子单元，其中， 

所述采集子单元，用于实时采集中间件链路实时性业务量及平均响应时间； 

所述响应时间计算子单元，用于计算响应时间的可信区间； 

所述业务量计算子单元，用于计算业务量的可信区间； 

所述基线值计算子单元，用于计算业务效率基线值。 

9.如权利要求7所述的系统，其特征在于，所述系统还包括告警单元，用于在连续三个探测周期内，同一所述中间件链路均被所述重置单元选中重置时，将所述中间件链路重置结果告警。