掌桥专利:专业的专利平台
掌桥专利
首页

处理业务请求的方法、装置、服务器以及存储介质

文献发布时间:2023-06-19 09:26:02


处理业务请求的方法、装置、服务器以及存储介质

技术领域

本公开涉及互联网技术领域,尤其涉及一种处理业务请求的方法、装置、服务器以及存储介质。

背景技术

服务器可以在判断终端满足某些业务执行触发规则的情况下,再去执行终端请求的业务。例如,应用程序开发平台可以对应用程序进行更新,更新后的应用程序在初期可以称为测试版应用程序,测试版应用程序还不能正式发布在下载平台以供所有用户下载。此时的测试版应用程序还可能存在一些未知的问题,需要一小部分满足某些规则的终端优先下载并协助改进。

终端在开启应用程序时,可以触发获取终端相关信息并向服务器发送携带有终端相关信息的业务请求。服务器在接收到业务请求之后,可以验证终端相关信息是否满足预设的业务执行触发规则。在验证结果为终端相关信息能够满足预设的业务执行触发规则的情况下,服务器可以执行终端请求的业务。

在需要变更业务对应的业务执行触发规则时,程序员可以在计算机中编译好变更后的业务执行触发规则对应的执行代码,将执行代码上传至服务器运行。这样,当服务器再次接收到相应的业务请求时,可以基于变更后的业务执行触发规则作出响应。

在实现本公开的过程中,发明人发现至少存在以下问题:

在实际应用中,经常需要变更业务对应的业务执行触发规则,以适应不同需求。在每次变更业务执行触发规则时,程序员都需要在计算机中编译好变更后的业务执行触发规则对应的执行代码,将执行代码上传至服务器运行,才能使服务器基于变更后的业务执行触发规则对终端发送的业务请求进行响应,这种操作效率极低。

发明内容

本公开提供一种处理业务请求的方法、装置、服务器以及存储介质,以至少解决相关技术中变更业务执行触发规则操作效率低的问题。本公开的技术方案如下:

根据本公开实施例的第一方面,提供一种处理业务请求的方法,包括:

接收规则配置请求,其中,所述规则配置请求中携带有目标业务对应的目标业务执行触发规则的规则标识和配置参数;

在预先存储的多个业务规则组件中,获取所述规则标识对应的目标业务规则组件,其中,所述业务规则组件包括业务执行触发规则对应的不包含配置参数的初始代码;

将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码;

当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。

可选地,所述规则配置请求中携带有多个规则标识,所述配置参数包括每个规则标识对应的配置参数,所述在预先存储的多个业务规则组件中,获取所述规则标识对应的目标业务规则组件步骤包括:

在预先存储的多个业务规则组件中,获取各规则标识对应的目标业务规则组件;

所述将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码步骤包括:

将每个规则标识对应的配置参数,分别添加到对应的目标业务规则组件中;

将添加配置参数后的各目标业务规则组件进行组合链接,得到所述目标业务执行触发规则对应的执行代码。

可选地,所述目标业务为应用程序更新查询业务,所述多个业务规则组件包括以下业务规则组件中的至少一个:

客户端版本规则组件,所述客户端版本规则组件用于判断终端中已安装的应用程序的版本号是否属于预设版本号集合;

系统版本规则组件,所述系统版本规则组件用于判断终端系统的系统号是否是预设系统号;

白名单规则组件,所述白名单规则组件用于判断终端是否是预设的白名单中的终端;

地理位置规则组件,所述地理位置规则组件用于判断终端位置是否属于预设地理区域;

终端品牌规则组件,所述终端品牌规则组件用于判断终端的品牌是否是预设品牌;

终端型号规则组件,所述终端型号规则组件用于判断终端型号是否是预设型号;

灰度上限规则组件,所述灰度上限规则组件用于判断服务器已发送的下载链接的总数目是否超过第一预设阈值;

下发频率规则组件,所述下发频率规则组件用于判断预设单位时长内服务器已发送的下载链接的数目是否超过第二预设阈值。

可选地,所述目标业务对应有多个目标业务执行触发规则,所述当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理步骤包括:

对各目标业务执行触发规则进行排序,并设置N为1;

确定排序在第N位的目标业务执行触发规则;

如果所述目标业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足所述第N位的目标业务执行触发规则,则确定所述第N位的目标业务执行触发规则对应的目标业务处理方式,基于所述目标业务处理方式对所述业务请求进行处理;

如果所述目标业务的业务请求中携带的终端相关信息或者获取的服务器当前的状态信息不满足所述第N位的目标业务执行触发规则,则将N加1,转至执行确定排序在第N位的目标业务执行触发规则步骤。

可选地,所述目标业务为应用程序更新查询业务,所述如果所述目标业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足所述第N位的目标业务执行触发规则,则确定所述第N位的目标业务执行触发规则对应的目标业务处理方式,基于所述目标业务处理方式对所述业务请求进行处理步骤包括:

