CN102567006A - 应用业务的扩展方法、装置及系统 - Google Patents

Abstract

本发明提供了一种应用业务的扩展方法、装置及系统，其中，该方法包括：将各应用业务划分为多个功能域；根据接收的应用业务的业务类别，判断接收的应用业务与多个功能域的关系；根据判定得到的接收的应用业务与多个功能域的关系，动态调整接收的应用业务所属的功能域。本发明实现了新业务上线与其他日常业务的同时进行且互不影响，提升业务扩展的稳定性。

Description

应用业务的扩展方法、装置及系统

技术领域

本发明涉及业务支撑领域，具体涉及一种应用业务的扩展方法、装置及系统。

背景技术

一级BOSS(即ONEBOSS)是全国中心建设高速的信息交互平台，实现帐务枢纽、客服枢纽、鉴权枢纽功能和全国业务数据管理，并初步实现BOSS系统全网的信息共享，带动全网支撑系统服务的提升。目前的系统有很高的耦合性，上线一个新业务时必须重启整个系统来达到新程序的生效和业务逻辑处理要求，导致其他业务的中断；同时在ONEBOSS上有多种业务平台，如果一种业务平台有问题就会导致所有业务无法正常进行，造成业务的不连续性，不能适应快速业务推广的需求；此外，在日常维护时也需要重启整个系统，。上述各种情况说明了现有BOSS在业务扩展及维护时的稳定性较低。

发明内容

本发明的第一目的是提出一种稳定的应用业务的扩展方法。

本发明的第二目的是提出一种稳定的应用业务的扩展装置。

本发明的第三目的是提出一种稳定的应用业务的扩展系统。

为实现上述第一目的，本发明提供了一种应用业务的扩展方法，包括：将各应用业务划分为多个功能域；根据接收的应用业务的业务类别，判断接收的应用业务与多个功能域的关系；根据判定得到的接收的应用业务与多个功能域的关系，动态调整接收的应用业务所属的功能域。

为实现上述第二目的，本发明提供了一种应用业务的扩展装置，包括：第一处理模块，用于将各应用业务划分为多个功能域；第二处理模块，用于根据接收的应用业务的业务类别，判断接收的应用业务与多个功能域的关系；调整模块，用于根据判定得到的接收的应用业务与多个功能域的关系，动态调整接收的应用业务所属的功能域。

为实现上述第三目的，本发明提供了一种应用业务的扩展系统，包括：主机及备机，主机及备机中均包括应用业务的扩展装置，应用业务的扩展装置将各应用业务划分为多个功能域；根据接收的应用业务的业务类别，判断接收的应用业务与多个功能域的关系；根据判定得到的接收的应用业务与多个功能域的关系，动态调整接收的应用业务所属的功能域。

本发明各个实施例中，通过将各应用业务分为对应的各类功能域，在接收的应用业务不属于已有功能域时，动态加载其功能域，不影响在线业务的作业，实现了新业务上线与其他日常业务的同时进行且互不影响，提升业务扩展的稳定性。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一并用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明的应用业务的扩展方法的实施例一流程图；

图2为本发明的应用业务的扩展方法的实施例二流程图；

图3为本发明的应用业务的扩展方法的实施例三流程图；

图4为本发明的应用业务的扩展装置的实施例结构图；

图5为本发明的应用业务的扩展系统的实施例结构图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

方法实施例

图1为本发明的应用业务的扩展方法的实施例一流程图。如图1所示，本实施例包括：

步骤102：将各应用业务划分为多个功能域；

步骤104：根据接收的应用业务的业务类别，判断接收的应用业务与多个功能域的关系；

步骤106：根据判定得到的接收的应用业务与多个功能域的关系，动态调整接收的应用业务所属的功能域。

本实施例通过将各应用业务分为对应的各类功能域，在接收的应用业务不属于已有功能域时，动态加载其功能域，不影响在线业务的作业，实现了新业务上线与其他日常业务的同时进行且互不影响，提升业务扩展的稳定性。

图2为本发明的应用业务的扩展方法的实施例二流程图。如图2所示，包括：

步骤200，转换器接收到业务的交易代码(即业务类别)；该转换器设置在BOSS系统中。转化器主要包含两个部分，第一部分是将BOSS系统的应用业务划分为基础功能域，一级客服功能域和集团业务功能域等多个一级功能域；转化器的第二部分是对于每个交易在处理业务逻辑之前，判断业务交易代码是否能归入到现有一级功能域，若新增交易归属于已有一级功能域时，根据每个交易的业务类别转发到对应归属的一级功能域同时在对应子域中添加该业务交易代码，进行后续业务逻辑处理；若新增交易不归属已有功能域中的任何一个一级功能域时，在转换器中添加对应一级功能域，同时添加其一级功能域的子域代码，这样热启动转换器就可以完成业务分发到不同功能域的工作，这样既不影响原有业务正常处理，也可以保证了特殊业务的特殊处理，从而达到全网业务的不间断性，完整性；

