CN108255853A - 一种插件式的请求异步处理方法以及系统 - Google Patents

Abstract

一种插件式的请求异步处理方法以及系统，方法包括：S1、请求接受服务接受外部请求数据，调用请求分发框架；S2、请求分发框架判断是否存在对应的请求存储服务，如果没有，则基于路由分发策略通过插件方式动态创建请求存储服务以及与请求存储服务绑定的请求处理服务；S3、基于当前的路由分发策略将请求数据写入对应的请求存储服务；S4、请求处理服务从相应的请求存储服务中读取需要处理的请求数据并进行请求处理。本发明根据请求不同，动态调整请求存储服务及请求处理服务，请求是写入独立的请求存储服务，由对应的请求存储服务读取后处理，实现高性能的异步请求存储和处理；进一步的，业务请求可以在分类的基础上，按照优先级、负载均衡进行处理。

Description

一种插件式的请求异步处理方法以及系统

技术领域

本发明涉及数据处理技术领域，尤其涉及一种插件式的请求异步处理方法以及系统。

背景技术

在移动互联网时代，大数据量高并发的业务请求处理已经成为常态，如何有效快速的处理高并发请求并能灵活配置，成为当前急需解决的问题。一般基于异步请求处理模式为系统提供低延时、高吞吐量的请求处理。

参考图1，现有技术的异步请求处理主要分为三部分：请求接受服务、请求统一存储服务、请求处理服务。

请求接受服务：负责接受外部请求，并对请求数据进行初步的合法性校验，通过后，将请求数据写入统一请求存储服务例如保存至数据库、分布式缓存或消息队列，后向请求返回应答信息。

统一请求存储服务：负责所有请求数据的存储，向请求服务提供请求数据的写入，向请求处理服务提供数据的读取服务。

请求处理服务：负责具体业务请求的逻辑处理，从统一存储服务中读取需要处理的业务请求数据，并进行逻辑处理，完成实际的业务处理。

上述处理方案中，由于所有请求数据都在统一的存储服务中，如果采用数据库存储方式下，日积月累，库表中的数据量越来越大，受限于数据库单表处理的能力，业务数据处理的能力存在瓶颈，无法支撑高吞吐量的分布式处理能力；业务请求数据类型不同，其业务处理逻辑的处理性能及其处理的依赖关系也不同(如业务处理依赖于第三方平台对流控存在不同的要求)，根据木桶原理，导致异步的整体处理性能不能最大发挥，无法根据不同的业务请求进行权重的划分处理；如果存在批量或者紧急业务需要处理，由于请求进行了统一排队处理，因此部分紧急数据紧急的请求不能优先处理，需要单独引入相对负载的优先级处理机制。

发明内容

本发明要解决的技术问题在于，针对现有技术的上述缺陷，提供一种插件式的请求异步处理方法以及系统。

本发明解决其技术问题所采用的技术方案是：构造一种插件式的请求异步处理方法，方法包括：

S1、请求接受服务接受外部请求数据，调用请求分发框架；

S2、请求分发框架判断是否存在与请求数据对应的请求存储服务，如果没有，则基于路由分发策略通过插件方式动态创建请求存储服务以及与请求存储服务绑定的请求处理服务；

S3、基于当前的路由分发策略将请求数据写入对应的请求存储服务；

S4、请求处理服务从相应的请求存储服务中读取需要处理的请求数据并进行请求处理。

在本发明所述的插件式的请求异步处理方法中，所述路由分发策略包括路由策略和分发策略，所述路由策略包括请求类型、请求来源、请求优先级，所述分发策略包括轮询、优先级、负载均衡。

在本发明所述的插件式的请求异步处理方法中，步骤S2包括：

S21、基于路由策略对请求数据进行识别；

S22、从请求存储服务列表中查询与识别结果对应的标识信息，如果查询到标识信息则进入步骤S3，否则，判断不存在与请求数据对应的请求存储服务，进入步骤S23；