如果所述应用程序更新查询业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足所述第N位的目标业务执行触发规则,则确定所述第N位的目标业务执行触发规则对应的目标测试版本的应用程序的下载链接、以及下载提示信息,向发送所述业务请求的终端,返回所述目标测试版本的应用程序的下载链接、以及所述下载提示信息。

可选地,所述向发送所述业务请求的终端,返回所述目标测试版本的应用程序的下载链接、以及所述下载提示信息步骤包括:

如果已设置所述目标测试版本的应用程序的下载状态为自动下载状态,则获取自动下载标志信息,向发送所述业务请求的终端返回所述目标测试版本的应用程序的下载链接、所述下载提示信息、以及所述自动下载标志信息;

如果未设置所述目标测试版本的应用程序的下载状态为自动下载状态,则向发送所述业务请求的终端,返回所述目标测试版本的应用程序的下载链接、以及所述下载提示信息。

可选地,所述当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理步骤包括:

将所述目标业务执行触发规则对应的执行代码关联到用于处理所述目标业务的业务请求的主线程上,以当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。

根据本公开实施例的第二方面,提供一种处理业务请求的装置,包括:

接收模块,被配置为接收规则配置请求,其中,所述规则配置请求中携带有目标业务对应的目标业务执行触发规则的规则标识和配置参数;

获取模块,被配置为在预先存储的多个业务规则组件中,获取所述规则标识对应的目标业务规则组件,其中,所述业务规则组件包括业务执行触发规则对应的不包含配置参数的初始代码;

添加模块,被配置为将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码;

执行模块,被配置为当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。

可选地,所述规则配置请求中携带有多个规则标识,所述配置参数包括每个规则标识对应的配置参数,所述获取模块,被配置为:

在预先存储的多个业务规则组件中,获取各规则标识对应的目标业务规则组件;

所述将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码步骤包括:

将每个规则标识对应的配置参数,分别添加到对应的目标业务规则组件中;

将添加配置参数后的各目标业务规则组件进行组合链接,得到所述目标业务执行触发规则对应的执行代码。

可选地,所述目标业务为应用程序更新查询业务,所述多个业务规则组件包括以下业务规则组件中的至少一个:

客户端版本规则组件,所述客户端版本规则组件用于判断终端中已安装的应用程序的版本号是否属于预设版本号集合;

系统版本规则组件,所述系统版本规则组件用于判断终端系统的系统号是否是预设系统号;

白名单规则组件,所述白名单规则组件用于判断终端是否是预设的白名单中的终端;

地理位置规则组件,所述地理位置规则组件用于判断终端位置是否属于预设地理区域;

终端品牌规则组件,所述终端品牌规则组件用于判断终端的品牌是否是预设品牌;

终端型号规则组件,所述终端型号规则组件用于判断终端型号是否是预设型号;

灰度上限规则组件,所述灰度上限规则组件用于判断服务器已发送的下载链接的总数目是否超过第一预设阈值;

下发频率规则组件,所述下发频率规则组件用于判断预设单位时长内服务器已发送的下载链接的数目是否超过第二预设阈值。

可选地,所述目标业务对应有多个目标业务执行触发规则,所述执行模块,被配置为:

对各目标业务执行触发规则进行排序,并设置N为1;

确定排序在第N位的目标业务执行触发规则;

当所述目标业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足所述第N位的目标业务执行触发规则时,确定所述第N位的目标业务执行触发规则对应的目标业务处理方式,基于所述目标业务处理方式对所述业务请求进行处理;

当所述目标业务的业务请求中携带的终端相关信息或者获取的服务器当前的状态信息不满足所述第N位的目标业务执行触发规则时,将N加1,转至执行确定排序在第N位的目标业务执行触发规则步骤。

可选地,所述目标业务为应用程序更新查询业务,所述执行模块,被配置为:

当所述应用程序更新查询业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足所述第N位的目标业务执行触发规则时,确定所述第N位的目标业务执行触发规则对应的目标测试版本的应用程序的下载链接、以及下载提示信息,向发送所述业务请求的终端,返回所述目标测试版本的应用程序的下载链接、以及所述下载提示信息。

可选地,所述执行模块,被配置为:

当已设置所述目标测试版本的应用程序的下载状态为自动下载状态时,获取自动下载标志信息,向发送所述业务请求的终端返回所述目标测试版本的应用程序的下载链接、所述下载提示信息、以及所述自动下载标志信息;

当未设置所述目标测试版本的应用程序的下载状态为自动下载状态时,向发送所述业务请求的终端,返回所述目标测试版本的应用程序的下载链接、以及所述下载提示信息。

可选地,所述执行模块,被配置为:

将所述目标业务执行触发规则对应的执行代码关联到用于处理所述目标业务的业务请求的主线程上,以当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。

根据本公开实施例的第三方面,提供一种服务器,包括:

处理器;

用于存储所述处理器可执行指令的存储器;

其中,所述处理器被配置为执行所述指令,以实现本公开实施例的第一方面所述的处理业务请求的方法。