该转化器原理为：

transmit_name＝CUST|BBOSS|CALLCENTER|BADINFO|/*建立一级功能域*/

CALLCENTER_URL＝http://10.110.132.58/csp/pbh/provServiceProvider.action/*某一级功能域投递地址*/

CALLCENTER_TRANS_CONFIG＝BIP2C004|BIP2C005|BIP2C012|/*建立子功能域*/

具体见本实施例以下各步骤的解释说明；

步骤202，当转换器接收到业务代码时，首先判断是否适用于目前的一级功能域，若不属于已有的任何一个一级功能域或者交易返回慢，则对应表示遇到新功能类交易或障碍交易，新增功能域或者将障碍交易单独放置单独域，保证功能域的健康性和可规划性，其中具体新增功能域的操作参见如下转化器原理实例，执行步骤204；若属于已有的任一交易功能域，则无需改变域，执行步骤208；

具体实例如：新增全网客服投诉工单传递业务，需将交易传递到客服系统中，这时需要添加客服系统对应投递地址，及全网客服投诉工单传递的一级功能域，同时添加归属其子域的交易代码；当系统运行中发现某个一级功能域存在处理超时等待状态时，为避免产生对整个系统的拥塞，而将产生异常的交易代码从一级功能域和归属的子域中转移到新建一级功能域及其子域中让交易暂时处于丢弃状态，保障整个系统的交易稳定；

步骤204：更改转换器配置，动态调整一级功能域及其子域的业务代码归属情况，系统根据业务代码判断一级功能域归属，转发交易，动态实现写入系统文件，为热启动准备必要入口文件；实例承接以上转化器实例，具体实现如下：

应用读取转化器

MyLog.debugLog(″http协议转发″)；

                    MyLog.debugLog(″属于″+transmit_name+″交易，BIPCODE＝[″+bipCode+″]，直接转交给″+transmit_name+″系统″)；

                    TraderAgent trader＝new TraderAgent()；

                    MyLog.debugLog(transmit_name+″系统URL＝[″+transmit_url+″]″)；

                    retStr＝trader.postCommCust(″″，transmit_url，xmlReqName，xmlData)；

                    MyLog.debugLog(transmit_name+″返回应答报文＝[″+retStr+″]″)；

步骤206，加载转化器，该步骤主要使用热启动方法热更新配置文件，主要原理是将需要更新的数据按规定规则放置到定义的模式，并执行步骤212；

实例如下：热加载配置文件是使用java.io从磁盘文件读入信息到自定义MAP中，程序动态读取MAP，并将对热启动实现页面化修改操作，加载实时更新配置；

MAP定义过程：

步骤208，进行业务逻辑判断，执行到步骤210；

步骤210，根据现有的业务逻辑情况和业务变更情况判断是否修改程序，如业务逻辑发生变动交易代码不变，这时需要修改程序是执行步骤212，反之，执行步骤216；

步骤212，承接加载转化器实例，动态更新配置文件，重新读取入口文件配置，将动态划分后的结果读入到内存完成热启动；同时将处理逻辑程序按逻辑调用功能划分为多级别，实现最大限度热部署应用程序；实例如下：如果想高效的支撑业务开展，单纯的靠代发开发不是一个好方法，尽可能多的利用配置文件，实现业务的可配置性，配置文件的在线加载就成为一个瓶颈，同时java虚拟机加载class文件的顺序是先加载classpath，再加载具体应用的路径；目前的系统框架中业务处理主要由EJB处理的，由于EJB的特性，在EJB中需要的class等都可以在jar包找到，也可以更新jar包中的内容从而更新程序，但由于启动脚本中将应用目录设置成classpath，而现在程序上线时将EJBjar包中用到的class存放在了classpath中使得java虚拟机在加载class的时候并没有加载EJBjar中的class而是加载了classpath中的class，使得EJB在更新class的时候必须更新classpath中的class这就导致了weblogic需要重启；

改造之初需要将新增的class不更新到classpath中，新增的EJB时须将新增class打入jar包，逐步清理classpath中只保留基本class，达到改变单个业务逻辑时不影响其他业务；