S23、基于路由策略通过插件方式创建与识别结果对应的请求存储服务并初始化；

S24、创建与请求存储服务对应的请求处理服务的线程池，初始化线程池后绑定相应的请求存储服务，返回请求存储服务的标识信息至请求分发框架；

S25、请求分发框架将接收的标识信息加入到请求存储服务列表。

在本发明所述的插件式的请求异步处理方法中，所述步骤S3包括：

S31、根据步骤S22中查询到的标识信息或者步骤S24中返回的标识信息，选取请求存储服务，

S32、将请求数据按照分发策略发往选取的请求存储服务。

在本发明所述的插件式的请求异步处理方法中，

步骤S2之前还包括：请求分发框架被调用时，对请求数据进行合法性校验，如果校验不通过，则不作处理，如果校验通过则进入步骤S2；

步骤S1之前还包括：在系统启动或者配置变更时，基于路由策略通过插件方式创建若干个请求存储服务以及与请求存储服务绑定的请求处理服务，并返回请求存储服务列表至请求分发框架。

本发明还公开了一种插件式的请求异步处理系统，包括：

请求接受服务，用于接受外部请求数据，调用请求分发框架；

请求分发框架，用于在被调用时判断是否存在与请求数据对应的请求存储服务，如果没有，则基于路由分发策略通过插件方式动态创建请求存储服务以及与请求存储服务绑定的请求处理服务；以及基于当前的路由分发策略将请求数据写入对应的请求存储服务；

至少一个请求存储服务，用于指定的请求数据的存储，向请求接受服务提供请求数据的写入，向请求处理服务提供数据的读取服务；

至少一个请求处理服务集群，用于从相应的请求存储服务中读取需要处理的请求数据并进行请求处理。

在本发明所述的插件式的请求异步处理系统中，所述路由分发策略包括路由策略和分发策略，所述路由策略包括请求类型、请求来源、请求优先级，所述分发策略包括轮询、优先级、负载均衡。

在本发明所述的插件式的请求异步处理系统中，所述请求分发框架包括：

请求识别单元，用于基于路由策略对请求数据进行识别；

标识信息获取单元，用于从请求存储服务列表中查询与识别结果对应的标识信息；

服务创建单元，用于通过插件方式创建与识别结果对应的请求存储服务并初始化，创建与请求存储服务对应的请求处理服务的线程池，初始化线程池后绑定相应的请求存储服务；

请求存储服务列表更新单元，用于接收请求存储服务返回的标识信息，并将接收的标识信息加入到请求存储服务列表。

在本发明所述的插件式的请求异步处理系统中，请求分发框架还包括：

请求存储服务选取单元，用于根据标识信息获取单元查询到的标识信息或者服务创建单元返回的标识信息，选取请求存储服务，

请求转发单元，用于将请求数据按照分发策略发往选取的请求存储服务。

在本发明所述的插件式的请求异步处理系统中，请求分发框架还包括：

初始化单元，用于在系统启动或者配置变更时，基于路由策略通过插件方式创建若干个请求存储服务以及与请求存储服务绑定的请求处理服务，并接收该若干个请求存储服务返回的标识信息形成所述请求存储服务列表；

合法性校验单元，用于在请求分发框架被调用时，对请求数据进行合法性校验，如果校验不通过，则不作处理，如果校验通过则触发请求识别单元。

实施本发明的插件式的请求异步处理方法以及系统，具有以下有益效果：本发明配置有路由分发策略，请求分发框架根据业务请求的不同需要，通过插件方式动态的调整请求存储服务以及请求处理服务，请求并不是统一存储，而是写入独立的请求存储服务，再由对应的请求存储服务读取后进行处理，因此可以实现高性能的异步请求存储和处理，解决了异步请求处理中统一请求存储的单点存储性能，提升系统的可伸缩能力；进一步的，业务请求可以在分类的基础上，按照优先级、负载均衡的方式进行处理。