根据本公开实施例提供的第四方面,提供一种存储介质,当所述存储介质中的指令由服务器的处理器执行时,使得服务器能够执行本公开实施例的第一方面所述的处理业务请求的方法。

根据本公开实施例的第五方面,提供一种计算机程序产品,包括:

接收规则配置请求,其中,所述规则配置请求中携带有目标业务对应的目标业务执行触发规则的规则标识和配置参数;

在预先存储的多个业务规则组件中,获取所述规则标识对应的目标业务规则组件,其中,所述业务规则组件包括业务执行触发规则对应的不包含配置参数的初始代码;

将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码;

当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。

本公开的实施例提供的技术方案至少带来以下有益效果:

通过本公开实施例提供的方法,可以预先将对应不同业务规则的业务规则组件存储在服务器中,在使用时,可以根据需求获取目标业务规则组件。目标业务规则组件为目标业务执行触发规则对应的标准化的初始代码。通过向目标业务规则组件中传入个性化设置的配置参数,可以使得目标业务规则组件实现不同的规则控制逻辑。这样,只需要将目标业务执行触发规则的规则标识发送至服务器,服务器就可以基于规则标识确定目标业务规则组件,再通过向目标业务规则组件中添加配置参数,就可获得目标业务执行触发规则对应的执行代码,最终可以达到服务器能够基于目标业务执行触发规则对终端发送的业务请求进行响应的效果,提高了变更业务执行触发规则的操作效率。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理,并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种处理业务请求的系统结构示意图;

图2是根据一示例性实施例示出的一种处理业务请求的方法的流程图;

图3是根据一示例性实施例示出的一种业务规则过滤链的结构示意图;

图4是根据一示例性实施例示出的一种处理业务请求的方法的流程图;

图5是根据一示例性实施例示出的一种处理业务请求的方法的流程图;

图6是根据一示例性实施例示出的一种处理业务请求的装置的结构框图;

图7是根据一示例性实施例示出的一种服务器的结构示意图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案,下面将结合附图,对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是,本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

本公开实施例提供一种处理业务请求的方法,该方法可以由服务器实现,并由计算机配合实现。如图1所示,当需要变更业务执行触发规则时,程序员可以在计算机的浏览器中打开目标web(World Wide Web,全球广域网)页面,通过在目标web页面中的相关操作来变更业务执行触发规则。当程序员在计算机中设置好变更后的业务执行触发规则时,计算机可以向服务器发送规则配置请求,服务器在接收到规则配置请求之后,就可以在服务器本地进行一些相应的设置,以最终变更业务执行触发规则。具体实现方式可以参见下面的实施例中描述的内容。

图2是根据一示例性实施例示出的一种处理业务请求的方法的流程图,如图2所示,处理业务请求的方法用于服务器中,包括以下步骤。

在步骤S210中,服务器接收规则配置请求。

其中,规则配置请求中携带有目标业务对应的目标业务执行触发规则的规则标识和配置参数。目标业务执行触发规则用于当满足目标业务执行触发规则时,触发执行目标业务。当不满足目标业务执行触发规则时,不执行目标业务。目标业务可以是灰度更新业务、热更新业务等业务,灰度更新业务还可以包括Android(Android是一种基于Linux的自由及开放源代码的操作系统)灰度更新业务和iOS(iOS是由设备公司开发的移动操作系统)灰度更新业务。热更新业务也可以称为增量更新业务,更新时只需下载安装更新部分的代码,再次打开时即可使用。

在实施中,当需要变更业务执行触发规则时,程序员可以在计算机的浏览器中打开目标web页面,在目标web页面中展示有需要变更的应用程序标识输入框、需要变更的应用程序对应的目标业务标识输入框。程序员可以输入需要变更的应用程序标识,例如,可以输入AAA应用程序的名称。程序员还可以输入需要变更的应用程序对应的目标业务标识,例如,AAA应用程序对应的可变更业务包括灰度更新业务、热更新业务等多个业务,程序员可以在输入框中的下拉菜单中选择需要变更的应用程序对应的目标业务。

接着,程序员可以在目标web页面中查看到备选的目标业务执行触发规则。例如,程序员选择需要变更的应用程序对应的目标业务为AAA应用程序的灰度更新业务,对应该业务,可设置的触发执行灰度更新的规则有客户端版本规则、系统版本规则、白名单规则、地理位置规则、渠道规则(也可称为手机品牌规则)、手机型号规则、灰度上限规则(当成功进行灰度更新的终端达到一定数量时,停止再为其他终端进行灰度更新),自动灰度规则(当设置过自动灰度规则时,进行灰度更新的终端不能单单查看是否存在更新版本的应用程序,同时要下载安装更新版本的应用程序)、下发频率规则(在一段单位时长内,当成功进行灰度更新的终端达到一定数量时,停止再为其他终端进行灰度更新)、ab实验规则(相同版本的应用程序中某些参数不同,让不同用户使用不同参数对应的应用程序,并调查哪种参数对应的应用程序的用户体验更佳)等规则。计算机可以在目标web页面的目标业务执行触发规则输入框的下拉菜单中展示上述多个规则供程序员选择,程序员可以根据实际需求,选择目标业务执行触发规则。

