企业服务总线系统、数据处理方法、终端及存储介质与流程

本发明涉及计算机技术领域，具体涉及一种重模式企业服务总线系统、重模式企业服务总线数据处理方法、终端及存储介质。

背景技术：

随着计算机信息系统的发展，信息系统也越来越庞大、越来越复杂。在连接对象比较多的情况时，点对点的连接方式成本高，可用性和可维护性低，因而，总线的概念随之被引入到信息系统的架构建设上。跟随面向服务架构(serviceorientedarchitecture，soa)的概念，信息系统的总线通常叫服务总线。其战略层的总线称之为企业服务总线(enterpriseservicebus，esb)。企业服务总线是一个具有标准接口、实现了互连、通信、服务路由、支持实现soa的企业级信息系统基础平台。

在一些选择重模式(自营模式)的企业中，因涉及到中间环节足够多，控制力强，但若想将每个环节都做好，其运转成本非常高，因而有必要建立一种企业服务总线的架构，减低企业运营成本、管理成本。

技术实现要素：

鉴于以上内容，有必要提出一种重模式企业服务总线系统、重模式企业服务总线数据处理方法、终端及存储介质，能够将不同的数据请求的请求方发送的数据请求转换成统一的报文和请求协议，并实现了同步处理机制转成异步处理机制的功能。

本发明的第一方面提供一种企业服务总线系统，所述企业服务总线系统通讯连接多个企业系统和多个第三方系统，所述企业服务总线系统包括：esb-api子系统、kafka子系统、esb-consumer子系统、esb-proxy-in子系统、esb-proxy-out子系统、esb-file-proxy-out子系统，所述kafka子系统分别与所述esb-api子系统及所述esb-consumer子系统通讯连接，所述esb-api子系统与所述esb-proxy-in子系统通讯连接，所述esb-consumer子系统分别与所述esb-proxy-out子系统及所述esb-file-proxy-out子系统通讯连接，其中，

所述esb-api子系统用于发布dubbo服务协议，所述esb-proxy-in子系统用于发布http服务协议和https服务协议；

所述esb-api子系统还用于将所述企业服务总线系统封装后的消息由所述esb-api子系统中的消息生产者将消息发送至所述kafka子系统；

所述kafka子系统用于接收到所述esb-api子系统发送的待处理的消息时，根据所述待处理的消息配置相应的消息队列，并对所述待处理的消息进行处理；

所述esb-consumer子系统用于每隔预设时间段从所述kafka子系统的消息队列中拉取所述待处理的消息，根据所述待处理的消息创建相应的线程；

所述esb-consumer子系统用于对所述待处理的消息进行解析，并将解析后的内容发送至所述数据请求对应的服务方；

所述esb-consumer子系统还用于获取所述数据请求的服务方发送的请求结果并将所述请求结果暂存至所述kafka子系统的消息队列中；

所述esb-api子系统还用于从所述kafka子系统的消息队列中获取所述请求结果，并将所述请求结果发送至所述数据请求的请求方。

本发明的第二方面提供一种利用所述的企业服务总线系统进行企业服务总线数据处理方法，所述方法包括：

发布服务，供请求方调用，所述esb-api子系统发布服务协议为dubbo协议，所述esb-proxy-in子系统发布服务协议为http协议和https协议；

侦测是否接收到请求方的数据请求；

当侦测到接收到请求方的数据请求后，识别所述数据请求的请求方是否合法；

当识别所述数据请求的请求方合法时，根据所述数据请求识别所述数据请求的服务方；

根据所述请求的服务方将所述数据请求封装成相应的消息，并将封装后的消息由所述esb-api子系统中的消息生产者将消息发送至所述kafka子系统；

所述kafka子系统接收到所述esb-api子系统发送的待处理的消息时，根据所述待处理的消息配置相应的消息队列，并对所述待处理的消息进行处理；

每隔预设时间段所述esb-consumer子系统从所述kafka子系统的消息队列中拉取所述待处理的消息，根据所述待处理的消息创建相应的线程；

所述esb-consumer子系统对所述待处理的消息进行解析，并将解析后的内容发送至所述数据请求对应的服务方；

所述esb-consumer子系统获取所述数据请求的服务方发送的请求结果并将所述请求结果暂存至所述kafka子系统的消息队列中；

所述esb-api子系统从所述kafka子系统的消息队列中获取所述请求结果，并将所述请求结果发送至所述数据请求的请求方。

优选地，所述请求方的数据请求为所述请求方根据企业服务系统所发布的服务协议对数据请求进行封装后的数据请求，包括：

当所述请求方为所述企业系统时，根据所述dubbo协议对所述数据请求进行封装；

当所述请求方为第三方系统时，根据所述http协议或者https协议对所述数据请求进行封装。

优选地，所述根据所述数据请求识别所述数据请求的服务方包括：

根据所述数据请求中携带的数据请求服务方标识识别所述数据请求的服务方；

当识别所述数据请求服务方标识为第一标识时，确定所述数据请求服务方为企业系统；

当识别所述数据请求服务方标识为第二标识时，确定所述数据请求服务方为第三方系统。

优选地，所述根据所述请求的服务方将所述数据请求封装成相应的消息，并将封装后的消息由所述esb-api子系统中的消息生产者将消息发送至所述kafka子系统包括：

当所述数据请求的接收系统为所述esb-api子系统时，将所述数据请求封装为消息，并将封装后的消息由所述esb-api子系统中的消息生产者将消息发送至所述kafka子系统；

当所述数据请求的接收系统为所述esb-proxy-in子系统时，将所述数据请求封装为消息，并通过所述esb-proxy-in子系统转发至所述esb-api子系统后，由所述esb-api子系统中的消息生产者将消息发送至所述kafka子系统。

优选地，所述根据所述待处理的消息创建相应的线程包括：根据所述服务方对应的所述请求并发数创建相应大小的线程池，所述请求并发数等于所述线程池的大小。