附图说明

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

图1是本发明的插件式的请求异步处理方法的流程图；

图2是创建请求存储服务和请求处理服务的时序图；

图3是本发明的插件式的请求异步处理系统的结构示意图。

具体实施方式

为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明，应当理解本发明实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本发明实施例以及实施例中的技术特征可以相互组合。

参考图1，是本发明的插件式的请求异步处理方法的流程图；本发明的插件式的请求异步处理方法包括：

S1、请求接受服务接受外部请求数据，调用请求分发框架；

S2、请求分发框架判断是否存在与请求数据对应的请求存储服务，如果没有，则基于路由分发策略通过插件方式动态创建请求存储服务以及与请求存储服务绑定的请求处理服务，其中，请求存储服务一般包括多个队列。

其中，所述路由分发策略包括路由策略和分发策略，所述路由策略包括但不限于请求类型、请求来源、请求优先级等策略；所述分发策略包括但不限于轮询、优先级、负载均衡等策略。

一般，步骤S2之前还包括：请求分发框架被调用时，对请求数据进行合法性校验，如果校验不通过，则不作处理，如果校验通过则进入步骤S2；

S3、基于当前的路由分发策略将请求数据写入对应的请求存储服务；

S4、请求处理服务从相应的请求存储服务中读取需要处理的请求数据并进行请求处理。

其中，较佳实施例中，步骤S2具体包括：

S21、基于路由策略对请求数据进行识别；

所谓识别，即是从请求数据中提取路由策略所指定的具体策略，即获取请求数据的请求类型、请求来源或者请求优先级等作为识别结果。例如，从请求数据中提取请求类型、请求来源或者请求优先级等。

S22、从请求存储服务列表中查询与识别结果对应的请求存储服务的标识信息，如果查询到标识信息则进入步骤S3直接写入请求至相应的请求存储服务器即可，否则，判断不存在与请求数据对应的请求存储服务，需要新创建与当前请求对应的请求存储服务器和请求处理服务器，进入步骤S23；

S23、基于路由策略通过插件方式创建与识别结果(请求类型、请求来源或者请求优先级等)对应的请求存储服务并初始化；

S24、创建与请求存储服务对应的请求处理服务的线程池，初始化线程池后绑定相应的请求存储服务，返回请求存储服务的标识信息至请求分发框架；

S25、请求分发框架将接收的标识信息加入到请求存储服务列表。

其中，较佳实施例中，所述步骤S3包括：

S31、根据步骤S22中查询到的标识信息(代表已经存在的相应的请求存储服务)或者步骤S24中返回的标识信息(代表新创建了相应的请求存储服务)，选取请求存储服务，

S32、将请求数据按照分发策略发往选取的请求存储服务。

优选的，可以在系统启动或者配置变更时进行初始化，预先建立有一定数量的请求存储服务和请求处理服务。为此步骤S1之前还包括：在系统启动或者配置变更时，基于路由策略通过插件方式创建若干个请求存储服务以及与请求存储服务绑定的请求处理服务，并返回请求存储服务列表至请求分发框架。此处请求存储服务和请求处理服务具体的创建过程可以参考在处理请求的过程中的创建过程，即步骤S23-S24，此处不再赘述。

例如，假设路由策略设定为按照请求来源创建请求存储服务和请求处理服务，假设系统启动时初始化建立了若干个常用IP地址的请求存储服务，其标识信息(代表请求来源)罗列于请求存储服务列表中。当接收到某个请求时，则首先从请求数据中提取出请求来源，再从存储服务列表中查找看是否存在提取的请求来源，如果存在，则将该请求写入到查找到的请求存储服务，如果不存在，则需要通过插件方式动态创建一个与当前请求的请求来源相对应的请求存储服务，再创建与请求存储服务绑定的请求处理服务，然后更新存储服务列表，并把请求写入到新创建的请求存储服务即可。请求存储服务中包括多个队列，因此可以基于轮询、优先级、负载均衡等方式写入其中一个具体的队列，请求处理服务再从队列中读取请求进行处理。