随后,程序员可以在目标web页面的目标业务执行触发规则的配置参数输入框中,输入目标业务执行触发规则的配置参数。例如,程序员选择的目标业务执行触发规则为“只有预设品牌手机可以进行灰度更新”,对应需要输入的配置参数为“X品牌”,这样只有X品牌手机可以进行灰度更新了。如果输入的配置参数为“Y品牌”,这样只有Y品牌手机可以进行灰度更新了。在应用中,程序员可以根据实际需求配置本次灰度更新多少终端,对哪个范围的老版本的客户端进行灰度更新,对哪些品牌手机进行灰度更新,不同品牌手机对应的下载CDN(Content Delivery Network,内容分发网络)链接,对哪些手机型号进行灰度更新,是否增加ab实验等。

在程序员在计算机的目标web页面中输入上述信息之后,计算机可以获取需要变更的应用程序标识、需要变更的应用程序的目标业务标识、目标业务执行触发规则的规则标识和目标业务执行触发规则的配置参数,将这些信息携带在规则配置请求中发送至服务器。服务器可以接收到计算机发送的规则配置请求,并获取规则配置请求中的需要变更的应用程序标识、需要变更的应用程序的目标业务标识、目标业务执行触发规则的规则标识和目标业务执行触发规则的配置参数,基于获取到的信息进行目标业务执行触发规则的变更处理。

在服务器中,可以设置用于对不同应用程序和不同业务进行目标业务执行触发规则的变更处理的业务规则系统,基于该业务规则系统实现目标业务执行触发规则的变更处理。

在服务器中,可以设置有数据库表,包括业务表和规则表。业务表用于存储目标业务对应的信息,规则表用于存储和目标业务关联的目标业务执行触发规则。

在步骤S220中,服务器在预先存储的多个业务规则组件中,获取规则标识对应的目标业务规则组件。

其中,业务规则组件包括业务执行触发规则对应的不包含配置参数的初始代码。

在实施中,业务规则组件可以是业务执行触发规则对应的初始代码(也可以称为业务执行触发规则对应的类),初始代码为标准化代码,它可以适用到任何场景任何环境中,但是初始代码中缺少配置参数,在将配置参数传入到初始代码中之后,也即生成类对应的对象之后,可以通过调用对象实现一些逻辑功能。例如,业务规则组件描述的逻辑是“只有预设品牌手机可以进行灰度更新”,但是其中缺少具体只有哪个品牌手机才可以进行灰度更新。可以预先编写好具有各种功能的业务规则组件,将这些业务规则组件进行存储,在需要时,向业务规则组件中传入具体的配置参数完成个性化设置并进行调用。

可选地,当目标业务为应用程序更新查询业务时,本公开实施例提供的多个业务规则组件可以包括但不限于以下业务规则组件:

客户端版本规则组件(对应客户端版本规则,预设版本号集合可以是低版本到高版本之间的所有版本组成的集合),客户端版本规则组件用于判断终端中已安装的应用程序的版本号是否属于预设版本号集合。

系统版本规则组件(对应系统版本规则),系统版本规则组件用于判断终端系统的系统号是否是预设系统号。

白名单规则组件(对应白名单规则),白名单规则组件用于判断终端是否是预设的白名单中的终端。

地理位置规则组件(对应地理位置规则),地理位置规则组件用于判断终端位置是否属于预设地理区域。

终端品牌规则组件(对应渠道规则),终端品牌规则组件用于判断终端的品牌是否是预设品牌。

终端型号规则组件(对应终端型号规则),终端型号规则组件用于判断终端型号是否是预设型号。

灰度上限规则组件(对应灰度上限规则),灰度上限规则组件用于判断服务器已发送的下载链接的总数目是否超过第一预设阈值。

下发频率规则组件(对应下发频率规则),下发频率规则组件用于判断预设单位时长内服务器已发送的下载链接的数目是否超过第二预设阈值。

可以根据实际需求扩展新的业务规则组件,新的业务规则组件对应着新的规则。例如,还可以增加用于自动让满足规则的终端下载并安装更新版本的应用程序的业务规则组件,在安装之前只弹窗对用户进行提示将要更新应用程序,但是不设置取消更新按键。还可以增加用于进行ab实验的业务规则组件,当终端满足第一规则时,将第一更新版本的应用程序的下载链接发送给该终端,当终端满足第二规则时,将第二更新版本的应用程序的下载链接发送给该终端。这样,不同终端会安装不同更新版本的应用程序,不同更新版本的应用程序之间存在较小的差异,通过收取用户体验,可以帮助应用程序的开发人员确定最终发布哪个更新版本的应用程序。

在步骤S230中,服务器将规则配置请求中携带的配置参数,添加到目标业务规则组件中,得到目标业务执行触发规则对应的执行代码。