优选地，所述将解析后的内容发送至所述数据请求对应的服务方包括：当所述数据请求的服务方为所述第三方系统时，通过所述esb-proxy-out子系统或所述esb-file-proxy-out子系统将解析后的内容发送至所述数据请求的服务方；当所述数据请求的服务方为所述企业系统时，直接将将解析后的内容发送至所述企业系统。

优选地，所述将所述请求结果发送至所述数据请求的请求方包括：当所述数据请求的请求方为所述企业系统时，所述esb-api子系统直接将所述请求结果发送至所述企业系统；当所述数据请求的请求方为所述第三方系统时，所述esb-api子系统通过所述esb-proxy-out子系统或所述esb-file-proxy-out子系统将所述请求结果发送至所述第三方系统。

优选地，所述方法还包括：

判断当前请求状态是否满足熔断条件；

当当前请求状态满足熔断条件时，配置第一数量的消息队列，并向当前接收到的数据请求的请求方返回预设信息；

当当前请求状态不满足熔断条件时，配置第二数量的消息队列。

优选地，所述熔断条件包括以下一种或多种的组合：

当前的数据请求的耗时时间超过预设耗时时间；或者

预设时间段内的所有数据请求的耗时时间的平均值大于或者等于接口超过时间；或者

所述esb-api子系统消息队列中的消息数量超过预设数量；或者

接收到同一个数据请求的请求方的数据请求的数量超过预设数量。

本发明的第三方面提供一种终端，所述终端包括处理器和存储器，所述处理器用于执行所述存储器中存储的计算机程序时实现所述的企业服务总线数据处理方法。

本发明的第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现所述的企业服务总线数据处理方法。

综上所述，本发明实施例中所述的重模式企业服务总线系统、数据处理方法、终端及存储介质，采用开源框架dubbo的同步处理机制，并结合开源处理流平台kafka的异步处理机制，将同步处理机制转成异步处理机制，使得esb不仅具有dubbo的均衡负载的特点，还兼具kafka的消息队列的缓冲功能，能够做到动态扩容和消息持久化：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。其次，设置统一的报文格式，通过将不同的数据请求的请求方发送的数据请求转换成统一的报文和请求协议，能够屏蔽异构系统的底层技术差异，还便于数据请求的请求方的开发和管理。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1是本发明实施例一提供的重模式企业服务总线系统的运行环境图。

图2是本发明实施例二提供的重模式企业服务总线数据处理方法的流程图。

图3是本发明实施例三提供的终端的示意图。

如下具体实施方式将结合上述附图进一步说明本发明。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施例对本发明进行详细描述。需要说明的是，在不冲突的情况下，本发明的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明。

实施例一

图1是本发明实施例一提供的重模式企业服务总线系统的运行环境图。

本实施例中，企业系统200通过重模式企业服务总线系统100(enterpriseservicebus，esb，下文简称为esb100)与第三方系统300进行通讯连接及数据交互。第三方系统300通过esb100与企业系统200进行通讯连接及数据交互。

所述企业系统200可以包括多个企业内部应用或者企业内部文件服务，例如，企业应用1、企业应用2及企业应用3，不同的企业内部应用或者企业内部文件服务可以配置在不同的服务器上。

所述第三方系统300可以包括多个第第三方应用或者第三方文件服务，例如，第三方应用1、第三方应用2、第三方应用3及三方文件服务，不同的第三方应用或者第三方文件服务可以配置在不同的服务器上。

所述esb100可以包括多个子系统，例如：esb-api子系统(下文简称为esb-api)101、kafka子系统(下文简称为kafka)102、esb-consumer子系统(下文简称为esb-consumer)103、esb-proxy-in子系统(下文简称为esb-proxy-in)104、esb-proxy-out子系统(下文简称为esb-proxy-out)105、esb-file-proxy-out子系统(下文简称为esb-file-proxy-out)106。其中，kafka102分别与esb-api101及esb-consumer103通讯连接，esb-api101与esb-proxy-in104通讯连接，esb-consumer103分别与esb-proxy-out105及esb-file-proxy-out106通讯连接。esb-proxy-in104可以称之为接入代理服务器。esb-proxy-out105及esb-file-proxy-out106可以称之为接出代理服务器。

在其他实施例中，所述esb100还可以包括zookeeper子系统107及nas子系统108。

本实施例中，所述esb100中的各子系统(例如，esb-api10、esb-proxy-in104、esb-proxy-out105、esb-file-proxy-out106)用于发布服务。发布服务为发布服务协议，所述服务协议可以包括：dubbo协议、http协议、https协议。

本实施例中，所述企业系统200、esb100、第三方系统300可以为请求方，也可以为服务方。esb100会为不同的所述企业系统200以及不同的所述第三方系统300建立唯一标识和请求并发数，例如为某一银行建立标识“b10047”，请求并发数为100。

本实施例中，所述esb-api101发布服务协议为dubbo协议，服务名称格式为“esb-api.service.xxxxxx_yyyyyy”，所述接口名称中的“xxxxxx”为服务方(所述企业系统200或所述第三方系统300)的标识，所述接口名称中的“yyyyyy“为所述服务方提供的服务名称，所述esb-api101发布服务供企业系统200和所述esb-proxy-in104调用。

本实施例中，所述esb-proxy-in104发布服务协议为http协议和https协议，服务名称格式为“esb.yyyyyy”，所述接口名称中的“yyyyyy“为所述服务方(所述企业系统200或所述第三方系统300)提供的服务名称，所述esb-proxy-in104发布服务供所述第三方系统300调用。在所述esb-proxy-in104发布服务时会维护一张服务对应表，将所述esb-proxy-in104发布的服务与所述esb-api101发布的服务对应起来，例如所述esb-proxy-in101发布的esb.customer.queryreferrerlist服务与所述esb-api101发布的esb-api.service.fin004.ff.customer.queryreferrerlist服务对应起来。