参考图3，相应的，本发明还公开了一种插件式的请求异步处理系统，包括：

请求接受服务，用于接受外部请求数据，调用请求分发框架；

请求分发框架，用于在被调用时判断是否存在与请求数据对应的请求存储服务，如果没有，则基于路由分发策略通过插件方式动态创建请求存储服务以及与请求存储服务绑定的请求处理服务；以及基于当前的路由分发策略将请求数据写入对应的请求存储服务；

至少一个请求存储服务，每个请求存储服务一般包括多个队列，请求存储服务用于指定的请求数据的存储，向请求接受服务提供请求数据的写入，向请求处理服务提供数据的读取服务；

至少一个请求处理服务集群，用于从相应的请求存储服务中读取需要处理的请求数据并进行请求处理。

其中，所述路由分发策略包括路由策略和分发策略，所述路由策略包括但不限于请求类型、请求来源、请求优先级等策略；所述分发策略包括但不限于轮询、优先级、负载均衡等策略。

具体的，所述请求分发框架包括：

请求识别单元，用于基于路由策略对请求数据进行识别；所谓识别，即是从请求数据中提取路由策略所指定的具体策略，即获取请求数据的请求类型、请求来源或者请求优先级等作为识别结果。例如，从请求数据中提取请求类型、请求来源或者请求优先级等。

标识信息获取单元，用于从请求存储服务列表中查询与识别结果对应的标识信息；

服务创建单元，用于通过插件方式创建与识别结果对应的请求存储服务并初始化，创建与请求存储服务对应的请求处理服务的线程池，初始化线程池后绑定相应的请求存储服务；

请求存储服务列表更新单元，用于接收请求存储服务返回的标识信息，并将接收的标识信息加入到请求存储服务列表。

请求存储服务选取单元，用于根据标识信息获取单元查询到的标识信息或者服务创建单元返回的标识信息，选取请求存储服务，

请求转发单元，用于将请求数据按照分发策略发往选取的请求存储服务。

优选的，请求分发框架还包括：

初始化单元，用于在系统启动或者配置变更时，基于路由策略通过插件方式创建若干个请求存储服务以及与请求存储服务绑定的请求处理服务，并接收该若干个请求存储服务返回的标识信息形成所述请求存储服务列表；

合法性校验单元，用于在请求分发框架被调用时，对请求数据进行合法性校验，如果校验不通过，则不作处理，如果校验通过则触发请求识别单元。

综上所述，本发明配置有路由分发策略，请求分发框架根据业务请求的不同需要，通过插件方式动态的调整请求存储服务以及请求处理服务，请求并不是统一存储，而是写入独立的请求存储服务，再由对应的请求存储服务读取后进行处理，因此可以实现高性能的异步请求存储和处理，解决了异步请求处理中统一请求存储的单点存储性能，提升系统的可伸缩能力；进一步的，业务请求可以在分类的基础上，按照优先级、负载均衡的方式进行处理。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims (10)

1.一种插件式的请求异步处理方法，其特征在于，方法包括：

S1、请求接受服务接受外部请求数据，调用请求分发框架；

S2、请求分发框架判断是否存在与请求数据对应的请求存储服务，如果没有，则基于路由分发策略通过插件方式动态创建请求存储服务以及与请求存储服务绑定的请求处理服务；

S3、基于当前的路由分发策略将请求数据写入对应的请求存储服务；

S4、请求处理服务从相应的请求存储服务中读取需要处理的请求数据并进行请求处理。

2.根据权利要求1所述的插件式的请求异步处理方法，其特征在于，所述路由分发策略包括路由策略和分发策略，所述路由策略包括请求类型、请求来源、请求优先级，所述分发策略包括轮询、优先级、负载均衡。

