一种业务请求报文数据的处理方法和装置与流程

文档序号:24980407发布日期:2021-05-07 22:55阅读:68来源:国知局
一种业务请求报文数据的处理方法和装置与流程

本发明涉及数据处理技术领域,特别涉及一种业务请求报文数据的处理方法和装置。



背景技术:

传统的网络应用大多采用单体架构,也就是将应用程序的所有功能都打包成一个独立的单元部署在一个中心服务器上,中心服务器不但要对接所有外来业务请求,还要根据业务请求调用系统内部不同的功能模块进行处理。这种系统架构的优点是开发周期短、部署简单,但缺点也很明显:处理高并发难度大、功能迭代升级速度慢。

为满足互联网应用高并发和功能快速迭代的需求,近年来,人们开始使用微服务架构来搭建应用系统。在微服务架构下,应用系统的所有功能可拆解为多个独立子服务,这些子服务可以部署在不同的服务器上独立运行,这些子服务间的应用程序接口(applicationprogramminginterface,api)从传统单体架构内部的类、函数调用接口,变为服务器间的超文本传输协议(hypertexttransferprotocol,http)格式的业务请求报文接口。如此一来,中心服务器的业务处理流程可以被多个分布式子服务器接管,外来业务请求甚至可以直接发送至子服务器上进行处理,从而提高了应用系统对高并发的处理能力、和对快速升级的响应能力。

但是,我们在实际实施部署中,也发现了一些问题,若直接将所有子服务都部署在公网上,子服务需要预备额外的软硬件资源来处理发自不同客户端的业务请求,另外还要申请多个公网地址对服务器进行部署,同时还会使得系统面临攻击的风险增大。

为了兼顾灵活部署与安全运维,我们采用了一种折中的处理方式,在所有子服务与外部业务请求之间,增加一个业务请求转发层,该转发层主要负责对业务请求报文进行校验和转发。



技术实现要素:

本发明的目的,就是针对现有技术的缺陷,提供一种业务请求报文数据的处理方法、装置、电子设备、计算机程序产品及计算机可读存储介质,实现上述业务请求转发层的功能,将接收的业务请求报文数据中的统一资源定位符(uniformresourcelocator,url)信息做为请求路径,并通过查询预先配置的反映请求路径与转发主机地址及转发路径对应关系的第一对应关系表,得到对应的转发路径,并按转发路径向实际处理业务的服务器发送业务请求参数,并在接收和转发时,完成对业务请求报文数据的权限校验和授权参数准备等操作;这样一来,只需将具备本发明实施例功能的服务部署在公网上即可,既降低了应用系统整体受攻击的风险,又降低了子服务上用于处理业务请求的软硬件开销。

为实现上述目的,本发明实施例第一方面提供了一种业务请求报文数据的处理方法,所述方法包括:

获取第一业务请求报文数据;

对所述第一业务请求报文数据,进行请求权限校验处理;

所述请求权限校验处理成功,则按超文本传输协议http协议的请求报文数据格式,对所述第一业务请求报文数据的请求行的统一资源定位符url信息,进行路径信息与参数信息的拆解处理,生成对应的第一请求路径数据和第一参数数据组;

根据所述第一请求路径数据,查询预设的反映请求路径与转发主机地址及转发路径对应关系的第一对应关系表,生成对应的第一主机地址数据和第二请求路径数据;

按http协议的请求报文数据格式,将所述第二请求路径数据做为请求报文请求行的url信息,将所述第一主机地址数据做为请求报文请求头的主机字段信息,将所述第一参数数据组做为请求报文的请求体,拼装生成第二业务请求报文数据;并向所述第一主机地址数据对应的第一服务器,发送所述第二业务请求报文数据。

优选的,所述对所述第一业务请求报文数据,进行请求权限校验处理,具体包括:

按http协议的请求报文数据格式,对所述第一业务请求报文数据的请求体中的所有字段进行提取,生成第一字段数据组集合;所述第一字段数据组集合包括多个第一字段数据组;所述第一字段数据组包括第一字段名数据和第一字段内容数据;

在所述第一字段数据组集合中,根据预设的授权令牌字段名信息和授权校验码字段名信息,进行令牌字段查询处理,并根据查询结果生成第一授权类型数据;

当所述第一授权类型数据为令牌授权类型时,提取与所述授权令牌字段名信息对应的所述第一字段数据组的所述第一字段内容数据,做为第一令牌数据;并根据所述第一令牌数据,进行第一令牌校验处理;若所述第一令牌校验处理成功,则所述请求权限校验处理成功;