本实施例中，所述esb-proxy-out105、esb-file-proxy-out106发布服务协议为dubbo协议，服务名称格式为“esb-proxy.service.xxxxxx_yyyyyy”，所述接口名称中的“xxxxxx”为服务方(所述企业系统200或所述第三方系统300)的标识，所述接口名称中的“yyyyyy“为所述服务方提供的服务名称，所述esb-proxy-out105、esb-file-proxy-out106发布服务供所述esb-api101调用。所述esb-proxy-out105、esb-file-proxy-out106发布的服务与所述esb-api101发布的服务成对出现，例如所述esb-proxy-out105发布的esb-proxy.service.b10043.querygradinginterest

rateservice服务与所述esb-api101发布的esb-api.service.b10043.querygrad-inginterestrateservice服务成对出现。

需要说明的是，esb100作为请求方主要是相对esb100内部的各子系统而言的，因为esb100内部各子系统之间也存在调用关系。

例如：esb100的esb-proxy-in104给esb100的其他子系统调用，同时esb100的esb-proxy-in104也会调用esb100的esb-api101，这时esb-proxy-in104相对于esb-api101就是请求方。

所述esb100还用于侦测是否接收到请求方的数据请求。

请求方的数据请求为请求方根据esb100所发布的服务对数据请求进行封装后的数据请求。

本实施例中，请求方根据所发布的服务对数据请求进行封装可以包括：

1)当请求方为企业系统200时，根据所述esb100的各子系统发布的dubbo协议对数据请求进行封装。

2)当请求方为第三方系统300时，根据所述esb100的各子系统发布的http协议或者https协议对数据请求进行封装。

由请求方根据所述esb100的各子系统发布的服务对数据请求进行封装，请求方只需要按照esb100的统一请求报文格式进行封装就可以了，不需关注不同的服务方的请求报文格式不一样的问题。

举例说明，本实施例提供的统一请求报文格式如下所示：

所述esb100还用于当侦测到接收到请求方的数据请求后，识别所述数据请求的请求方是否合法。

本实施例中，esb100接收到数据请求时，根据所述数据请求识别所述数据请求的请求方是否合法。所述合法是指请求方是否为esb100所承认的合法的企业系统200或第三方系统300，所述企业系统200和所述第三方系统300是指esb100对接的并为其建立了唯一标识的系统。

本实施例中，所述数据请求中可以携带有数据请求来源标识，所述数据请求来源标识用以表明所述数据请求的请求方的身份。所述来源标识即esb100为该系统建立的唯一标识。

所述esb100还用于在识别所述数据请求的请求方不合法时，中断请求。

所述esb100还用于在识别所述数据请求的请求方时，根据所述数据请求识别所述数据请求的服务方。

本实施例中，esb在确定数据请求的请求方为合法的请求方时，根据所述数据请求识别所述数据请求的服务方，所述服务方可以为为企业系统200或第三方系统300。

本实施例中，所述数据请求可以携带有数据请求服务方标识，所述数据请求服务方标识用以表明所述数据请求的服务方的身份。所述数据请求服务方标识包括：第一标识和第二标识，其中所述第一标识用以表明所述数据请求服务方为企业内部应用或者企业内部文件服务，所述第二标识用以表明所述数据请求服务方为第三方应用或者第三方文件服务。

根据所述数据请求识别所述数据请求的服务方可以包括：根据所述数据请求中携带的数据请求服务方标识识别所述数据请求的服务方；当识别所述数据请求服务方标识为第一标识时，确定所述数据请求服务方为企业系统；当识别所述数据请求服务方标识为第二标识时，确定所述数据请求服务方为第三方系统。

举例说明，本实施例中的所述数据请求服务方标识可以为所述esb-api101、esb-proxy-out105、esb-file-proxy-out106所发布的服务名称中的“xxxxxx”部分。

所述esb100还用于根据所述请求的服务方将所述数据请求封装成相应的消息，并将封装后的消息由esb-api101中的消息生产者将消息发送至kafka102。

本实施例中，esb-api101为应用程序编程接口(applicationprogramminginterface，api)预先定义的函数，是esb100的服务入口及消息的生产者。

本实施例中，根据所述请求的服务方将所述数据请求封装成相应的消息，并将封装后的消息由esb-api101中的消息生产者将消息发送至kafka102可以包括：

1)当所述数据请求的接收系统为所述esb-api101时，将数据请求封装为消息，并将封装后的消息由esb-api101中的消息生产者将消息发送至kafka102。

2)当所述数据请求的接收系统为esb-proxy-in104时，将数据请求封装为消息，并通过第一代理服务器转发至esb-api101后，由esb-ap101i中的消息生产者将消息发送至kafka102。

消息封装后直接由esb-api101中的消息生产者发送至kafka102的消息队列中，所述消息中携带有标识号，用以表明存储的消息队列的位置信息。例如，当标识号为a时，表明将所述消息存储于消息队列1中，当标识号为b时，表明将所述消息存储于消息队列2中。所述消息队列可以是kafka102的消息队列或者内存中的消息队列。

所述esb-proxy-in104还可以包括负载均衡功能(例如，图中所示的f5)，对第三方系统300的数据请求进行负载均衡控制。防止高并发时对企业系统(例如，银行系统)造成压力导致瘫痪。

kafka102用于接收到esb-api101发送的待处理的消息时，根据所述待处理的消息配置相应的消息队列，并对所述待处理的消息进行处理。

本实施例中，kafka102是一种高吞吐量的分布式发布订阅消息系统，为esb100提供消息队列，可以处理消费者规模的网站中的所有动作流数据，kafka102具有高吞吐量、支持负载均衡、异步发送、消息持久化的特点。当kafka102侦测到esb-api101发送的消息时，获取待处理的消息，配置相应的消息队列，并对所述待处理的消息进行处理。