3.根据权利要求2所述的插件式的请求异步处理方法，其特征在于，步骤S2包括：

S21、基于路由策略对请求数据进行识别；

S22、从请求存储服务列表中查询与识别结果对应的标识信息，如果查询到标识信息则进入步骤S3，否则，判断不存在与请求数据对应的请求存储服务，进入步骤S23；

S23、基于路由策略通过插件方式创建与识别结果对应的请求存储服务并初始化；

S24、创建与请求存储服务对应的请求处理服务的线程池，初始化线程池后绑定相应的请求存储服务，返回请求存储服务的标识信息至请求分发框架；

S25、请求分发框架将接收的标识信息加入到请求存储服务列表。

4.根据权利要求3所述的插件式的请求异步处理方法，其特征在于，所述步骤S3包括：

S31、根据步骤S22中查询到的标识信息或者步骤S24中返回的标识信息，选取请求存储服务，

S32、将请求数据按照分发策略发往选取的请求存储服务。

5.根据权利要求3所述的插件式的请求异步处理方法，其特征在于，

步骤S2之前还包括：请求分发框架被调用时，对请求数据进行合法性校验，如果校验不通过，则不作处理，如果校验通过则进入步骤S2；

步骤S1之前还包括：在系统启动或者配置变更时，基于路由策略通过插件方式创建若干个请求存储服务以及与请求存储服务绑定的请求处理服务，并返回请求存储服务列表至请求分发框架。

6.一种插件式的请求异步处理系统，其特征在于，包括：

请求接受服务，用于接受外部请求数据，调用请求分发框架；

请求分发框架，用于在被调用时判断是否存在与请求数据对应的请求存储服务，如果没有，则基于路由分发策略通过插件方式动态创建请求存储服务以及与请求存储服务绑定的请求处理服务；以及基于当前的路由分发策略将请求数据写入对应的请求存储服务；

至少一个请求存储服务，用于指定的请求数据的存储，向请求接受服务提供请求数据的写入，向请求处理服务提供数据的读取服务；

至少一个请求处理服务集群，用于从相应的请求存储服务中读取需要处理的请求数据并进行请求处理。

7.根据权利要求6所述的插件式的请求异步处理系统，其特征在于，所述路由分发策略包括路由策略和分发策略，所述路由策略包括请求类型、请求来源、请求优先级，所述分发策略包括轮询、优先级、负载均衡。

8.根据权利要求6所述的插件式的请求异步处理系统，其特征在于，所述请求分发框架包括：

请求识别单元，用于基于路由策略对请求数据进行识别；

标识信息获取单元，用于从请求存储服务列表中查询与识别结果对应的标识信息；

服务创建单元，用于通过插件方式创建与识别结果对应的请求存储服务并初始化，创建与请求存储服务对应的请求处理服务的线程池，初始化线程池后绑定相应的请求存储服务；

请求存储服务列表更新单元，用于接收请求存储服务返回的标识信息，并将接收的标识信息加入到请求存储服务列表。

9.根据权利要求8所述的插件式的请求异步处理系统，其特征在于，请求分发框架还包括：

请求存储服务选取单元，用于根据标识信息获取单元查询到的标识信息或者服务创建单元返回的标识信息，选取请求存储服务，

请求转发单元，用于将请求数据按照分发策略发往选取的请求存储服务。

10.根据权利要求8所述的插件式的请求异步处理系统，其特征在于，请求分发框架还包括：

初始化单元，用于在系统启动或者配置变更时，基于路由策略通过插件方式创建若干个请求存储服务以及与请求存储服务绑定的请求处理服务，并接收该若干个请求存储服务返回的标识信息形成所述请求存储服务列表；

合法性校验单元，用于在请求分发框架被调用时，对请求数据进行合法性校验，如果校验不通过，则不作处理，如果校验通过则触发请求识别单元。