在实施中,可以在JSON(JavaScript Object Notation,对象表示法)文件中存储配置参数,目标业务规则组件可以通过单独的JSON文件进行描述。可以将JSON文件中存储的配置参数传入目标业务规则组件,得到目标业务执行触发规则对应的执行代码。此时的执行代码是可以执行的,是可以实现某些特定逻辑功能的执行代码。

可选地,可以将业务规则组件和动作执行语句进行封装,得到业务规则过滤器。在规则过滤器中,不仅能判断是否满足一定的规则,在满足一定的规则之后,还可以执行预设逻辑动作(实现action操作)或者输出特定信息。

例如,渠道规则对应的业务规则过滤器不仅能判断终端的品牌是否是预设品牌(其中,预设品牌可以是两个品牌包括“X品牌”和“Y品牌”),而且在终端的品牌是“X品牌”的情况下能输出“A下载链接”,在终端的品牌是“Y品牌”的情况下能输出“B下载链接”(不同品牌终端需要从不同渠道下载更新版本的应用程序)。

可选地,规则标识可以一个也可以是多个。当规则配置请求中携带有多个规则标识时,配置参数包括每个规则标识对应的配置参数。可以将不同规则进行组合,当满足组合后的所有规则时,触发执行目标业务,否则不执行目标业务。例如,将“只有X品牌手机可以进行Android灰度更新”和“只有手机中已安装的应用程序的版本号在1.3.5至1.3.7之间的手机可以进行Android灰度更新”进行组合,变为“只有X品牌手机且手机中已安装的应用程序的版本号在1.3.5至1.3.7之间的手机可以进行Android灰度更新”。其中,X品牌手机的操作系统为Android操作系统。这样,当终端发送业务请求,并满足“只有X品牌手机且手机中已安装的应用程序的版本号在1.3.5至1.3.7之间的手机可以进行Android灰度更新”规则时,可以触发执行目标业务,否则不执行目标业务。

如果程序员设置的规则标识为多个,则规则配置请求中携带有多个规则标识,且规则配置请求中携带有每个规则标识对应的配置参数。服务器在接收到规则配置请求后,可以在预先存储的多个业务规则组件中,获取各规则标识对应的目标业务规则组件。将每个规则标识对应的配置参数,分别添加到对应的目标业务规则组件中。将添加配置参数后的各目标业务规则组件进行组合链接,得到目标业务执行触发规则对应的执行代码

如果已将业务规则组件封装为业务规则过滤器,则每个业务规则组件对应的业务规则过滤器之间都是独立的。如果需要组合业务规则组件,就可以将各业务规则过滤器进行组合链接,得到业务规则过滤链。可以在前一个业务规则过滤器中写入下一个要跳转的业务规则过滤器,这样就可以实现各业务规则过滤器的组合链接。因此,业务规则过滤链可以把需要组合的规则都链接起来,实现逻辑“与”的语义,即只有满足所有规则才能通过该业务规则过滤链。

业务规则过滤链的结构可以见图3所示,包括前业务规则过滤器子链、业务规则过滤器A、后业务规则过滤器子链。只有在前业务规则过滤器子链都通过的情况下,才能到达业务规则过滤器A,如果业务规则过滤器A也通过,可以判断后业务规则过滤器子链是否通过。如果后业务规则过滤器子链都通过,可以从最后一个业务规则过滤器倒序返回通过信息。可以在业务规则过滤器A中定义当接收到通过信息时,执行目标业务,例如,对于灰度更新,当接收到通过信息时,获取更新版本的应用程序的下载链接,将更新版本的应用程序的下载链接发送至终端。这样,当全部规则都满足时,就可以在业务规则过滤器A中处理满足事件,而无需将通过信息返回至第一个业务规则过滤器才能处理满足事件,即只要满足规则就实现action操作,无需将判断满足不满足规则和满足规则之后执行的逻辑动作分开。

在步骤S240中,当接收到目标业务的业务请求时,服务器基于执行代码对业务请求进行处理。

在实施中,在得到目标业务执行触发规则对应的执行代码之后,就可以让目标业务执行触发规则对应的执行代码生效,在服务器接收到目标业务的业务请求时,可以基于生效的执行代码对业务请求进行处理。

业务规则系统可以监听触发生效新任务的事件,新任务包含一个业务规则过滤器链。如图4所示,步骤S240可以包括:在步骤S441中,当监听到触发生效新任务的事件时,可以从数据库表中读取目标业务对应的信息、与目标业务关联的目标业务执行触发规则。在步骤S442中,可以解析新任务。在步骤S443中,可以解析与目标业务关联的目标业务执行触发规则,生成对应的业务规则过滤器,将所有的规则过滤器链接成一个业务规则过滤链。在步骤S444中,可以将业务规则过滤链关联到新任务上,并将任务加入到多任务控制模块中。服务器中可以设置有多任务控制模块,每个任务对应一个业务规则过滤链,当满足任何一个业务规则过滤链时,可以触发执行对应的业务,实现了逻辑“或”的语义。服务器可以支持多个业务需求,所有的开发人员或者测试人员都可以根据自己的需求随时配置目标业务执行触发规则,实现了应用程序的快速迭代和验证。