所述对待处理的消息进行处理可以包括：将所述待处理的消息进行分布式存储为多个副本；当待处理的消息的数量超过预设数量阈值时，将待处理的消息中的每一条消息进行切片或切块；对待处理的消息进行压缩处理。如此可确保待处理的消息不会丢失且重复消费的问题。

本实施例中，esb100采用kafka102作为消息队列，具有高吞吐率和消息持久化的功能，能够很好地提升esb100的处理能力，使得esb100的处理能力是可控制的，当esb100的服务性能较低时，可使用消息队列对信息进行缓冲，避免当机的情况发生。

所述esb-consumer103用于每隔预设时间段从kafka102的消息队列中拉取所述待处理的消息，根据所述待处理的消息创建相应的线程。

esb-consumer103可以每隔预设时间段(例如，200毫秒)监听kafka102中是否有消息要处理，当esb-consumer103监听到kafka102中有消息要处理时，从kafka102中拉取消息，并根据消息内容路由到对应的代理服务器。

esb100会根据消息队列创建对应的线程池，一个消息队列对应一个线程池，每个线程池固定消费对应的消息队列中的待处理的消息，不同的线程池之间相互不干扰。例如，线程池1只负责消费消息队列1中的待处理的消息，线程池2只负责消费消息队列2中的待处理的消息。

本实施例中，所述根据所述待处理的消息创建相应的线程可以包括：根据所述服务方对应的所述请求并发数创建相应大小的线程池。所述请求并发数等于线程池的大小。

根据所述服务方预先配置好的请求并发数来创建不同大小的线程池，从而实现根据不同的数据请求量执行不同的并发控制，比如，企业系统的数据请求量一般较少，所述服务方(第三方系统300)预先配置好的请求并发数也相应较低，因而esb-consumer103创建的线程池也较小，例如，20-50个；再如，第三方系统的数据请求量一般较多，所述服务方(企业系统200)预先配置好的请求并发数也相应较高，因而esb-consumer103创建的线程池较大，例如，100-150个。

esb-consumer103对所述待处理的消息进行解析，并将解析后的内容发送至所述数据请求对应的服务方。

本实施例中，esb-consumer103的线程可以预先配置有与所述待处理的消息相对应的配置表。所述配置表包括：完成数据请求所需要的系统服务名、系统服务物理路由、系统服务后续流程条件码、条件码对应后续服务等信息。对所述待处理的消息进行解析就是通过检索配置表，解释其中内容，以确定具体服务内容，并确定系统服务名、系统服务物理路由、后续流程条件码、条件码对应后续服务等。

本实施例中，所述服务方是指响应所述请求方的数据请求，并根据所述数据请求提供相应的请求结果的服务者，所述服务方可以包括：企业系统200或者第三方系统300。当然，若企业系统200包括多个企业子系统，例如，企业子系统1，企业子系统2。所述服务方还可以是多个企业子系统中的一个企业子系统。同理，若第三方系统300包括多个第三方子系统，例如，第三方子系统1，第三方子系统2。所述服务方还可以是多个第三方子系统中的一个第三方子系统。即，请求方和服务方可以同时为企业系统200，也可以同时为第三方系统300，如，当企业子系统1请求调用企业子系统2时，此时，企业子系统1为请求方，企业子系统2为服务方。

举例说明，本实施例中提供的服务方响应所述数据请求，即响应所述报文格式如下所示：

本实施例中，将解析后的内容发送至所述数据请求对应的服务方可以包括：

1)当所述数据请求的服务方为第三方系统300时，通过接出代理服务器将解析后的内容发送至所述数据请求的服务方(第三方系统)。

所述接出代理服务器接收到esb-consumer103的线程发送的解析后的内容时，转发所述解析后的内容至第三方系统300中。所述esb-proxy-out105用以接收esb-consumer103的消息，并根据所述消息按照第三方系统预设的请求方式请求第三方系统响应所述数据请求并返回请求结果。所述esb-file-proxy-out106用于接收esb-consumer103的消息，并根据所述消息按照第三方系统300预设的请求方式请求第三方系统300，上传或者下载所述数据请求中对应的文件。

2)当所述数据请求的服务方为企业系统200时，直接将将解析后的内容发送至所述企业系统200。

esb-consumer103获取所述数据请求的服务方发送的请求结果并将所述请求结果暂存至kafka102的消息队列中。

本实施例中，所述获取所述数据请求的服务方发送的请求结果可以包括：

1)当所述数据请求的服务方为第三方系统300时，通过所述接出代理服务器从所述第三方系统300中获取所述请求结果，并将所述请求结果暂存至kafka102的消息队列中。

2)当所述数据请求的服务方为企业系统200时，直接从所述企业系统中获取所述请求结果，并将所述请求结果暂存至kafka102的消息队列中。

esb-api101从所述kafka102的消息队列中获取所述请求结果，并将所述请求结果发送至所述数据请求的请求方。

本实施例中，将所述请求结果发送至所述数据请求的请求方可以包括：

1)当所述数据请求的请求方为企业系统200时，esb-api101直接将所述请求结果发送至所述企业系统200。

2)当所述数据请求的请求方为第三方系统300时，esb-api101通过所述接入代理服务器将所述请求结果发送至所述第三方系统300。

应当说明的是，无论是企业系统200还是第三方系统300，都既可以做数据请求的请求方，也可以做响应所述数据请求并提供请求结果的数据请求的服务方。即，企业系统200作为数据请求的请求方在向所数据请求的服务方(第三方系统300)发送数据请求的同时，也可以作为数据请求的服务方响应数据请求并为数据请求的请求方(第三方系统300)提供请求结果。第三方系统作为数据请求的请求方在向所数据请求的服务方(企业系统200)发送数据请求的同时，也可以作为数据请求的服务方响应数据请求并为数据请求的请求方(企业系统200)提供请求结果。

