一种用于业务支撑系统的业务处理方法及系统

摘要

本发明公开了一种用于业务支撑系统的业务处理方法及系统。其中用于业务支撑系统的业务处理方法包括：根据业务支撑系统中业务的用户感知度特征值将所述业务划分为不同类别；并为不同类别的业务配置不同的处理策略；根据业务支撑系统中现有业务的用户感知度特征值对现有业务进行归类，并按照类别对应的处理策略对现有业务进行部署。本发明的用于业务支撑系统的业务处理方法及系统，通过根据用户感知度对业务进行分类，针对不同类别的业务采用不同的处理策略，有效地利用系统资源，解决了在有限的系统资源上不断提升业务服务质量的问题，使得系统的运行压力得到极大的缓解，提高业务服务质量及业务支撑系统的客户感知度。

说明书

技术领域

本发明涉及一种业务支撑技术，尤其涉及一种用于业务支撑系统的业务处理方法及系统。

背景技术

业务支撑系统是各大电信运营商提供全网业务运营的支撑系统，在中国移动通信集团公司的规范定义中，该类系统称为业务操作支撑系统(Business& Operation Support System，简称BOSS)，BOSS系统的功能架构最基本的配置为：客户服务系统、计费系统、结算系统。发展到今天的一体化的业务支撑，功能范围包含了数据采集、计费处理、网间结算、客户服务、业务管理、综合账务、系统监控、联机指令、资源管理、BOSS网管和数据挖掘各个方面。说明业务支撑系统的功能范围越发趋于全面化，从业务的性能特征上来分，业务支撑系统从以往的实时交易类型的业务发展成为结合实时交易类型和分析挖掘类型的混合型业务。业务的服务质量主要体现在以下三个方面：业务的完整性，业务的正确性及业务的运行效率。

因此，为了在不断扩张的业务需求下，保障业务的服务质量，目前现有的系统部署调整方式包括：

1、系统扩容法，通过系统层面计算目前的系统负载能力，按照业务扩张的速度计算出未来一定时间范围内系统能需要达到的负荷的系统配置，采取增加服务器CPU、扩展内存、增加服务器、扩容存储等方法，按照尽量满足需求扩展速度的前提下，保障业务的服务质量；

2、服务拆分法，基于中间件驱动的API技术的应用部署方式下，为保障业务的服务质量，增加中间件的服务队列，或者按照执行效率快慢简单分离出效率较低的服务队列。在WEB SERVICE驱动技术的应用部署方式下，采用增加JDBC连接池等方法保障WEB服务队列的无阻塞调用。

但是，现有的两类应用部署技术存在如下缺陷：

1、系统扩容法：

不断对系统硬件配置进行扩容，增加了系统运行的硬件成本。业务的增长，除了新业务的上线外，还有已有业务的使用率提升，因此硬件的扩容规模呈非线性增长，扩容比例远高于业务增长比例；为系统的稳定运行与维护工作带来了巨大的困难。

2、服务拆分法：

对服务队列的调整，是以服务为单位的业务的运行效率高低为判断标准，而业务服务质量的高低并不仅限于中间件服务队列的运行效率。由于业务的服务质量的要求是以业务的服务要求为导向，而对于服务质量要求中要求快速响应的业务，对应中间件服务无法达到响应要求，被简单扩展队列或者隔离到其他队列的方式，并不能解决业务的服务质量降低的问题。

发明内容

本发明的目的在于，提供一种用于业务支撑系统的业务处理方法及系统，能够有效地利用系统资源，缓解系统压力，提高业务的服务质量。

为实现上述目的，根据本发明的一个方面，提供一种用于业务支撑系统的业务处理方法，包括：根据业务支撑系统中业务的用户感知度特征值将所述业务划分为不同类别；并为所述不同类别的业务配置不同的处理策略；根据业务支撑系统中现有业务的用户感知度特征值对所述现有业务进行归类，并按照所述类别对应的处理策略对所述现有业务进行部署。

为实现上述目的，根据本发明的另一个方面，提供一种用于业务支撑系统的业务处理系统，包括：存储装置，用于存储根据业务支撑系统中业务的用户感知度特征值将所述业务划分的不同类别以及所述不同类别的业务对应的处理策略；分类装置，用于根据业务支撑系统中现有业务的用户感知度特征值对所述现有业务进行归类；部署装置，用于根据所述现有业务所在类别对应的处理策略对所述现有业务进行部署。

本发明的用于业务支撑系统的业务处理方法及系统，通过根据用户感知度对业务进行分类，针对不同类别的业务采用不同的处理策略，有效地利用系统资源，弥补了现有的应用部署技术只能以简单扩容来满足业务发展需求的不足，同时解决了在有限的系统资源上不断提升业务服务质量的问题，使得系统(包括数据库层面和应用层面)的运行压力得到极大的缓解，提高业务服务质量及业务支撑系统的客户感知度。

附图说明

图1是本发明用于业务支撑系统的业务处理方法实施例流程图；

图2是本发明业务响应速度和时效性二维矩阵示意图；