例如,对于灰度更新业务,开发人员可以设置同时对多个更新版本的应用程序进行灰度更新。当终端满足第一规则时,将第一更新版本的应用程序的下载链接发送给该终端,当终端满足第二规则时,将第二更新版本的应用程序的下载链接发送给该终端。这样,不同终端会安装不同更新版本的应用程序,不同更新版本的应用程序之间存在较小的差异,可以用于测试哪个更新版本的应用程序的用户体验更高。终端在开启应用程序时,可以触发发送应用程序更新查询请求。服务器在接收到应用程序更新查询请求之后,可以确定终端能够通过的目标业务规则过滤链,执行目标业务规则过滤链对应的业务。

可选地,解析与目标业务关联的目标业务执行触发规则以及将业务规则过滤链关联到新任务上的步骤可以包括:将目标业务执行触发规则对应的执行代码关联到用于处理目标业务的业务请求的主线程上,以当接收到目标业务的业务请求时,基于执行代码对业务请求进行处理。

在服务器中存在多个处理不同业务的业务请求的主线程,每个主线程可以对应一种业务。当服务器接收到一种业务的业务请求时,可以确定业务请求对应的目标业务种类,在目标业务种类对应的主线程中处理该业务请求。如果需要接入触发执行目标业务的规则,在得到目标业务执行触发规则对应的执行代码之后,可以将目标业务执行触发规则对应的执行代码关联到用于处理目标业务的业务请求的主线程上。这样,当服务器接收到目标业务的业务请求并进入对应的主线程处理业务请求时,可以调用目标业务执行触发规则对应的执行代码,进而可以实现当满足目标业务执行触发规则时执行目标业务的逻辑。

如图5所示,步骤S240可以包括:在步骤S541中,接收业务请求。在步骤S542中,通过业务控制模块获取目标业务关联的所有任务。在步骤S543中,遍历所有任务关联的业务规则过滤链,在每个业务规则过滤链中,基于终端相关信息和服务器当前的状态信息,按序判断是否能满足业务规则过滤链,直到确定出第一个能满足的业务规则过滤链或者确定全部业务规则过滤链都不能满足。在步骤S544中,当确定出第一个能满足的业务规则过滤链的同时,可以执行目标业务,如果目标业务是应用程序更新查询业务,则可以获取到目标测试版本的应用程序的下载链接、以及下载提示信息,将目标测试版本的应用程序的下载链接、以及下载提示信息返回至终端。

可选地,服务器中可以设置有业务管理模块,由于会有不同应用程序和不同业务需要接入业务规则系统,因此可以通过业务管理模块针对不同应用程序和不同业务进行规则的配置、更新和下发处理。例如,可以设置第一应用程序的第一业务的业务执行触发规则,也可以设置第二应用程序的第二业务的业务执行触发规则。可以根据实际需求设置不同应用程序的不同业务的业务执行触发规则,将不同应用程序的不同业务的业务执行触发规则接入到业务规则系统中,由业务规则系统统一进行管理。

当一个目标业务对应有多个目标业务执行触发规则时,如果接收到目标业务的业务请求,服务器则可以执行下述步骤:

(1)对各目标业务执行触发规则进行排序,并设置N为1。

(2)确定排序在第N位的目标业务执行触发规则。

(3)如果目标业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足第N位的目标业务执行触发规则,则确定第N位的目标业务执行触发规则对应的目标业务处理方式,基于目标业务处理方式对业务请求进行处理。

(4)如果目标业务的业务请求中携带的终端相关信息或者获取的服务器当前的状态信息不满足第N位的目标业务执行触发规则,则将N加1,转至执行步骤(2),从步骤(2)开始继续执行。

其中,终端相关信息可以包括终端中已安装的应用程序的版本号、终端系统的系统号、终端标识、终端位置、终端的品牌、终端型号等。服务器当前的状态信息可以包括服务器已发送的下载链接的总数目、预设单位时长内服务器已发送的下载链接的数目等。可以基于终端相关信息或者获取的服务器当前的状态信息,确定是否满足目标业务执行触发规则。

当一个目标业务对应有多个目标业务执行触发规则时,如果接收到目标业务的业务请求,服务器可以将先判断满足的目标业务执行触发规则对应的目标业务处理方式,作为处理对业务请求进行处理的业务处理方式。需要说明的是,在步骤(1)中,可以随机对各目标业务执行触发规则进行排序,或者每次调整上一次的排序,保证相近的几次排序不一样。

当目标业务为应用程序更新查询业务且一个目标业务对应有多个目标业务执行触发规则时,上述步骤(4)可以包括:如果应用程序更新查询业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足第N位的目标业务执行触发规则,则确定第N位的目标业务执行触发规则对应的目标测试版本的应用程序的下载链接、以及下载提示信息,向发送业务请求的终端,返回目标测试版本的应用程序的下载链接、以及下载提示信息。