进一步地，当esb100还用于接收到数据请求时，判断当前请求状态是否满足熔断条件；当当前请求状态满足熔断条件时，配置第一数量的消息队列，并向当前接收到的数据请求的请求方返回预设信息。当当前请求状态不满足熔断条件时，配置第二数量的消息队列。

esb100可以统计每一个数据请求的耗时时间，所述数据请求的耗时时间是指esb100从接收到数据请求的请求方发送的数据请求到向数据请求的请求方返回所述数据请求对应的请求结果的时间。

所述当前请求状态可以包括以下一种或多种的组合：当前的数据请求的耗时时间；预设时间段内的所有数据请求的耗时时间的平均值；esb-api消息队列中的消息数量；接收到同一个数据请求的请求方的数据请求的数量。

所述熔断条件可以包括以下一种或多种的组合：当前的数据请求的耗时时间超过预设耗时时间；预设时间段内的所有数据请求的耗时时间的平均值大于或者等于接口超过时间；esb-api101消息队列中的消息数量超过预设数量；接收到同一个数据请求的请求方的数据请求的数量超过预设数量。

所述预设耗时时间为预先定义的一个时间值。所述预设信息可以是“系统业务繁忙，请稍后再试”。所述第一数量值等于线程池的大小值，所述第二数量值等于线程池的大小值乘以接口超时时间值与平均耗时时间值的比值。

本实施例中，通过预先设置熔断条件，当侦测到满足所述熔断条件时，可使得瞬时高并发超过esb100处理能力时，例如，esb-api101消息队列中的消息数量超过预设数量时，kafka102及esb-consumer103来不及处理数据请求，或者当第三方系统300大量异常或者请求超时时，能够自动对当前的数据请求进行熔断控制，增加消息在消息队列中的等待时间，起到缓冲消息的作用，减少esb100的压力，同时还能及时向当前的数据请求的请求方返回预设信息，做到了及时响应，提高了数据请求的请求方的体验度。

进一步的，所述esb100还可以用于配置可视化管理工具，用以存储消息及响应数据请求。所述可视化管理工具可以包括：mongodb、mongobooster、adminmongo。

进一步的，所述esb100还可以用于提供分布式应用程序协调服务，用于为kafka和dubbo提供注册中心。所述分布式应用程序协调服务可以是zookeeper组件。

综上所述，本发明实施例中所述的重模式企业服务总线系统，采用开源框架dubbo的同步处理机制，并结合开源处理流平台kafka的异步处理机制，将同步处理机制转成异步处理机制，使得esb不仅具有dubbo的均衡负载的特点，还兼具kafka的消息队列的缓冲功能，能够做到动态扩容和消息持久化：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。其次，设置统一的报文格式，通过将不同的数据请求的请求方发送的数据请求转换成统一的报文和请求协议，能够屏蔽异构系统的底层技术差异，还便于数据请求的请求方的开发和管理。另外，根据消息队列中的待处理的消息创建相应的线程，并配置线程池的大小，有效的防止了高并发时数据请求的服务方造成的压力导致了数据请求的服务方系统的瘫痪。且，生产者和消费者独立部署，一个生产者可以配置多个消费者对待处理的消息进行消费。最后，设置熔断条件，在瞬时高并发超过esb处理能力时或者当第三方系统大量异常或者请求超时时，能够自动对当前的数据请求进行熔断控制，增加消息在消息队列中的等待时间，起到缓冲消息的作用，减少esb的压力，同时还能及时向当前的数据请求的请求方返回预设信息，做到了及时响应，提高了数据请求的请求方的体验度。

实施例二

图2是本发明实施例二提供的企业服务总线的数据处理方法的流程图。根据不同的需求，该流程图中的执行顺序可以改变，某些步骤可以省略。

本发明实施例的企业服务总线的数据处理方法可以应用在一个或者多个终端中。所述企业服务总线的数据处理方法也可以应用于由终端和通过网络与所述终端进行连接的服务器所构成的硬件环境中。网络包括但不限于：广域网、城域网或局域网。本发明实施例的企业服务总线的数据处理方法可以由服务器来执行，也可以由终端来执行；还可以是由服务器和终端共同执行。

所述对于需要进行企业服务总线的数据处理方法的终端，可以直接在终端上集成本发明的方法所提供的企业服务总线的数据处理功能，或者安装用于实现本发明的方法的客户端。再如，本发明所提供的方法还可以以软件开发工具包(softwaredevelopmentkit，sdk)的形式运行在服务器等设备上，以sdk的形式提供企业服务总线架构功能的接口，终端或其他设备通过提供的接口即可实现对企业服务总线的数据处理。

s11、发布服务，供请求方调用。

本实施例中，可以由esb中的各子系统发布服务，esb中的各子系统包括：esb-api、esb-proxy-in、esb-proxy-out、esb-file-proxy-out，发布服务为发布服务协议，所述服务协议可以包括：dubbo协议、http协议、https协议。

本实施例中，所述请求方可以为企业系统、esb、第三方系统。所述企业系统可以包括多个企业内部应用或者企业内部文件服务，不同的企业内部应用或者企业内部文件服务可以配置在不同的服务器上。所述esb可以为本方案中所述esb中的各子系统。所述第三方系统可以包括多个第第三方应用或者第三方文件服务，不同的第三方应用或者第三方文件服务可以配置在不同的服务器上。esb会为不同的所述企业系统以及不同的所述第三方系统建立唯一标识和请求请求并发数，例如为某一银行建立标识“b10047”，请求并发数为100。

本实施例中，所述esb-api发布服务协议为dubbo协议，服务名称格式为“esb-api.service.xxxxxx_yyyyyy”，所述接口名称中的“xxxxxx”为服务方(所述企业系统或所述第三方系统)的标识，所述接口名称中的“yyyyyy“为所述服务方提供的服务名称，所述esb-api发布服务供企业系统和所述esb-proxy-in调用。