当所述第一授权类型数据为校验码授权类型时,提取与所述授权校验码字段名信息对应的所述第一字段数据组的所述第一字段内容数据,做为第一校验码数据;并根据所述第一校验码数据,进行第一校验码校验处理;若所述第一校验码校验处理成功,则所述请求权限校验处理成功;

当所述第一授权类型数据为令牌及校验码授权类型时,提取与所述授权令牌字段名信息对应的所述第一字段数据组的所述第一字段内容数据,做为第二令牌数据,并提取与所述授权校验码字段名信息对应的所述第一字段数据组的所述第一字段内容数据,做为第二校验码数据;并根据所述第二令牌数据,进行第二令牌校验处理;并根据所述第二校验码数据,进行第二校验码校验处理;若所述第二令牌校验处理成功、且所述第二校验码校验处理成功,则所述请求权限校验处理成功。

进一步的,所述在所述第一字段数据组集合中,根据预设的授权令牌字段名信息和授权校验码字段名信息,进行令牌字段查询处理,并根据查询结果生成第一授权类型数据,具体包括:

初始化第一状态数据和第二状态数据为空;

在所述第一字段数据组集合中,对所有所述第一字段名数据进行轮询,当被轮询的所述第一字段名数据与所述授权令牌字段名信息匹配时,设置所述第一状态数据为成功状态;

在所述第一字段数据组集合中,对所有所述第一字段名数据进行轮询,当被轮询的所述第一字段名数据与所述授权校验码字段名信息匹配时,设置所述第二状态数据为成功状态;

当所述第一状态数据为所述成功状态、且所述第二状态数据为空时,将所述第一授权类型数据设为所述令牌授权类型;当所述第一状态数据为空、且所述第二状态数据为所述成功状态时,将所述第一授权类型数据设为所述校验码授权类型;当所述第一状态数据和所述第二状态数据均为所述成功状态时,将所述第一授权类型数据设为所述令牌及校验码授权类型。

优选的,所述根据所述第一请求路径数据,查询预设的反映请求路径与转发主机地址及转发路径对应关系的第一对应关系表,生成对应的第一主机地址数据和第二请求路径数据,具体包括:

根据所述第一请求路径数据,对所述第一对应关系表的所有第一对应关系记录进行轮询;当被轮询的所述第一对应关系记录的第一请求路径字段与所述第一请求路径数据匹配时,提取被轮询的所述第一对应关系记录的第一转发主机地址字段,做为所述第一主机地址数据;并提取被轮询的所述第一对应关系记录的第一转发路径字段,做为所述第二请求路径数据;所述第一对应关系表包括多个所述第一对应关系记录;所述第一对应关系记录包括所述第一请求路径字段、所述第一转发主机地址字段和所述第一转发路径字段。

优选的,所述拼装生成第二业务请求报文数据时,所述方法还包括:

根据所述第一主机地址数据,对预设的反映主机地址与主机授权参数集合对应关系的第二对应关系表的所有第二对应关系记录进行轮询;当被轮询的所述第二对应关系记录的第一主机地址字段与所述第一主机地址数据匹配时,提取被轮询的所述第二对应关系记录的第一主机授权参数集合字段,做为第一授权参数集合;根据所述第一授权参数集合,进行校验信息准备处理,并将准备处理得到的结果按http协议的请求报文数据格式,添加至所述第二业务请求报文数据的请求头中;所述第二对应关系表包括多个所述第二对应关系记录;所述第二对应关系记录包括所述第一主机地址字段和所述第一主机授权参数集合字段。

本发明实施例第二方面提供了一种业务请求报文数据的处理装置,包括:

获取模块用于获取第一业务请求报文数据;

权限校验模块用于对所述第一业务请求报文数据,进行请求权限校验处理;

业务请求转发模块用于在所述请求权限校验处理成功,则按超文本传输协议http协议的请求报文数据格式,对所述第一业务请求报文数据的请求行的统一资源定位符url信息,进行路径信息与参数信息的拆解处理,生成对应的第一请求路径数据和第一参数数据组;并根据所述第一请求路径数据,查询预设的反映请求路径与转发主机地址及转发路径对应关系的第一对应关系表,生成对应的第一主机地址数据和第二请求路径数据;并按http协议的请求报文数据格式,将所述第二请求路径数据做为请求报文请求行的url信息,将所述第一主机地址数据做为请求报文请求头的主机字段信息,将所述第一参数数据组做为请求报文的请求体,拼装生成第二业务请求报文数据;并向所述第一主机地址数据对应的第一服务器,发送所述第二业务请求报文数据。

本发明实施例第三方面提供了一种电子设备,包括:存储器、处理器和收发器;