例如,终端向服务器发送A应用程序的应用程序更新查询请求,服务器中对应A应用程序存储有两个进行灰度更新的不同测试版本的应用程序。两个进行灰度更新的不同测试版本的应用程序分别为P测试版本的应用程序和Q测试版本的应用程序,分别对应的目标业务执行触发规则为V规则和W规则。可以对V规则和W规则进行排序,例如第一位是W规则,第二位是V规则。可以先判断终端发送的终端相关信息和服务器获取到的本地的服务器当前的状态信息是否满足W规则,如果满足W规则,则将Q测试版本的应用程序的下载链接发送至终端。否则,判断终端发送的终端相关信息和服务器获取到的本地的服务器当前的状态信息是否满足V规则,如果满足V规则,则将P测试版本的应用程序的下载链接发送至终端。同时,还可以确定下载提示信息,将下载提示信息发送至终端,这样,终端可以对用户进行提示已检测到目标测试版本的应用程序,以及是否要下载目标测试版本的应用程序。

可选地,向发送业务请求的终端,返回目标测试版本的应用程序的下载链接、以及下载提示信息步骤可以包括:如果已设置目标测试版本的应用程序的下载状态为自动下载状态,则获取自动下载标志信息,向发送业务请求的终端返回目标测试版本的应用程序的下载链接、下载提示信息、以及自动下载标志信息;如果未设置目标测试版本的应用程序的下载状态为自动下载状态,则向发送业务请求的终端,返回目标测试版本的应用程序的下载链接、以及下载提示信息。

如果已设置目标测试版本的应用程序的下载状态为自动下载状态,可以通过配置自动灰度业务规则过滤器的方式实现。该业务规则过滤器中不存在判断逻辑,存在动作执行逻辑,比如获取自动下载标志信息。当通过业务规则过滤器链并返回通过信息时,在通过信息传回到自动灰度业务规则器时,自动灰度业务规则器可以获取自动下载标志信息。最终业务规则过滤链可以输出自动下载标志信息,服务器可以将目标测试版本的应用程序的下载链接、下载提示信息、以及自动下载标志信息发送至终端。

在终端接收到自动下载标志信息时,终端对用户进行提示已检测到目标测试版本的应用程序,但是不会再询问用户是否要下载目标测试版本的应用程序,在弹出对用户进行提示的弹窗预设时长之后,自动下载并安装目标测试版本的应用程序。

通过本公开实施例提供的方法,可以预先将对应不同业务规则的业务规则组件存储在服务器中,在使用时,可以根据需求获取目标业务规则组件。目标业务规则组件为目标业务执行触发规则对应的标准化的初始代码。通过向目标业务规则组件中传入个性化设置的配置参数,可以使得目标业务规则组件实现不同的规则控制逻辑。这样,只需要将目标业务执行触发规则的规则标识发送至服务器,服务器就可以基于规则标识确定目标业务规则组件,再通过向目标业务规则组件中添加配置参数,就可获得目标业务执行触发规则对应的执行代码,最终可以达到服务器能够基于目标业务执行触发规则对终端发送的业务请求进行响应的效果,提高了变更业务执行触发规则的操作效率。

图6是根据一示例性实施例示出的一种处理业务请求的装置框图。该装置可以包括:

接收模块610,被配置为接收规则配置请求,其中,所述规则配置请求中携带有目标业务对应的目标业务执行触发规则的规则标识和配置参数;

获取模块620,被配置为在预先存储的多个业务规则组件中,获取所述规则标识对应的目标业务规则组件,其中,所述业务规则组件包括业务执行触发规则对应的不包含配置参数的初始代码;

添加模块630,被配置为将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码;

执行模块640,被配置为当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。

可选地,所述规则配置请求中携带有多个规则标识,所述配置参数包括每个规则标识对应的配置参数,所述获取模块620,被配置为:

在预先存储的多个业务规则组件中,获取各规则标识对应的目标业务规则组件;

所述将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码步骤包括:

将每个规则标识对应的配置参数,分别添加到对应的目标业务规则组件中;

将添加配置参数后的各目标业务规则组件进行组合链接,得到所述目标业务执行触发规则对应的执行代码。

可选地,所述目标业务为应用程序更新查询业务,所述多个业务规则组件包括以下业务规则组件中的至少一个:

客户端版本规则组件,所述客户端版本规则组件用于判断终端中已安装的应用程序的版本号是否属于预设版本号集合;

系统版本规则组件,所述系统版本规则组件用于判断终端系统的系统号是否是预设系统号;

白名单规则组件,所述白名单规则组件用于判断终端是否是预设的白名单中的终端;

地理位置规则组件,所述地理位置规则组件用于判断终端位置是否属于预设地理区域;

终端品牌规则组件,所述终端品牌规则组件用于判断终端的品牌是否是预设品牌;