图3是本发明用于业务支撑系统的业务处理系统实施例结构图。

具体实施方式

以下结合附图对本发明进行详细说明。

方法实施例

如图1所示，本发明用于业务支撑系统的业务处理方法实施例包括如下步骤：

步骤102，根据业务支撑系统中业务的用户感知度特征值将所述业务划分为不同类别；

步骤104，为不同类别的业务配置不同的处理策略；

步骤106，根据业务支撑系统中现有业务的用户感知度特征值对现有业务进行归类；

步骤108，按照现有业务所属类别对应的处理策略对现有业务进行部署。

业务支撑系统中业务的服务质量主要概括为以下三个方面：业务的完整性，业务的准确性及业务的运行效率，反应为业务的时效性、时间跨度、返回结果的数量级以及响应时间等客户感知度特征，因此，本实施例中，用户感知度特征值包括：业务响应速度和时效性；

步骤102中，将业务划分为不同类别的具体操作包括：

(1)根据业务的响应速度和时效性建立二维矩阵；

(2)计算分类用的响应速度界定值和时效性界定值；

a、响应速度界定值计算方法如下：

对业务的历史运行数据进行抽样，应用抽样数据于正态分布的概率统计模型中，计算出现有交互类业务比例下的响应时间上限，

例如：取样湖北移动BOSS现网运行的三天(任意月份取月头、月中和月末三天)的业务响应时间及业务名称的数据。例如：

  序号  业务名称  响应时间(秒)  1  缴费1  2.80  2  缴费2  1.79  3  综合查询  1.02  4  日志查询  0.35

X～N(μ，σ²)，响应时间X服从正态分布；其中μ代表样本的平均响应时间，描述样本的位置参数；σ代表样本响应时间的标准差，描述样本的离散程度。P代表“现有交互类业务的比例”，响应速度界定值t的计算公式如下：

$P(X\le t)=P(\frac{X-\mu }{\sigma }\le \frac{t-\mu }{\sigma })=\phi \left(\frac{t-\mu }{\sigma }\right)$

例如：BOSS3.0的样本数据计算出来的

μ＝0.1653，σ＝108.99，P＝0.95，即样本中响应时间的平均值为0.1653秒，样本的标准差为108.99，需要计算出占整体样本概率为95％的响应时间：则，$\phi \left(\frac{t-\mu }{\sigma }\right)=0.95,$查询标准正态分布表得：$\frac{t-\mu }{\sigma }=1.65,$因此t＝180。

即，当响应速度在低于t的时候的业务被界定为低响应速度，高于t的时候的业务为高响应速度；

b、时效性界定值计算方法如下：

根据各类交互类业务的服务结果要求，来判断需要获取系统实时或准实时数据，目前定义实时或准实时以h小时为界定线，根据目前湖北移动的系统负载能力，主用中心和备用中心数据复制的周期受主用中心系统负载能力的限制，系统负载能力越高则能允许的同步周期越小，即h越小，

h＝max(主用中心的最后业务发生时间-备用中心最后业务发生时间)；

例如：湖北移动目前的h＝24小时；

即：业务交互时，根据所需提取数据是当日最新数据或各日历史数据来区分实时或准实时，如下业务的时效性要求：

  序号  业务名称  服务结果要求  时效性  1  缴费  查询用户最新账户费用情况  实时  2  开户  即时开通  实时  3  操作员工作日志查询  对某一节点下的工作量进行审核  准实时  4  E动商网  即时查询、兑换  实时 5  商品销售月报  进行按月的统计，统计时间不定  准实时

响应时间和时效性界定值的高低受系统负载能力的影响：负载能力越高则系统中业务的响应时间越小，响应时间高低的界定值越低。时效性的界定值越低，即主用中心和备用中心的数据单向复制的周期越短，对系统负载能力的要求就越高。例如要求更高配置的存储设备，更高速的磁盘读写效率等等。

(3)根据所述响应速度界定值和时效性界定值将所述二维矩阵划分为若干区域，每个区域中的个业务对应为不同类别，

如图2所示，本实施例中，将该二维矩阵划分为四个区域，即将业务划分为四个类别，分别是：

A区：高时效性、低响应速度，此类业务涉及到在多个数据库的分布式事务，并且总体事务的成功依赖于每一步的事务或者查询的结果是否成功；还需要前台操作人员的信息录入，由于涉及到的步骤较多，整体业务的用时较长，同时由于属于事务操作，时效性要求是在线最新的数据，所以时效性要求高；

B区：高时效性、高响应速度，此类业务多为简单事务性交易，比如缴费，开机，密码修改等，这些操作简单，数据量操作小，响应速度均要求在秒级完成，所以响应速度和实效性要求都高；

C区：低时效性、低响应速度，此类业务多为营业后台数据查询类，比如营业报表统计，装机报表统计等，此类业务面向支撑和经营分析系统，查询范围和时间不固定，是查询距离在线有一段时间间隔的统计，比如对一个月/周/天前的数据的统计，而且通常被允许在较长的一段时间内完成(数十分钟或数个小时)，同时此类业务多涉及到单一的数据库数据，所以响应速度和时效性都比较低；