所述处理器用于与所述存储器耦合,读取并执行所述存储器中的指令,以实现上述第一方面所述的方法步骤;

所述收发器与所述处理器耦合,由所述处理器控制所述收发器进行消息收发。

本发明实施例第四方面提供了一种计算机程序产品,所述计算机程序产品包括计算机程序代码,当所述计算机程序代码被计算机执行时,使得所述计算机执行上述第一方面所述的方法。

本发明实施例第五方面提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机指令,当所述计算机指令被计算机执行时,使得所述计算机执行上述第一方面所述的方法的指令。

本发明实施例提供一种业务请求报文数据的处理方法、装置、电子设备、计算机程序产品及计算机可读存储介质,将接收的业务请求报文数据中的url信息做为请求路径,并通过查询预先配置的反映请求路径与转发主机地址及转发路径对应关系的第一对应关系表,得到对应的转发路径,并按转发路径向实际处理业务的服务器发送业务请求参数,并在接收和转发时,完成对业务请求报文数据的权限校验和授权参数准备等操作;这样一来,只需将具备本发明实施例功能的服务部署在公网上即可,既降低了应用系统整体受攻击的风险,又降低了子服务上用于处理业务请求的软硬件开销。

附图说明

图1为本发明实施例一提供的一种业务请求报文数据的处理方法示意图;

图2为本发明实施例一提供的基于微服务架构的应用系统结构示意图;

图3为本发明实施例一提供的http请求报文数据格式示意图;

图4为本发明实施例二提供的一种业务请求报文数据的处理装置的模块结构图;

图5为本发明实施例三提供的一种电子设备的结构示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述,显然,所描述的实施例仅仅是本发明一部份实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。

本发明实施例一提供一种业务请求报文数据的处理方法,如图1为本发明实施例一提供的一种业务请求报文数据的处理方法示意图所示,本方法主要包括如下步骤:

步骤1,获取第一业务请求报文数据。

这里,为方便进行说明,以图2为本发明实施例一提供的基于微服务架构的应用系统结构示意图所描述的应用系统作为示例进行说明,该应用系统由多个子服务与一个系统数据库组成,多个子服务包括业务请求转发子服务、产品子服务、订单子服务和其他子服务组成,业务请求转发子服务为该应用系统对接公网业务请求的子服务,其余子服务均在应用系统内网,不与外部网络直接连接;第一业务请求报文数据为外部客户端向应用系统发送的业务请求报文数据,由业务请求转发子服务负责接收和转发;第一业务请求报文数据的数据格式为http协议的请求报文格式;http协议的请求报文格式如图3为本发明实施例一提供的http请求报文数据格式示意图所示,第一业务请求报文数据的报文中包括请求行、请求头和请求体三部分,请求行与请求头之间采用回车换行符进行隔离,请求头与请求体之间多一个空行也就是使用两组回车换行符进行隔离;请求行中包括三个信息:请求方法信息、url信息和协议版本信息,三个信息之间采用空格符进行隔离;请求方法信息包括get、post、head、put、delete、trace、options和connect等八种方法,本发明实施例中第一业务请求报文数据的请求方法信息常规都为get方法;url信息的内容与请求方法信息对应,当请求方法信息为get方法时,url的数据的内容中包括路径信息和参数信息,路径信息与参数信息之间使用隔离符“?”进行隔离,参数间使用隔离符“&”进行隔离;协议版本信息为当前http报文的版本信息,例如http/1.1;请求头由多组字段组成,每组字段包括字段名和字段内容,字段名与字段内容之间,使用隔离符“:”进行隔离,字段与字段之间使用回车换行符进行隔离;请求体也与请求方法信息有对应关系,当请求方法信息为get方法时,第一业务请求报文数据中不包含请求体。

例如,第一业务请求报文数据如表一所示,则,

请求行中请求方法信息为get方法,url信息为“/business/product/getlist?product_id=1&product_id=2”,路径信息为“/business/product/getlist”,参数包括两个:product_id=1、product_id=2,协议版本信息为“http/1.1”;

请求头中有10组字段:host、user-agent、accept、accept-language、origin、connection、pragma、cache-control和token字段,其中前9个字段都是http协议的标准字段,token字段为应用自定义的授权令牌字段;因为请求方法信息为get方法,所以第一业务请求报文数据不含请求体部分。

表一

步骤2,对第一业务请求报文数据,进行请求权限校验处理;

这里,在实际应用中,为防止响应未授权客户端发送的业务请求报文,每个应用系统都会对业务请求报文进行合法请求的权限验证,具体的验证过程就是从请求报文的请求头中提取出相关的自定义字段的字段内容进行验证;