本实施例中，所述esb-proxy-in发布服务协议为http协议和https协议，服务名称格式为“esb.yyyyyy”，所述接口名称中的“yyyyyy“为所述服务方(所述企业系统或所述第三方系统)提供的服务名称，所述esb-proxy-in发布服务供所述第三方系统调用。在所述esb-proxy-in发布服务时会维护一张服务对应表，将所述esb-proxy-in发布的服务与所述esb-api发布的服务对应起来，例如所述esb-proxy-in发布的esb.customer.queryreferrerlist服务与所述esb-api发布的esb-api.service.fin004.ff.customer.queryreferrerlist服务对应起来。

本实施例中，所述esb-proxy-out、esb-file-proxy-out发布服务协议为dubbo协议，服务名称格式为“esb-proxy.service.xxxxxx_yyyyyy”，所述接口名称中的“xxxxxx”为服务方(所述企业系统或所述第三方系统)的标识，所述接口名称中的“yyyyyy“为所述服务方提供的服务名称，所述esb-proxy-out、esb-file-proxy-out发布服务供所述esb-api调用。所述esb-proxy-out、esb-file-proxy-out发布的服务与所述esb-api发布的服务成对出现，例如所述esb-proxy-out发布的esb-proxy.service.b10043.querygradinginterestrateservice服务与所述esb-api发布的esb-api.service.b10043.querygradinginterestrateservice服务成对出现。

需要说明的是，esb作为请求方主要是相对esb内部的各子系统而言的，因为esb内部各子系统之间也存在调用关系。

例如：esb的esb-proxy-in子系统给esb的其他子系统调用，同时esb的esb-proxy-in子系统也会调用esb的esb-api子系统，这时esb-proxy-in子系统相对于esb-api子系统就是请求方。

s12、侦测是否接收到请求方的数据请求。

请求方的数据请求为请求方根据esb所发布的服务对数据请求进行封装后的数据请求。

本实施例中，请求方根据所发布的服务对数据请求进行封装可以包括：

1)当请求方为企业系统时，根据所述esb的各子系统发布的dubbo协议对数据请求进行封装。

2)当请求方为第三方系统时，根据所述esb的各子系统发布的http协议或者https协议对数据请求进行封装。

由请求方根据所述esb的各子系统发布的服务对数据请求进行封装，请求方只需要按照esb的统一请求报文格式进行封装就可以了，不需关注不同的服务方的请求报文格式不一样的问题。

举例说明，本实施例提供的统一请求报文格式如下所示：

当侦测到接收到请求方的数据请求后，执行步骤s13；否则，可以继续侦测是否接收到请求方的数据请求。

s13、识别所述数据请求的请求方是否合法。

本实施例中，esb接收到数据请求时，根据所述数据请求识别所述数据请求的请求方是否合法。所述合法是指请求方是否为esb所承认的合法的企业系统或第三方系统，所述企业系统和所述第三方系统是指esb对接的并为其建立了唯一标识的系统。若请求方不合法则中断请求，请求方合法则进行后续流程s14。

本实施例中，所述数据请求中可以携带有数据请求来源标识，所述数据请求来源标识用以表明所述数据请求的请求方的身份。所述来源标识即esb为该系统建立的唯一标识。

s14、根据所述数据请求识别所述数据请求的服务方。

本实施例中，esb在确定数据请求的请求方为合法的请求方时，根据所述数据请求识别所述数据请求的服务方，所述服务方可以为为企业系统或第三方系统。所述企业系统可以包括多个企业内部应用或者企业内部文件服务，不同的企业内部应用或者企业内部文件服务可以配置在不同的服务器上。所述第三方系统可以包括多个第三方应用或者第三方文件服务，不同的第三方应用或者第三方文件服务可以配置在不同的服务器上。

本实施例中，所述数据请求可以携带有数据请求服务方标识，所述数据请求服务方标识用以表明所述数据请求的服务方的身份。所述数据请求服务方标识包括：第一标识和第二标识，其中所述第一标识用以表明所述数据请求服务方为企业内部应用或者企业内部文件服务，所述第二标识用以表明所述数据请求服务方为第三方应用或者第三方文件服务。

根据所述数据请求识别所述数据请求的服务方可以包括：根据所述数据请求中携带的数据请求服务方标识识别所述数据请求的服务方；当识别所述数据请求服务方标识为第一标识时，确定所述数据请求服务方为企业系统；当识别所述数据请求服务方标识为第二标识时，确定所述数据请求服务方为第三方系统。

举例说明，本实施例中的所述数据请求服务方标识可以为所述esb-api、esb-proxy-out、esb-file-proxy-out所发布的服务名称中的“xxxxxx”部分。

s15、根据所述请求的服务方将所述数据请求封装成相应的消息，并将封装后的消息由esb-api中的消息生产者将消息发送至kafka。

本实施例中，应用程序编程接口(applicationprogramminginterface，api)为预先定义的函数，是esb的服务入口及消息的生产者。

本实施例中，根据所述请求的服务方将所述数据请求封装成相应的消息，并将封装后的消息由esb-api中的消息生产者将消息发送至kafka可以包括：

1)当所述数据请求的接收系统为所述esb-api时，将数据请求封装为消息，并将封装后的消息由esb-api中的消息生产者将消息发送至kafka。

2)当所述数据请求的接收系统为第一代理服务器时，将数据请求封装为消息，并通过第一代理服务器转发至esb-api后，由esb-api中的消息生产者将消息发送至kafka。

消息封装后直接由esb-api中的消息生产者发送至kafka的消息队列中，所述消息中携带有标识号，用以表明存储的消息队列的位置信息。例如，当标识号为a时，表明将所述消息存储于消息队列1中，当标识号为b时，表明将所述消息存储于消息队列2中。所述消息队列可以是kafka的消息队列或者内存中的消息队列。

所述第一代理服务器可以为接入代理服务器(esb-proxy-in)。