步骤214，在线处理，利用主备机可以随时切换特性，在线更换程序，甚至可以重启系统而对在线交易不产生任何影响，同时执行步骤216；

步骤216，程序处理，实现具体逻辑处理，如缴费业务具体处理过程，处理结束，执行步骤218

步骤218，数据处理；将程序处理结果记录到数据库中，到此位置，一个交易完成。

图3为本发明的应用业务的扩展方法的实施例二流程图。本实施例是建立在BOSS系统中的主机服务器中的各功能块与备机服务器中每一功能块分别相连的基础上，且预先设定主机中weblogic1的监听端口存在时优先级高于备机中weblogic2。如图3所示，包括：

步骤300，交易发起方将交易首先投递到四层交换机上；

步骤302，四层交换机监测weblogic的健康情况和数据库连接健康情况；

步骤304，四层交互根据预先设置的主机及备机的优先级分发交易，在本实施例中，对weblogic1的级别进行判断，具体如：利用weblogic1后台参数实时获取数据库连接数、队列连接数等参数情况，根据实际需要设立应用级别监控，若weblogic1满足要求时，执行步骤306；若应用级别达到设定阀值时切换到步骤314中，如当产生宕机类系统级别的错误时自动切换链路，或者在判定weblogic1的队列数和连接池等性能参数不符合阀值设定时自动切换到互补链路；

步骤306，weblogic1接收交易，首先进行操作流水记录，同时分析交易情况，执行步骤308；

步骤308，weblogic1是否需要调整转化器或进行热加载配置文件、程序，如需要执行图二步骤，调整完毕后执行步骤310；

步骤310：判断tuxedo1的级别，具体如判断tuxedo1连接是否在规定时间内正常反馈，当超过规定时间时，执行步骤320，实现自动切换到互补链路，保证交易正常完成；

本领域技术人员可以理解，步骤314-318分别与步骤306-310对称，不再赘述；在步骤310之后执行步骤312，tuxedo1与数据库进行交互完成交易；在步骤318之后执行步骤320，tuxedo2与数据库进行交互完成交易。

本实施例通过，主机的每一功能块与备机的所有功能块分别相连，在当前处理链路出现故障时直接切换至互补链路，解决了主备系统间消息传递问题及系统切换的问题，保证业务的连续性。

装置实施例

图4为本发明的应用业务的扩展装置的实施例结构图。图1-3所示的各方法实施例均可应用于本实施例。本实施例包括：第一处理模块40，用于将各应用业务划分为多个功能域；第二处理模块42，用于根据接收的应用业务的业务类别，判断接收的应用业务与多个功能域的关系；调整模块44，用于根据判定得到的接收的应用业务与多个功能域的关系，动态调整接收的应用业务所属的功能域。

具体操作时，该应用业务的扩展装置还可以包括：第三处理模块46，用于根据预设的功能域与配置文件的对应关系，热更新与所属的功能域相适配的配置文件；根据预设的功能域与应用程序的对应关系，热部署与所属的功能域相适配的应用程序。

调整模块44可以包括：

第一调整子模块442，用于在判定得到的接收的应用业务与多个功能域的关系为接收的应用业务不属于多个功能域中的任一种时，添加接收的应用业务的业务代码，并热启动业务代码，形成接收的应用业务所属的功能域；

第二调整子模块444，用于在判定得到的接收的应用业务与多个功能域的关系为接收的应用业务属于多个功能域中的一种时，将接收的应用业务动态归属到对应的功能域。

本领域技术人员可以理解该应用业务的扩展装置设置在BOSS系统中。

本实施通过将各应用业务分为对应的各类功能域，在接收的应用业务不属于已有功能域时，动态加载其功能域，不影响在线业务的作业，实现了新业务上线与其他日常业务的同时进行且互不影响，提升业务扩展的稳定性。

系统实施例

图5为本发明的应用业务的扩展系统的实施例结构图。图1-3所示的各方法实施例均可应用于本实施例。本实施例包括：主机及备机，主机及备机中均包括应用业务的扩展装置(图未示)，应用业务的扩展装置将各应用业务划分为多个功能域；根据接收的应用业务的业务类别，判断接收的应用业务与多个功能域的关系；根据判定得到的接收的应用业务与多个功能域的关系，动态调整接收的应用业务所属的功能域。本领域技术人员可以理解该主机及备机均为BOSS系统。

优选地，主机中的每一功能块与备机中的所有功能块分别相连。具体如：主备系统中的数据库连接也采用互备方式，设置不同的数据库连接优先级，调整后产生四条可用链路，同时在线备用两个数据库结点，日常维护过程中利用自制上线工具便捷备份应用程序，保障当主链路发生问题时，可以自由切换其他三路链路中。