具体包括:步骤21,按http协议的请求报文数据格式,对第一业务请求报文数据的请求体中的所有字段进行提取,生成第一字段数据组集合;

其中,第一字段数据组集合包括多个第一字段数据组;第一字段数据组包括第一字段名数据和第一字段内容数据;

这里,图2的业务请求转发子服务对第一业务请求报文数据的请求体中的多个字段进行数据提取;

例如,第一业务请求报文数据如表一所示,则第一字段数据组集合包含10组字段:

1)host字段的内容为“www.company.net”,

2)user-agent字段的内容为“mozilla/5.0(macintosh;intelmacosx10.15;rv:84.0)gecko/20100101firefox/84.0”,

3)accept字段的内容为“application/json,text/plain,*/*”,

4)accept-language字段的内容为“zh-cn”,

5)accept-encoding字段的内容为“gzip,deflate”,

6)origin字段的内容为“http://www.app.com”,

7)connection字段的内容为“keep-alive”,

8)pragma字段的内容为“no-cache”,

9)cache-control字段的内容为“no-cache”,

10)token字段的内容为:

“rexbz3rqregvvutxogreylvzm2xxd2r6d1vlufo2b05mk1ory0g3etmxmu1vqwf6wedztdjhqjhqzzhmt1ixa2kztmtts1hrvng1s3byy01ccgn5r0e9pq==”;

步骤22,在第一字段数据组集合中,根据预设的授权令牌字段名信息和授权校验码字段名信息,进行令牌字段查询处理,并根据查询结果生成第一授权类型数据;

这里,授权令牌字段名信息为预先设定的用于识别授权令牌字段名的信息,默认为“token”,授权校验码字段名信息为预先设定的用于识别授权校验码字段名的信息,默认为“auth-app-sign”;

具体包括:步骤221,初始化第一状态数据和第二状态数据为空;

步骤222,在第一字段数据组集合中,对所有第一字段名数据进行轮询,当被轮询的第一字段名数据与授权令牌字段名信息匹配时,设置第一状态数据为成功状态;

这里,图2的业务请求转发子服务在第一字段数据组集合包含的所有字段中,查找字段名为授权令牌字段名信息也就是“token”的字段,若该字段存在,将第一状态数据设为成功状态,说明第一业务请求报文数据中携带了用于识别身份的授权令牌数据,后续步骤需要将授权令牌数据从请求头中提取出来,并对该授权令牌数据进行校验;

步骤223,在第一字段数据组集合中,对所有第一字段名数据进行轮询,当被轮询的第一字段名数据与授权校验码字段名信息匹配时,设置第二状态数据为成功状态;

这里,图2的业务请求转发子服务在第一字段数据组集合包含的所有字段中,查找字段名为授权校验码字段名信息也就是“auth-app-sign”的字段,若该字段存在,将第二状态数据设为成功状态,说明第一业务请求报文数据中携带了用于识别身份的授权校验码数据以及用于计算该校验码的相关数据,后续步骤需要将授权校验码数据以及用于计算该校验码的相关数据从请求头中提取出来,并对该授权校验码数据进行校验;

步骤224,当第一状态数据为成功状态、且第二状态数据为空时,将第一授权类型数据设为令牌授权类型;当第一状态数据为空、且第二状态数据为成功状态时,将第一授权类型数据设为校验码授权类型;当第一状态数据和第二状态数据均为成功状态时,将第一授权类型数据设为令牌及校验码授权类型;

这里,若第一状态数据为成功状态、第二状态数据为空,说明第一业务请求报文数据只包含了授权令牌数据,将第一授权类型数据设为令牌授权类型,是为了告知后续步骤只需进行授权令牌校验;当第一状态数据为空、第二状态数据为成功状态,说明第一业务请求报文数据只包含了授权校验码数据,将第一授权类型数据设为校验码授权类型,是为了告知后续步骤只需进行授权校验码校验;当第一、二状态数据均为成功状态,说明第一业务请求报文数据不仅包含了授权令牌数据,还包含了授权校验码数据,将第一授权类型数据设为令牌及校验码授权类型,是为了告知后续步骤不仅要做授权令牌校验、还要做授权校验码校验;

例如,第一业务请求报文数据如表二所示时,则第一授权类型数据就为令牌授权类型;

表二

第一业务请求报文数据如表三所示时,则第一授权类型数据就为校验码授权类型;

表三

第一业务请求报文数据如表四所示时,则第一授权类型数据就为令牌及校验码授权类型;

表四

步骤23,当第一授权类型数据为令牌授权类型时,提取与授权令牌字段名信息对应的第一字段数据组的第一字段内容数据,做为第一令牌数据;并根据第一令牌数据,进行第一令牌校验处理;若第一令牌校验处理成功,则请求权限校验处理成功;

这里,授权令牌是图2中的应用系统为每一个能够使用系统服务的客户端分配的固定身份令牌信息,一般会将其存储在系统数据库中;当第一授权类型数据为令牌授权类型时,图2的业务请求转发子服务会从系统数据库中读出与客户端对应的令牌信息,并用其与第一业务请求报文数据中提取出的第一令牌数据进行比较,若二者相同则说明第一令牌校验处理成功,反之为失败;若第一令牌校验处理成功,则请求权限校验处理也被视为成功,反之被视为失败;若请求权限校验处理成功,则继续后续步骤,若请求权限校验处理失败,则业务请求转发子服务会退出当前正在进行的请求报文数据处理流程,并向客户端返回预先设定的错误处理响应报文;

例如,第一业务请求报文数据如表二所示,第一授权类型数据为令牌授权类型,授权令牌字段名信息为“token”,则与“token”对应的第一字段数据组的第一字段内容数据也就是第一令牌数据为“rexbz3rqregvvutxogreylvzm2xxd2r6d1vlufo2b05mk1ory0g3etmxmu1vqwf6wedztdjhqjhqzzhmt1ixa2kztmtts1hrvng1s3byy01ccgn5r0e9pq==”,业务请求转发子服务从系统数据库中读出的与客户端对应的令牌信息与第一令牌数据一致,则第一令牌校验处理成功、请求权限校验处理成功;

步骤24,当第一授权类型数据为校验码授权类型时,提取与授权校验码字段名信息对应的第一字段数据组的第一字段内容数据,做为第一校验码数据;并根据第一校验码数据,进行第一校验码校验处理;若第一校验码校验处理成功,则请求权限校验处理成功;

这里,图2中的应用系统除了可以使用为客户端分配的固定身份令牌信息对其进行校验之外,还可以使用动态的授权校验码对其进行校验;授权校验码的计算方法有多种,常见的方法是,应用系统预先为客户端分配一个应用标识和一个应用密钥,在每次发送业务请求报文时,客户端临时生成一个时间戳,再根据与应用系统预先约定好的数字摘要算法,例如信息摘要(message-digest,md)-5算法,对由应用标识+应用密钥+时间戳组成的连续数据进行md-5数字摘要计算,并将计算的结果做为授权校验码上传应用系统;这里,每次与授权校验码一起上传的还包括用于计算该校验码的应用标识和时间戳;这里,时间戳因为每次都不一样,所以在计算的时候将其做为计算因子,可以每次得到不同的授权校验码,达到一次一密的效果;另外,不传输应用密钥是为了保证第三方不可通过网络拦截,获得计算摘要的全部信息,达到无法复制身份的效果;图2的业务请求转发子服务在得到第一业务请求报文数据之后,从中提取出应用标识,并根据该应用标识从系统数据库中得到对应的应用密钥,再按照与客户端相同的计算过程,对应用标识+应用密钥+时间戳组成的连续数据进行md-5数字摘要计算,得到一个用于比较的校验码数据,若该校验码数据与从第一业务请求报文数据中提取出的第一校验码数据相同,则说明第一校验码校验处理成功,反之则为失败;若第一校验码校验处理成功,则请求权限校验处理成功,反之则为失败;若请求权限校验处理成功,则继续后续步骤,若请求权限校验处理失败,则业务请求转发子服务会退出当前正在进行的请求报文数据处理流程,并向客户端返回预先设定的错误处理响应报文;

例如,第一业务请求报文数据如表三所示,第一授权类型数据为校验码授权类型,授权校验码字段名信息为“auth-app-sign”,则与“auth-app-sign”对应的第一字段数据组的第一字段内容数据也就是第一校验码数据为“xkaqq1juzhrnflemwhvwaoi9smn2cfrj9evpyscy1jy=”,另外,与之相关的数据还包括应用标识也就是“auth-app-id”对应的第一字段数据组的第一字段内容数据为“10002”,时间戳也就是“client-timestamp”对应的第一字段数据组的第一字段内容数据为“1608125130”;图2的业务请求转发子服务从系统数据库中查出与应用标识“10002”对应的应用密钥为key1;业务请求转发子服务对应用标识“10002”+应用密钥key1+时间戳“1608125130”组成的连续数据进行md-5数字摘要计算,得到的哈希数据与第一校验码数据相同,则第一校验码校验处理成功、请求权限校验处理成功;

步骤25,当第一授权类型数据为令牌及校验码授权类型时,提取与授权令牌字段名信息对应的第一字段数据组的第一字段内容数据,做为第二令牌数据,并提取与授权校验码字段名信息对应的第一字段数据组的第一字段内容数据,做为第二校验码数据;并根据第二令牌数据,进行第二令牌校验处理;并根据第二校验码数据,进行第二校验码校验处理;若第二令牌校验处理成功、且第二校验码校验处理成功,则请求权限校验处理成功。

这里,若第一授权类型数据为令牌及校验码授权类型,说明图2中的应用系统除了为客户端分配了固定身份令牌信息,还为其分配了应用标识和应用密钥,所以每次进行请求报文的权限校验时,既要验证授权令牌还要验证授权校验码,只有二者都通过验证才说明请求权限校验处理成功,反之为失败;这里,验证授权令牌和验证授权校验码的处理过程与步骤23、24类似,不做进一步赘述。

步骤3,请求权限校验处理成功,则按http协议的请求报文数据格式,对第一业务请求报文数据的请求行的url信息,进行路径信息与参数信息的拆解处理,生成对应的第一请求路径数据和第一参数数据组。

例如,第一业务请求报文数据如表二所示时,则url信息为“/business/product/getlist?product_id=1&product_id=2”,参考步骤1的拆解描述,第一请求路径数据为“/business/product/getlist”,第一参数数据组包括两个第一参数数据:第1个第一参数数据为product_id=1、第2个第一参数数据为product_id=2。

步骤4,根据第一请求路径数据,查询预设的反映请求路径与转发主机地址及转发路径对应关系的第一对应关系表,生成对应的第一主机地址数据和第二请求路径数据;

具体包括:根据第一请求路径数据,对第一对应关系表的所有第一对应关系记录进行轮询;当被轮询的第一对应关系记录的第一请求路径字段与第一请求路径数据匹配时,提取被轮询的第一对应关系记录的第一转发主机地址字段,做为第一主机地址数据;并提取被轮询的第一对应关系记录的第一转发路径字段,做为第二请求路径数据;

其中,第一对应关系表包括多个第一对应关系记录;第一对应关系记录包括第一请求路径字段、第一转发主机地址字段和第一转发路径字段。

这里,如前文所述,第一对应关系表为预设在图2中业务请求转发子服务本地或者系统数据库中的数据表项;每个第一对应关系记录对应一个具体的请求路径;第一对应关系记录中的第一请求路径字段用于存储该对应的请求路径;第一转发主机地址字段用于存储处理当前请求路径对应功能的子服务的第一服务器主机地址,该地址可以为具体的网际互连协议(internetprotocol,ip)地址和或端口信息,例如,192.168.0.1或192.168.0.2:4335,还可以为图2应用系统内部网络的域名信息,例如,service.dev.company.iot;第一转发路径字段用于存储在第一转发主机地址字段对应的第一服务器主机上处理当前请求路径对应功能的具体的路径信息。

例如,第一请求路径数据为“/business/product/getlist”,第一对应关系表如表五所示,则第一对应关系表中与第一请求路径数据匹配的第一对应关系记录为第1个第一对应关系记录,从第1个第一对应关系记录中提取出的第一主机地址数据为“service.dev.company.iot”,第二请求路径数据为“/getlist”。

表五

步骤5,按http协议的请求报文数据格式,将第二请求路径数据做为请求报文请求行的url信息,将第一主机地址数据做为请求报文请求头的主机字段信息,将第一参数数据组做为请求报文的请求体,拼装生成第二业务请求报文数据;并向第一主机地址数据对应的第一服务器,发送第二业务请求报文数据。

这里,图2中业务请求转发子服务需要根据获取到的第一主机地址数据、第二请求路径数据以及步骤3中提取出的第一参数数据组,重新拼装生成新的请求报文数据也就是第二业务请求报文数据;该请求报文数据的请求方法通常采用post方法;

对于post方法的第二业务请求报文数据,按http协议规则,其请求行的请求方法信息应为post,其请求行的url信息应不带参数为第二请求路径数据;在其请求头中,host字段的内容设为第一主机地址数据;在其请求体中,将第一参数数据组的两个参数采用字符串“product_id=1&product_id=2”的形式进行参数添加;因为在请求体中纳入了参数,所以还需在请求头中使用content-type字段将请求体携带的数据或文件的格式进行说明,例如text/plain说明请求体中的数据为文本数据,另外,还需使用content-length字段对请求体数据长度进行说明,例如请求体中的字符串“product_id=1&product_id=2”长度为25,则content-length应为25。

例如,第一主机地址数据为“service.dev.company.iot”,第二请求路径数据为“/getlist”,第一参数数据组包括两个第一参数数据:第1个第一参数数据为product_id=1、第2个第一参数数据为product_id=2,则最后,图2中业务请求转发子服务会向图2中域名为“service.dev.company.iot”的产品子服务所在服务器发送第二业务请求报文数据,第二业务请求报文数据的具体内容如表六所示。

表六

另外,如果图2中域名为“service.dev.company.iot”的产品子服务,需要对请求报文的使用权限进行校验的话,就还需要在第二业务请求报文数据中添加用于校验的信息,类似授权令牌或者授权校验码信息,因此在拼装生成第二业务请求报文数据时,还应包括:

根据第一主机地址数据,对预设的反映主机地址与主机授权参数集合对应关系的第二对应关系表的所有第二对应关系记录进行轮询;当被轮询的第二对应关系记录的第一主机地址字段与第一主机地址数据匹配时,提取被轮询的第二对应关系记录的第一主机授权参数集合字段,做为第一授权参数集合;根据第一授权参数集合,进行校验信息准备处理,并将准备处理得到的结果按http协议的请求报文数据格式,添加至第二业务请求报文数据的请求头中;

其中,第二对应关系表包括多个第二对应关系记录;第二对应关系记录包括第一主机地址字段和第一主机授权参数集合字段。

这里,第二对应关系表为预设在图2中业务请求转发子服务本地或者系统数据库中的数据表项;每个第二对应关系记录对应一个具体的主机地址;第二对应关系记录中的第一主机地址字段用于存储该对应的主机地址;第一主机授权参数集合字段中至少包括两个子信息:令牌子信息、应用标识子信息;

根据第一授权参数集合,进行校验信息准备处理时,若令牌子信息不为空,则将该子信息提取出来,并在第二业务请求报文数据中添加token字段,并将令牌子信息做为token字段的内容;若应用标识子信息不为空,则从系统数据库中查出与应用标识子信息对应的应用密钥信息key2,再生成一个时间戳t1,再对应用标识子信息+应用密钥信息key2+时间戳t1组成的连续数据进行md-5数字摘要计算得到一个授权校验码信息code1,再在第二业务请求报文数据中添加client-timestamp、auth-app-id、和auth-app-sign字段,并将client-timestamp的内容设为时间戳t,将auth-app-id字段的内容设为应用标识子信息,将auth-app-sign字段的内容设为授权校验码信息code1。

例如,第一主机地址数据为“service.dev.company.iot”,第二请求路径数据为“/getlist”,第一参数数据组包括两个第一参数数据:第1个第一参数数据为product_id=1、第2个第一参数数据为product_id=2,第二对应关系表如表七所示;

表七

则表七中与第一主机地址数据匹配的第二对应关系记录为第1个第二对应关系记录;该记录中第一主机授权参数集合字段的令牌子信息、应用标识子信息均不为空,所以应在第二业务请求报文数据中添加token、client-timestamp、auth-app-id、和auth-app-sign四个字段;

接着,从系统数据库中查出与应用标识子信息“10012”对应的应用密钥信息key3,再生成一个时间戳t2,再对应用标识子信息“10012”+应用密钥信息key3+时间戳t2组成的连续数据进行md-5数字摘要计算得到一个授权校验码信息code2;

然后,在第二业务请求报文数据中,将token字段的内容设为“eitrsncxregvvutxogreylvzm2xxd230483thkgfl2r6d1vlufo2b05mk1ory0g3etmxmu1vqwf6wedztdjhqjhqzzhmt1ixa2kztmtts1hrvng1s3byy01c”;将client-timestamp字段的内容设为时间戳t2;将auth-app-id字段的内容设为“10012”;将auth-app-sign字段的内容设为授权校验码信息code2;

最终,得到的第二业务请求报文数据应如表八所示。

表八

图4为本发明实施例二提供的一种业务请求报文数据的处理装置的模块结构图,该装置可以为实现本发明实施例方法的终端设备或者服务器,也可以为与上述终端设备或者服务器连接的实现本发明实施例方法的装置,例如该装置可以是上述终端设备或者服务器的装置或芯片系统。如图4所示,该装置包括:

获取模块201用于获取第一业务请求报文数据。

权限校验模块202用于对第一业务请求报文数据,进行请求权限校验处理。

业务请求转发模块203用于在请求权限校验处理成功,则按超文本传输协议http协议的请求报文数据格式,对第一业务请求报文数据的请求行的统一资源定位符url信息,进行路径信息与参数信息的拆解处理,生成对应的第一请求路径数据和第一参数数据组;并根据第一请求路径数据,查询预设的反映请求路径与转发主机地址及转发路径对应关系的第一对应关系表,生成对应的第一主机地址数据和第二请求路径数据;并按http协议的请求报文数据格式,将第二请求路径数据做为请求报文请求行的url信息,将第一主机地址数据做为请求报文请求头的主机字段信息,将第一参数数据组做为请求报文的请求体,拼装生成第二业务请求报文数据;并向第一主机地址数据对应的第一服务器,发送第二业务请求报文数据。

本发明实施例提供的一种业务请求报文数据的处理装置,可以执行上述方法实施例中的方法步骤,其实现原理和技术效果类似,在此不再赘述。

需要说明的是,应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现;也可以全部以硬件的形式实现;还可以部分模块通过处理元件调用软件的形式实现,部分模块通过硬件的形式实现。例如,获取模块可以为单独设立的处理元件,也可以集成在上述装置的某一个芯片中实现,此外,也可以以程序代码的形式存储于上述装置的存储器中,由上述装置的某一个处理元件调用并执行以上确定模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起,也可以独立实现。这里所描述的处理元件可以是一种集成电路,具有信号的处理能力。在实现过程中,上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如,以上这些模块可以是被配置成实施以上方法的一个或多个集成电路,例如:一个或多个特定集成电路(applicationspecificintegratedcircuit,asic),或,一个或多个数字信号处理器(digitalsignalprocessor,dsp),或,一个或者多个现场可编程门阵列(fieldprogrammablegatearray,fpga)等。再如,当以上某个模块通过处理元件调度程序代码的形式实现时,该处理元件可以是通用处理器,例如中央处理器(centralprocessingunit,cpu)或其它可以调用程序代码的处理器。再如,这些模块可以集成在一起,以片上系统(system-on-a-chip,soc)的形式实现。

在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时,全部或部分地产生按照本发明实施例所描述的流程或功能。上述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。上述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,上述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线路(digitalsubscriberline,dsl))或无线(例如红外、无线、蓝牙、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。上述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。上述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,dvd)、或者半导体介质(例如固态硬盘(solidstatedisk,ssd))等。

图5为本发明实施例三提供的一种电子设备的结构示意图。该电子设备可以为前述的终端设备或者服务器,也可以为与前述终端设备或者服务器连接的实现本发明实施例方法的终端设备或服务器。如图5所示,该电子设备可以包括:处理器31(例如cpu)、存储器32、收发器33;收发器33耦合至处理器31,处理器31控制收发器33的收发动作。存储器32中可以存储各种指令,以用于完成各种处理功能以及实现本发明上述实施例中提供的方法和处理过程。优选的,本发明实施例涉及的电子设备还包括:电源34、系统总线35以及通信端口36。系统总线35用于实现元件之间的通信连接。上述通信端口36用于电子设备与其他外设之间进行连接通信。

在图5中提到的系统总线可以是外设部件互连标准(peripheralcomponentinterconnect,pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture,eisa)总线等。该系统总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。通信接口用于实现数据库访问装置与其他设备(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(randomaccessmemory,ram),也可能还包括非易失性存储器(non-volatilememory),例如至少一个磁盘存储器。

上述的处理器可以是通用处理器,包括中央处理器cpu、网络处理器(networkprocessor,np)等;还可以是数字信号处理器dsp、专用集成电路asic、现场可编程门阵列fpga或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

需要说明的是,本发明实施例还提供一种计算机可读存储介质,该存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述实施例中提供的方法和处理过程。

本发明实施例还提供一种运行指令的芯片,该芯片用于执行上述实施例中提供的方法和处理过程。

本发明实施例还提供一种程序产品,该程序产品包括计算机程序,该计算机程序存储在存储介质中,至少一个处理器可以从上述存储介质读取上述计算机程序,上述至少一个处理器执行上述实施例中提供的方法和处理过程。

本发明实施例提供一种业务请求报文数据的处理方法、装置、电子设备、计算机程序产品及计算机可读存储介质,将接收的业务请求报文数据中的url信息做为请求路径,并通过查询预先配置的反映请求路径与转发主机地址及转发路径对应关系的第一对应关系表,得到对应的转发路径,并按转发路径向实际处理业务的服务器发送业务请求参数,并在接收和转发时,完成对业务请求报文数据的权限校验和授权参数准备等操作;这样一来,只需将具备本发明实施例功能的服务部署在公网上即可,既降低了应用系统整体受攻击的风险,又降低了子服务上用于处理业务请求的软硬件开销。

专业人员应该还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施方式而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1