所述第一代理服务器还可以包括负载均衡功能(例如，图中所示的f5)，对第三方系统的数据请求进行负载均衡控制。防止高并发时对企业系统(例如，银行系统)造成压力导致瘫痪。

s16、kafka接收到esb-api发送的待处理的消息时，根据所述待处理的消息配置相应的消息队列，并对所述待处理的消息进行处理。

本实施例中，kafka是一种高吞吐量的分布式发布订阅消息系统，为esb提供消息队列，可以处理消费者规模的网站中的所有动作流数据，kafka具有高吞吐量、支持负载均衡、异步发送、消息持久化的特点。当kafka侦测到esb-api发送的消息时，获取待处理的消息，配置相应的消息队列，并对所述待处理的消息进行处理。

所述对待处理的消息进行处理可以包括：将所述待处理的消息进行分布式存储为多个副本；当待处理的消息的数量超过预设数量阈值时，将待处理的消息中的每一条消息进行切片或切块；对待处理的消息进行压缩处理。如此可确保待处理的消息不会丢失且重复消费的问题。

本实施例中，esb采用kafka作为消息队列，具有高吞吐率和消息持久化的功能，能够很好地提升esb的处理能力，使得esb的处理能力是可控制的，当esb的服务性能较低时，可使用消息队列对信息进行缓冲，避免当机的情况发生。

s17、每隔预设时间段esb-consumer从kafka的消息队列中拉取所述待处理的消息，根据所述待处理的消息创建相应的线程。

esb-consumer可以每隔预设时间段(例如，200毫秒)监听kafka中是否有消息要处理，当esb-consumer监听到kafka中有消息要处理时，从kafka中拉取消息，并根据消息内容路由到对应的代理服务器。

esb会根据消息队列创建对应的线程池，一个消息队列对应一个线程池，每个线程池固定消费对应的消息队列中的待处理的消息，不同的线程池之间相互不干扰。例如，线程池1只负责消费消息队列1中的待处理的消息，线程池2只负责消费消息队列2中的待处理的消息。

本实施例中，所述根据所述待处理的消息创建相应的线程可以包括：根据所述服务方对应的所述请求并发数创建相应大小的线程池。所述请求并发数等于线程池的大小。

根据所述服务方预先配置好的请求并发数来创建不同大小的线程池，从而实现根据不同的数据请求量执行不同的并发控制，比如，企业系统的数据请求量一般较少，所述服务方(第三方系统)预先配置好的请求并发数也相应较低，因而esb-consumer创建的线程池也较小，例如，20-50个；再如，第三方系统的数据请求量一般较多，所述服务方(企业系统)预先配置好的请求并发数也相应较高，因而esb-consumer创建的线程池较大，例如，100-150个。

s18、esb-consumer对所述待处理的消息进行解析，并将解析后的内容发送至所述数据请求对应的服务方。

本实施例中，esb-consumer的线程可以预先配置有与所述待处理的消息相对应的配置表。所述配置表包括：完成数据请求所需要的系统服务名、系统服务物理路由、系统服务后续流程条件码、条件码对应后续服务等信息。对所述待处理的消息进行解析就是通过检索配置表，解释其中内容，以确定具体服务内容，并确定系统服务名、系统服务物理路由、后续流程条件码、条件码对应后续服务等。

本实施例中，所述服务方是指响应所述请求方的数据请求，并根据所述数据请求提供相应的请求结果的服务者，所述服务方可以包括：企业系统或者第三方系统。当然，若企业系统包括多个企业子系统，例如，企业子系统1，企业子系统2。所述服务方还可以是多个企业子系统中的一个企业子系统。同理，若第三方系统包括多个第三方子系统，例如，第三方子系统1，第三方子系统2。所述服务方还可以是多个第三方子系统中的一个第三方子系统。即，请求方和服务方可以同时为企业系统，也可以同时为第三方系统，如，当企业子系统1请求调用企业子系统2时，此时，企业子系统1为请求方，企业子系统2为服务方。

举例说明，本实施例中提供的服务方响应所述数据请求，即响应所述报文格式如下所示：

本实施例中，将解析后的内容发送至所述数据请求对应的服务方可以包括：

1)当所述数据请求的服务方为第三方系统时，通过第二代理服务器将解析后的内容发送至所述数据请求的服务方(第三方系统)。

所述第二代理服务器可以为接出代理服务器(服务适配器esb-proxy-out或者服务文件适配器esb-file-proxy-out)，所述第二代理服务器接收到esb-consumer的线程发送的解析后的内容时，转发所述解析后的内容至第三方系统中。所述esb-proxy-out用以接收esb-consumer的消息，并根据所述消息按照第三方系统预设的请求方式请求第三方系统响应所述数据请求并返回请求结果。所述esb-file-proxy-out用于接收esb-consumer的消息，并根据所述消息按照第三方系统预设的请求方式请求第三方系统，上传或者下载所述数据请求中对应的文件。

2)当所述数据请求的服务方为企业系统时，直接将将解析后的内容发送至所述企业系统。

s19、esb-consumer获取所述数据请求的服务方发送的请求结果并将所述请求结果暂存至kafka的消息队列中。

本实施例中，所述获取所述数据请求的服务方发送的请求结果可以包括：

1)当所述数据请求的服务方为第三方系统时，通过所述第二代理服务器从所述第三方系统中获取所述请求结果，并将所述请求结果暂存至kafka的消息队列中。

2)当所述数据请求的服务方为企业系统时，直接从所述企业系统中获取所述请求结果，并将所述请求结果暂存至kafka的消息队列中。

s20、esb-api从所述kafka的消息队列中获取所述请求结果，并将所述请求结果发送至所述数据请求的请求方。

本实施例中，将所述请求结果发送至所述数据请求的请求方可以包括：

1)当所述数据请求的请求方为企业系统时，esb-api直接将所述请求结果发送至所述企业系统。

2)当所述数据请求的请求方为第三方系统时，esb-api通过所述第一代理服务器将所述请求结果发送至所述第三方系统。