终端型号规则组件,所述终端型号规则组件用于判断终端型号是否是预设型号;

灰度上限规则组件,所述灰度上限规则组件用于判断服务器已发送的下载链接的总数目是否超过第一预设阈值;

下发频率规则组件,所述下发频率规则组件用于判断预设单位时长内服务器已发送的下载链接的数目是否超过第二预设阈值。

可选地,所述目标业务对应有多个目标业务执行触发规则,所述执行模块640,被配置为:

对各目标业务执行触发规则进行排序,并设置N为1;

确定排序在第N位的目标业务执行触发规则;

当所述目标业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足所述第N位的目标业务执行触发规则时,确定所述第N位的目标业务执行触发规则对应的目标业务处理方式,基于所述目标业务处理方式对所述业务请求进行处理;

当所述目标业务的业务请求中携带的终端相关信息或者获取的服务器当前的状态信息不满足所述第N位的目标业务执行触发规则时,将N加1,转至执行确定排序在第N位的目标业务执行触发规则步骤。

可选地,所述目标业务为应用程序更新查询业务,所述执行模块640,被配置为:

当所述应用程序更新查询业务的业务请求中携带的终端相关信息和获取的服务器当前的状态信息满足所述第N位的目标业务执行触发规则时,确定所述第N位的目标业务执行触发规则对应的目标测试版本的应用程序的下载链接、以及下载提示信息,向发送所述业务请求的终端,返回所述目标测试版本的应用程序的下载链接、以及所述下载提示信息。

可选地,所述执行模块640,被配置为:

当已设置所述目标测试版本的应用程序的下载状态为自动下载状态时,获取自动下载标志信息,向发送所述业务请求的终端返回所述目标测试版本的应用程序的下载链接、所述下载提示信息、以及所述自动下载标志信息;

当未设置所述目标测试版本的应用程序的下载状态为自动下载状态时,向发送所述业务请求的终端,返回所述目标测试版本的应用程序的下载链接、以及所述下载提示信息。

可选地,所述执行模块640,被配置为:

将所述目标业务执行触发规则对应的执行代码关联到用于处理所述目标业务的业务请求的主线程上,以当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。

通过本公开实施例提供的装置,可以预先将对应不同业务规则的业务规则组件存储在服务器中,在使用时,可以根据需求获取目标业务规则组件。目标业务规则组件为目标业务执行触发规则对应的标准化的初始代码。通过向目标业务规则组件中传入个性化设置的配置参数,可以使得目标业务规则组件实现不同的规则控制逻辑。这样,只需要将目标业务执行触发规则的规则标识发送至服务器,服务器就可以基于规则标识确定目标业务规则组件,再通过向目标业务规则组件中添加配置参数,就可获得目标业务执行触发规则对应的执行代码,最终可以达到服务器能够基于目标业务执行触发规则对终端发送的业务请求进行响应的效果,提高了变更业务执行触发规则的操作效率。

关于上述实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。

图7示出了本公开一个示例性实施例提供的服务器1900的结构示意图。该服务器1900可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上处理器(centralprocessing units,CPU)1910和一个或一个以上的存储器1920。其中,所述存储器1920中存储有至少一条指令,所述至少一条指令由所述处理器1910加载并执行以实现上述实施例所述的处理业务请求的方法。

在示例性实施例中,还提供了一种包括指令的非临时性计算机可读存储介质,例如包括指令的存储器1920,上述指令可由服务器1900的处理器1910执行以完成上述处理业务请求的方法,该方法包括:接收规则配置请求,其中,所述规则配置请求中携带有目标业务对应的目标业务执行触发规则的规则标识和配置参数;在预先存储的多个业务规则组件中,获取所述规则标识对应的目标业务规则组件,其中,所述业务规则组件包括业务执行触发规则对应的不包含配置参数的初始代码;将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码;当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。例如,所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中,还提供了一种应用程序,包括一条或多条指令,该一条或多条指令可以由服务器1900的处理器1910执行,以完成上述处理业务请求的方法,该方法包括:接收规则配置请求,其中,所述规则配置请求中携带有目标业务对应的目标业务执行触发规则的规则标识和配置参数;在预先存储的多个业务规则组件中,获取所述规则标识对应的目标业务规则组件,其中,所述业务规则组件包括业务执行触发规则对应的不包含配置参数的初始代码;将所述规则配置请求中携带的所述配置参数,添加到所述目标业务规则组件中,得到所述目标业务执行触发规则对应的执行代码;当接收到所述目标业务的业务请求时,基于所述执行代码对所述业务请求进行处理。可选地,上述指令还可以由服务器1900的处理器1910执行以完成上述示例性实施例中所涉及的其他步骤。

本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本发明的真正范围和精神由下面的权利要求指出。

应当理解的是,本发明并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

相关技术
  • 业务请求的处理方法、装置、服务器及存储介质
  • 一种业务请求处理方法、装置、服务器和存储介质
技术分类

06120112159296