D区：低时效性、高响应速度，此类业务多为前台营业员相关统计，比如操作员查询日志，退费业务查询等，此类处理一般对一天或数天前的查询，或者涉及到多个业务逻辑，需要从不同的数据库获取数据，但营业员通常需要等待结果才能进行后续处理，所以时效性不高，响应速度要求高。

步骤104中，不同类别业务的处理策略如下：

对于高时效性、低响应速度的业务，其处理策略为调用在线专用慢响应速度的中间件服务；

对于高时效性、高响应速度的业务，其处理策略为调用在线系统实时快速响应的中间件服务；

对于低时效性、低响应速度的业务，其处理策略为调用历史库或者双中心中备用中心的JDBC应用；

对于低时效性、高响应速度的业务，其处理策略为调用历史库或者双中心中备用中心的中间件服务。

其中，历史库用于存放非当前帐期的历史交易数据，数据源同在线库不重复，区别于同步复制数据的双中心。例如：湖北移动的历史库用于存放12个月前的营业厅业务受理日至的相关数据，而此批数据在线不保存。

双中心是一种采用主用中心和备用中心的容灾建设方式。本实施例中，C区和D区的处理策略均利用双中心的备用中心，配置新的JDBC连接链路、中间件服务组或异步的数据处理进程等方式实现部署。此类处理策略直接利用系统现有的硬件资源，未添加新的设备投入，从而节约大量的硬件投资，同时达到分担主用在线系统运行压力的目的。

对于低实效性的业务，调用历史库或双中心中备用中心的JDBC应用、中间件服务，直接利用系统现有的硬件资源分担了主用在线系统运行压力，不影响对高时效性业务的处理，使得系统(包括数据库层面和应用层面)的运行压力得到极大的缓解，提高业务服务质量及业务支撑系统的客户感知度。

步骤108中，根据现有业务所属类别对应的处理策略对现有业务进行部署时，当所述现有业务的当前类别与原有类别不同时，按照当前类别对应的处理策略对所述现有业务进行部署，当前类别反映了现有业务当前的服务质量，因此，需要将该业务移植到当前类别所需的硬件设备上进行处理，

例如：

从B区到D区：配置新的服务组，直接调用双中心；

从B区到A区：移植到在线专用慢响应速度的中间件服务；

从A区到C区：配置调用历史库或者双中心中备用中心的JDBC应用。

如果在建模前系统均默认所有的业务处于高时效性的范围内，部署区间局限在A区或者B区。另外，业务移植的目标区域需要根据时效性和响应速度两个维度取值的高低综合判断，但至少保证现有业务的当前类别与原有类别中的其中一个用户感知度特征值相同，而不会出现交叉移植的情况，使得业务的时效性和运行速度不会同时受到影响，业务处理稳定。

本实施例的用于业务支撑系统的业务处理方法，通过根据用户感知度对业务进行分类，针对不同类别的业务采用不同的处理策略，有效地利用系统资源，弥补了现有的应用部署技术只能以简单扩容来满足业务发展需求的不足，同时解决了在有限的系统资源上不断提升业务服务质量的问题，使得系统(包括数据库层面和应用层面)的运行压力得到极大的缓解，提高业务服务质量及业务支撑系统的客户感知度。

系统实施例

如图3所示，本发明的用于业务支撑系统的业务处理系统实施例包括：

存储装置302，用于存储根据业务支撑系统中业务的用户感知度特征值将所述业务划分的不同类别以及所述不同类别的业务对应的处理策略；

分类装置304，用于根据业务支撑系统中现有业务的用户感知度特征值对所述现有业务进行归类；

部署装置306，用于根据所述现有业务所在类别对应的处理策略对所述现有业务进行部署。

本实施例的业务处理系统还包括：矩阵生成装置308，用于根据业务响应速度和时效性建立二维矩阵；界定值计算装置310，用于计算响应速度界定值和时效性界定值；分类装置304，用于根据响应速度界定值和时效性界定值将二维矩阵划分为若干区域，每个区域中的业务对应为不同类别。响应速度界定值和时效性界定值的具体计算方法以及分类方式在上述方法实施例中已详细说明，在此不再赘述。

本实施例中，分类装置304，当现有业务的当前类别与原有类别不同时，使得现有业务的当前类别与原有类别中的其中一个用户感知度特征值相同。

本实施例的业务处理系统，在业务支撑系统中，通过根据用户感知度对业务进行分类，针对不同类别的业务采用不同的处理策略，有效地利用系统资源，弥补了现有的应用部署技术只能以简单扩容来满足业务发展需求的不足，同时解决了在有限的系统资源上不断提升业务服务质量的问题，使得系统(包括数据库层面和应用层面)的运行压力得到极大的缓解，提高业务服务质量及业务支撑系统的客户感知度。

应说明的是：以上实施例仅用以说明本发明而非限制，本发明也并不仅限于上述举例，一切不脱离本发明的精神和范围的技术方案及其改进，其均应涵盖在本发明的权利要求范围中。