应当说明的是，无论是企业系统还是第三方系统，都既可以做数据请求的请求方，也可以做响应所述数据请求并提供请求结果的数据请求的服务方。即，企业系统作为数据请求的请求方在向所数据请求的服务方(第三方系统)发送数据请求的同时，也可以作为数据请求的服务方响应数据请求并为数据请求的请求方(第三方系统)提供请求结果。第三方系统作为数据请求的请求方在向所数据请求的服务方(企业系统)发送数据请求的同时，也可以作为数据请求的服务方响应数据请求并为数据请求的请求方(企业系统)提供请求结果。

进一步地，当接收到数据请求时，所述方法还可以包括：判断当前请求状态是否满足熔断条件；当当前请求状态满足熔断条件时，配置第一数量的消息队列，并向当前接收到的数据请求的请求方返回预设信息。当当前请求状态不满足熔断条件时，配置第二数量的消息队列。

esb可以统计每一个数据请求的耗时时间，所述数据请求的耗时时间是指esb从接收到数据请求的请求方发送的数据请求到向数据请求的请求方返回所述数据请求对应的请求结果的时间。

所述当前请求状态可以包括以下一种或多种的组合：当前的数据请求的耗时时间；预设时间段内的所有数据请求的耗时时间的平均值；esb-api消息队列中的消息数量；接收到同一个数据请求的请求方的数据请求的数量。

所述熔断条件可以包括以下一种或多种的组合：当前的数据请求的耗时时间超过预设耗时时间；预设时间段内的所有数据请求的耗时时间的平均值大于或者等于接口超过时间；esb-api消息队列中的消息数量超过预设数量；接收到同一个数据请求的请求方的数据请求的数量超过预设数量。

所述预设耗时时间为预先定义的一个时间值。所述预设信息可以是“系统业务繁忙，请稍后再试”。所述第一数量值等于线程池的大小值，所述第二数量值等于线程池的大小值乘以接口超时时间值与平均耗时时间值的比值。

本实施例中，通过预先设置熔断条件，当侦测到满足所述熔断条件时，可使得瞬时高并发超过esb处理能力时，例如，esb-api消息队列中的消息数量超过预设数量时，kafka及esb-consumer来不及处理数据请求，或者当第三方系统大量异常或者请求超时时，能够自动对当前的数据请求进行熔断控制，增加消息在消息队列中的等待时间，起到缓冲消息的作用，减少esb的压力，同时还能及时向当前的数据请求的请求方返回预设信息，做到了及时响应，提高了数据请求的请求方的体验度。

进一步的，所述方法还可以包括：配置可视化管理工具，用以存储消息及响应数据请求。所述可视化管理工具可以包括：mongodb、mongobooster、adminmongo。

进一步的，所述方法还可以包括：提供分布式应用程序协调服务，用于为kafka和dubbo提供注册中心。所述分布式应用程序协调服务可以是zookeeper组件。

综上所述，本发明实施例中所述的重模式企业服务总线数据处理方法，采用开源框架dubbo的同步处理机制，并结合开源处理流平台kafka的异步处理机制，将同步处理机制转成异步处理机制，使得esb不仅具有dubbo的均衡负载的特点，还兼具kafka的消息队列的缓冲功能，能够做到动态扩容和消息持久化：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。其次，设置统一的报文格式，通过将不同的数据请求的请求方发送的数据请求转换成统一的报文和请求协议，能够屏蔽异构系统的底层技术差异，还便于数据请求的请求方的开发和管理。另外，根据消息队列中的待处理的消息创建相应的线程，并配置线程池的大小，有效的防止了高并发时数据请求的服务方造成的压力导致了数据请求的服务方系统的瘫痪。且，生产者和消费者独立部署，一个生产者可以配置多个消费者对待处理的消息进行消费。最后，设置熔断条件，在瞬时高并发超过esb处理能力时或者当第三方系统大量异常或者请求超时时，能够自动对当前的数据请求进行熔断控制，增加消息在消息队列中的等待时间，起到缓冲消息的作用，减少esb的压力，同时还能及时向当前的数据请求的请求方返回预设信息，做到了及时响应，提高了数据请求的请求方的体验度。

以上所述，仅是本发明的具体实施方式，但本发明的保护范围并不局限于此，对于本领域的普通技术人员来说，在不脱离本发明创造构思的前提下，还可以做出改进，但这些均属于本发明的保护范围。

实施例三

图3为本发明实施例五提供的终端的示意图。

所述终端3包括：存储器31、至少一个处理器32、存储在所述存储器31中并可在所述至少一个处理器32上运行的计算机程序33及至少一条通讯总线34。

所述至少一个处理器32执行所述计算机程序33时实现上述企业服务总线数据处理方法实施例中的步骤。

示例性的，所述计算机程序33可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器31中，并由所述至少一个处理器32执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序33在所述终端3中的执行过程。

所述终端3可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。本领域技术人员可以理解，所述示意图3仅仅是终端3的示例，并不构成对终端3的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端3还可以包括输入输出设备、网络接入设备、总线等。

所述至少一个处理器32可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。该处理器32可以是微处理器或者该处理器32也可以是任何常规的处理器等，所述处理器32是所述终端3的控制中心，利用各种接口和线路连接整个终端3的各个部分。

所述存储器31可用于存储所述计算机程序33和/或模块/单元，所述处理器32通过运行或执行存储在所述存储器31内的计算机程序和/或模块/单元，以及调用存储在存储器31内的数据，实现所述终端3的各种功能。所述存储器31可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端3的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器31可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(smartmediacard，smc)，安全数字(securedigital，sd)卡，闪存卡(flashcard)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

所述终端3集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

在本发明所提供的几个实施例中，应该理解到，所揭露的终端和方法，可以通过其它的方式实现。例如，以上所描述的终端实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

另外，在本发明各个实施例中的各功能单元可以集成在相同处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在相同单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神范围。