本实施例通过实现全网业务受理的不间断支撑，实现了在新业务上线时日常运维的稳定性，即日常维护和新业务加载的不冲突受理，具体地，转换器实现了动态划分功能域及域内涵盖交易，对后期的规划和调整留有发展余地，保证了特殊业务的特殊处理，同时还实现了在线部署配置文件和更新程序；优选地，当系统产生异常时半自动化的切换可用链路，进一步提高稳定性。

最后应说明的是：以上仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种应用业务的扩展方法，其特征在于，包括：

将各应用业务划分为多个功能域；

根据接收的应用业务的业务类别，判断所述接收的应用业务与所述多个功能域的关系；

根据判定得到的所述接收的应用业务与所述多个功能域的关系，动态调整所述接收的应用业务所属的功能域。

2.根据权利要求1所述的应用业务的扩展方法，其特征在于，所述根据判定得到的所述接收的应用业务与所述多个功能域的关系，动态调整所述接收的应用业务所属的功能域的步骤包括：

在所述判定得到的所述接收的应用业务与所述多个功能域的关系为所述接收的应用业务不属于所述多个功能域中的任一种时，添加所述接收的应用业务的业务代码，并热启动所述业务代码，形成所述接收的应用业务所属的功能域；

在所述判定得到的所述接收的应用业务与所述多个功能域的关系为所述接收的应用业务属于所述多个功能域中的一种时，将所述接收的应用业务动态归属到对应的功能域。

3.根据权利要求2所述的应用业务的扩展方法，其特征在于，在所述热启动所述业务代码的步骤之后还包括：

根据预设的功能域与配置文件的对应关系，热更新与所述所属的功能域相适配的配置文件。

4.根据权利要求3所述的应用业务的扩展方法，其特征在于，在所述热更新与所述所属的功能域相适配的配置文件的步骤之后还包括：

根据预设的功能域与应用程序的对应关系，热部署与所述所属的功能域相适配的应用程序。

5.根据上述权利要求1-4中任一项所述的应用业务的扩展方法，其特征在于，在处理所述接收的应用业务时还包括：

在当前进行处理操作的主机的第一功能块出现故障时，切换至备机中与所述第一功能块对应的功能块；或者

在当前进行处理操作的所述备机的第二功能块出现故障时，切换至所述主机中与所述第二功能块对应的功能块，其中，所述主机及备机均为BOSS系统。

6.一种应用业务的扩展装置，其特征在于，包括：

第一处理模块，用于将各应用业务划分为多个功能域；

第二处理模块，用于根据接收的应用业务的业务类别，判断所述接收的应用业务与所述多个功能域的关系；

调整模块，用于根据判定得到的所述接收的应用业务与所述多个功能域的关系，动态调整所述接收的应用业务所属的功能域。

7.根据权利要求6所述的应用业务的扩展装置，其特征在于，所述调整模块包括：

第一调整子模块，用于在所述判定得到的所述接收的应用业务与所述多个功能域的关系为所述接收的应用业务不属于所述多个功能域中的任一种时，添加所述接收的应用业务的业务代码，并热启动所述业务代码，形成所述接收的应用业务所属的功能域；

第二调整子模块，用于在所述判定得到的所述接收的应用业务与所述多个功能域的关系为所述接收的应用业务属于所述多个功能域中的一种时，将所述接收的应用业务动态归属到对应的功能域。

8.根据权利要求7所述的应用业务的扩展装置，其特征在于，还包括：

第三处理模块，用于根据预设的功能域与配置文件的对应关系，热更新与所述所属的功能域相适配的配置文件；根据预设的功能域与应用程序的对应关系，热部署与所述所属的功能域相适配的应用程序。

9.根据上述权利要求6-8中任一项所述的应用业务的扩展装置，其特征在于，其设置在BOSS系统中。

10.一种应用业务的扩展系统，其特征在于，包括：

主机及备机，所述主机及备机中均包括应用业务的扩展装置，所述应用业务的扩展装置将各应用业务划分为多个功能域；根据接收的应用业务的业务类别，判断所述接收的应用业务与所述多个功能域的关系；根据判定得到的所述接收的应用业务与所述多个功能域的关系，动态调整所述接收的应用业务所属的功能域。

11.根据权利要求10所述的应用业务的扩展系统，其特征在于，所述主机中的每一功能块与所述备机中的所有功能块分别相连。

Images